Hacker News Reader

Comment by pshc | Hacker News Reader

S-expressions are still stored as text. Editing as structure is what IDEs do, but they serialize back to text in the end. This is the mistake. Smalltalk is closer to what I'm talking about. Code stored like git stores data, with hashes and version control.

> I think this is the wrong idea [...]

You're arguing about something else. I worded it badly. The logic is hard and the transformation into a series of instructions is hard. Once you're about to type those in, though, you should be having a conversation with the computer, as opposed to sending a series of tokens into a black box and wondering if it understood what you meant.

View on HN

> Smalltalk is closer to what I'm talking about.

And in Smalltalk, applications lived in the image and were difficult to extract from it. They didn't work well with code outside the image.

That was a bigger deal when the Desktop was King. It might actually be an advantage for web applications: Everything in the image is trusted in your security model and nothing much from the outside can get in. Run the image in a virtual machine (think Xen) to enhance the iron box effect.

> Code stored like git stores data, with hashes and version control.

I don't... we already have git. What could be more 'like git' than git?

> Once you're about to type those in, though, you should be having a conversation with the computer, as opposed to sending a series of tokens into a black box and wondering if it understood what you meant.

There has been some slight work done towards visual development, where you create 'circuit-diagram software': wire up logical components with visual control flow (or visual data flow, perhaps). It never seems to catch on.

> There has been some slight work done towards visual development, where you create 'circuit-diagram software': wire up logical components with visual control flow (or visual data flow, perhaps). It never seems to catch on.

We've done this in the past. You can blame implementation, perhaps, but we've found that in our use case (3D graphics processing workflows), it starts to get too hard to understand what is occuring for any non-trivial "program", since you're bound by the constraints of how much information we decided to display visually, whereas with a general purpose domain-specific programming language you can choose how much information to surface, by being able to choose the level of abstraction you want (or not, as the case may be).

The reason we chose to go visually in the first place, is because someone has the bright idea that "anyone" should be able to create these workflows, but it ends up that a technically minded 3D graphics engineer does it anyway, and they just get frustrated by not being able to write a proper program/script :)

It strikes me that IC design systems started out oriented towards a 2d visualization scheme but have evolved towards a text representation. Chip design was once done by laying out components in a 2d plan view of the chip, but is now done in VHDL/RTL.

An opaque image is the wrong idea, yes. A structure editor necessarily makes the structure easy to extract and manipulate, like git's tooling makes it easy to work with the git DAG.

Think of code where every blob in the git DAG is one AST node. (Obviously this is horrendously inefficient, this is just an example.) No plaintext.

I'm not talking about that particular subset of visual systems like circuit diagrams or other awkward things like LEGO mindstorms. A good representation would still look like code as you know it, since that's proved to be such an information-dense and useful form. The "view" is the same, but the model has been separated from it.

Reply on news.ycombinator.com