Coding: Fleeting Thoughts

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
Qaanol
The Cheshirest Catamount
Posts: 3040
Joined: Sat May 09, 2009 11:55 pm UTC

Re: Coding: Fleeting Thoughts

Postby Qaanol » Tue Dec 05, 2017 2:01 am UTC

Xeio wrote:Todays Google doodle is nice.

They appear to measure “shortest solution” in terms of fewest instructions, not least movement.
wee free kings

User avatar
hotaru
Posts: 1025
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: Coding: Fleeting Thoughts

Postby hotaru » Tue Dec 05, 2017 4:08 am UTC

Qaanol wrote:
Xeio wrote:Todays Google doodle is nice.

They appear to measure “shortest solution” in terms of fewest instructions, not least movement.

also, the "shortest solution" is wrong for the last one.

edit #1: same for number 4.

edit #2: and number 5.

Spoiler:
number 4, 6 instructions instead of 7: { { forward, forward, right } loop 4 times, left } loop 3 times

number 5, 5 instructions instead of 6: { { forward, right } loop 10 times, left } loop 18 times

number 6, 5 instructions instead of 6: { forward, right, forward, forward } loop 11 times

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

speising
Posts: 2078
Joined: Mon Sep 03, 2012 4:54 pm UTC
Location: wien

Re: Coding: Fleeting Thoughts

Postby speising » Tue Dec 05, 2017 10:16 am UTC

hotaru wrote:
Qaanol wrote:
Xeio wrote:Todays Google doodle is nice.

Spoiler:
number 6, 5 instructions instead of 6: { forward, right, forward, forward } loop 11 times

there's a solution in 4. (hint: you're doing something 3 times)

User avatar
Yakk
Poster with most posts but no title.
Posts: 11049
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

Re: Coding: Fleeting Thoughts

Postby Yakk » Mon Dec 11, 2017 9:06 pm UTC

Xanthir wrote:You might be interested in looking into Streams, like RxJS and the like. The concepts are very similar, and they've thought about many of these problems already.

I've poked at them, but documentation tends to focus on *using* them, not how they where written and how they work.

A lot of what they are doing -- passing key-value property bundles around -- isn't what I'm aiming for. I want type safety and argument descriptions and the like.

Also, they seem OO; and I've been trying to be functional instead of OO. My pipe/source/sink elements are fundamentally *functions* (with a bit of type-dressing), RxJS seems to have *objects* as its fundamental unit. I can see how to solve it with objects; maybe I should just bite the bullet, create real objects with a richer API, and just have factory-from-function when users don't care?
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

Tub
Posts: 320
Joined: Wed Jul 27, 2011 3:13 pm UTC

Re: Coding: Fleeting Thoughts

Postby Tub » Tue Dec 12, 2017 12:39 pm UTC

Yakk wrote:I've poked at them, but documentation tends to focus on *using* them, not how they where written and how they work.

Well, they are open source...

I'm not entriely sure I read your notation right, but you seem to try mixing the two fundamental control principles of streams: push and pull.

In push-based systems, the Sources will generate new data whenever they feel like it, and call into their sources with the new data. This is useful in complex event processing, e.g. when data arrives in near real-time from sensors.

In pull-based systems, the call stack is the other way around. You call into your sources, requesting a piece of data, which in turn request data from their sources etc. This is commonly called an operator graph in database systems. Because your sink will only request as much data as it needs, this allows early aborting of queries suffixed with 'LIMIT n'. It's also used anywhere you get an Iterator.
Pull-based systems require all data to be available when requested, e.g. in memory or on a local disk. You can kinda get around that in a language with async/await or something, but that'll only turn your source<T> into source<Promise<T>>, and then you're usually better off with a push-based system.

In push-based systems, no pipe or sink needs to know about its sources. In a pull-based system, no pipe or source needs to know about its sinks. Your definitions of source and sink seem to imply a push-based system, but then your pipes get a reference to both a source and a sink, and that seems weird.

You can try to create a system that somehow does both (rxjs appears to do so), but (from a cursory glance) rxjs just implements two systems in the same library with similar APIs. Pick one and start with it.


You can do everything functional, but IMHO it's easier to model as a (acyclic, connected, directed) graph of nodes, each being an object with a standardized API, like push<T> or observe<callback<T>> (for push-based) or get<T> or getIterator<T> (for pull-based). Passing the connections in a type-safe way in the constructor just seems cleaner and more robust than mixing connections and data in an arbitrary argument list.


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 6 guests