Found 3 comments on HN
akkartik · 2016-05-21 · Original thread
By a strange coincidence I just happened to be reading when I spotted this thread on another tab. I found it after reading this quote from "A small matter of programming":

Kay's colleagues have created a simulation construction kit for children so they can build their own simulations. The construction kit lets children write simple scripts that model animal behavior. Using the kit they can change parameters to see how changing conditions affect the animal. With the kit, the children have tools that give them tremendous scope for intellectual exploration and personal empowerment. Kay reported that the children have, with much enthusiasm, simulated an unusual animal, the clown fish, "producing simulations that reflect how the fish acts when it gets hungry, seeks food, acclimates to an anemone, and escapes from predators."

jamii · 2014-10-17 · Original thread
> They are going for a visual language

'Visual language' is a very overloaded term and we are in no way set on any particular ideology. Textual languages and visual layout have different strengths and weaknesses and there are lots of cases where it makes sense to mix both. There is plenty of evidence that both are useful (eg My only aversion to text is as an unstructured storage and communication format - it makes much more sense to allow tools to communicate using a shared, versioned and structured database rather than watching for changes in text files.

> visual languages are inherently hierarchal

Excel -

Access -

Labview -

Blender -

PureData -

TouchDevelop -

Kodu -

Pretty much the only hierarchical example that comes to mind is Scratch.

> Trying to map source-code that stores a lot of it's context on the stack is really hard to visually represent.

Yes. But non-local scope and control flow are also pretty hard to represent and understand. That's why we ended up avoiding both.

> However, if you can keep all of the context/state of your program in one area and it is hierarchal...

It doesn't have to be hierarchical. Excel and Access both have amazing (by programming tool standards) visual representations of your program and your data.

> So, all the cool things you can do visually representing data-structures, you can do with your actual program.

Data and code are different though. Eve is homoiconic-ish (code is stored in tables) but the actual visualisations and manipulations applied in 99% of the use cases are very different. We don't spend nearly as much time manipulating code as data compared to reading, writing and understanding code so it makes sense to default to visualisations that optimise for the latter.

> The only way to prevent people from running important systems with giant Excel spreadsheets is to present a better alternative.

I think the spreadsheet can still be improved. Macros can help a lot with this, but there are a myriad of other ways you could improve upon excel that gives a smooth transition from "casual user" to "power user". Read "A Small Matter of Programming"[0] for more!


Get dozens of book recommendations delivered straight to your inbox every Thursday.