nice job!
Well thanks for the compliment, but Art-Horns-Hue was invented by a 12-year-old and Animal Game is an old, old, standard Logo demo. I did invent https://scratch.mit.edu/projects/1053593/ and https://scratch.mit.edu/projects/1068688/ but mostly I do boring things like https://scratch.mit.edu/projects/257694182/.
Jens, on the other hand, cranks out great demos in his sleep. (It must be in his sleep because all his awake time is developing Snap!.)
Roses are red, violets are blue,
console.log("Hello, you!")
Sigh.
It's new to me, but I think it would slow down my computer too fast 
A remix, containing Jens' repeat and warp trick.
INSTRUCTIONS.
You can freeze the droplets by moving the mouse to the bottom of stage (touching an invisible shape, which will in turn change its transparency based on the amount of droplets touching it). Except for the droplets that have been touched by the mouse; those will continue moving.
nice! 
I'm humbly inspired only by the most interesting originals, such as your one here. Thanks for sharing the original, fridolinux!
That a 12 year old wrote the project makes the point all the more. Snap! has a high ratio of effect to code; big bang for the coding buck. And there are some amazing block-code projects out there. Tale of the Fiery Dragon (scratch.mit.edu/projects/126517840) comes to mind.
Even so, rules are not methods. That's true of all languages, whether English or JavaScript. I know the syntax of Snap! Heck, I know the syntax of JavaScript and the rules of baseball. I have yet to hit it out of the park. What I would like is a course on techniques of turning a concept into code. Going from an idea of what it should look like (effect) to translating that into working code.
Suppose I compose verse about the feeling of being in the scene when riding a motorcycle. I can hang a static image with it. Meh! Better still, I could create an interactive installation. Something in the sprit of fridolinux's "water simulation" above. So suppose I decide to simulate push steering on the bike, which is different from driving a car. Okay, now I know what I want to do. Nobody can write a manual for how to do all projects. Nor would I want one. But I would like something like the MasterClass series. Talented individuals who offer insight into their general methods and tips on technique.
There is a rise in tele-education. I can see the need for instructors and learners to turn concept into project with relative ease. Snap! has a calling here, both aesthetic and instructional. So the missing manual is somewhere between "Snap! 6 Reference" and the assignment. "Okay, by Monday make a simulation of blood pressure." Or goalie strategies or organic composting or scheduling efficiency.
You said you would like a MasterClass series about "turning a concept into code".
I share the sentiment with you, however, I would prefer first to have an intermediate ("pre-Master") course, showcasing not the concept-to-code path yet, but an original-to-remix path, in other words, a course teaching (or showcasing) how to remix an interesting project, is what we need, imho.
I'm deeply humbled by your beautiful accounts of how true inspiration can be found in programmed artifacts. It's precisely such projects as Frido's water project that make my heart smile. As far as Brian's praise for my own demos goes, I'm very afraid that your idealistic perception of how they come to existence is entirely exaggerated.
For me the music is very much in the piano. That's an Alan Kay quote and I'm emphatically contradicting it. Alan said that there isn't any music in the piano. For me, there is. Great minds must be able to conceive of a notion of beauty and - as you say - translate it into working code. Not me. I fiddle around with whatever my hands pick up, and the things suggest things I might do with them. And then those things suggest variations, and the variations of things beget new ideas.
When I was in Peru last September I bought a charango, a little guitar-like 10-stringed instrument with a peculiar, doubly-reentrant tuning that makes it ridiculously hard to play a tune, but fairly easy to strum those Andean chords. They practically fall out of the instrument as soon as you pick it up. I'm sure that handling a charango explains more about the indigenous tunes of the Andes than reading a book about it. Because the music is in the instrument.
In that respect programming languages are like musical instruments for computing to me. There are projects that literally "fall out of them" as soon as you pick them up. And then those projects suggest variations, and those variations trigger new ideas.
When I grow up I want to build an instrument that makes minds sing.
I think you did build it. Soon to be in version six.
And your point is well taken that music (function) follows from the instrument (form). In that sprit, to tinker with the blocks of Snap! is to see a project as performance and reach for the blocks that make that interaction happen.
Cool. I think you just wrote the first chapter of the missing methodology manual.
Taking up my previous example of being in the scene, push steering is about the "swoopy." Press this side of the screen and the image tilts, the path curves, then uprights. Harder the press, more intense the swoop, into a back and forth glide through the twisties of a mountain path or along a long valley arc.
Which blocks capture the press, curve the path, tilt the view? Pretty it up with a few bells and whistles, a bit of back and forth experimentation, and there it is. A few artist friends hate being asked where their ideas come from. They don't like to admit it is a messy, mundane process of revisions that started over there and end up here.
Likewise, contemporary poet A.E. Stallings uses rhyme in her work as a methodology. Finding patterns of sound compel her to re-imagine and evolve ideas, pushing the subject in directions not previously pictured. As with the poet, so with the coder. Fitting ideas to blocks, re-imagining, evolving, going directions not previously envisioned.
Ya know . . . Snap! is a charango.
Interesting thread ...
I have had similar experiences with recoding & remixing examples of early computer art. I learned a lot by analyzing the artwork and then designing algorithms to reproduce it. Snap! was immensely helpful in implementing them with manageable previous knowledge. Little by little I discovered new concepts (command-blocks) that simplified the implementation and allowed completely new components for remixing the artwork.
I agree with Jens that the art (at least some ideas) can be influenced by the tool. Unfortunately, as an autodidact, I lack basic computer science knowledge, because I suspect that advanced concepts (i.e. like object-oriented programming) could be very helpful for my further ideas, which I am probably unnecessarily tedious to tackle with my current state of knowledge.
The Snap! manual does not necessarily help me in this respect. I am still looking for a textbook that I can use as a low-threshold entry to the use of these concepts.
I appreciate the discussion. It helps coalesce a number of questions. The first and most important is: What is it I want to do? Now I know with a bit more precision. I want to make what, for lack of a better term, I call Snap!Art.
I can say what that is. I cannot say (yet) how to go from a concept to its code. In this regard, however, Jens offered an insight about allowing the instrument (block based coding) to inform the design. What that says to me is think in blocks. By analogy, in learning French, think French, don’t translate back and forth from English. In learning metric, think metric, don’t keep converting. (If I have seriously misunderstood, Jens, then I promise hang up my charango 
)
So, what is Snap!Art?
( Skip if uninterested, of course. )
In short, it’s an interactive installation made with Snap! How it is made with Snap! is for the missing manual. But I characterize an interactive installation as a (a) first-person (b) software (c) simulation.
(a) The user is a participant, not observer to the process. For example, a player on the field, not a spectator fan in the stands.
(b) The work is based on instructions by which user actions are turned into observable results. For example, rolling a virtual bowling ball down an alley knocks over pins along its path.
(c) The work is an immersive imitation [mimesis] of another real or realistic process. For example, a playground train for a toddler to sit on and turn a wheel and imagine steering.
As an installation, the work is on exhibit in a physical or virtual location as (a) an original (b) artifact (c) of aesthetic merit. For example, a kinetic sculpture in the lobby of a museum.
(a) Original in that the work is authentic or innovative (not a trivial copy of preceding work, mass produced, or clone)
(b) An artifact in that the work is human made, not naturally occurring (animals don’t make art)
(c) Having aesthetic merit in that the work is a personal expression, not merely functional (the way it is matters, not simply what it does). For example, the work inspires amusement, wonder, or appreciation.
Water simulation, which started the discussion, I see as an excellent example of Snap!Art. I want to add Snap!Art rather than simply static graphics to blog posts. That way, make the content more immersive and add to the content beyond a passive image.
Snap! is an excellent medium in this regard, no small part of which is how easily it is embeds on a post page and the improved speed of version 6. (I tried LiveCode …briefly.) The expressive power of Snap! isn’t the blocks. At least, not for me. It could just as easily be text syntax based. Rather, it’s the approachability of the language and ease of deployment. Heck of a lot more intuitive and expressive than Processing (https://processing.org).
Eckart's book? I guess you have to speak German...
Please do not necropost.
Did the post to which I was replying add anything to the discussion of the water simulation project?
Oh that’s why