Text is a serialization of an n-dimensional work space. "N-dimensional" doesn't have a formal definition I'm aware of but the major characteristic of it is that a new dimension can pop up anywhere. If you feel like you want to double-click on that, you can see my earlier comment here: https://news.ycombinator.com/item?id=35096647
A conventional textual language can represent everything mentioned there, whereas 2D layouts struggle almost immediately to represent things that textual layouts represent quite easily.
It can still be a useful "see the world differently" exercise, but it's the opposite of "freeing your mind"... it's stepping into a fairly small subset of functionality, albeit an unconventional one, and seeing what you can still manage to do even so. Rather than "unlocking a new dimension" it's actually throwing away n-2 of them. The experience of using this for any period of time would reveal this, as it would be a constant struggle to represent even very simple algorithms in this format.
I post this mostly because of the "familiarity breeds contempt" effect that programmers seem to get hit with for text. There is a reason we use text and it's not lack of imagination or being stuck in our ways... it is actually an incredibly rich and powerful format that poses a serious challenge for any alternative to overcome because of the astonishing combination of compactness combined with representational power.
Text works and is hard because it's a projection of a mental representation. The whole reason we can work with N-dimensional structures in text is because the dimensionality lives in the programmer's head. There isn't really any other way to represent say a >3 dimensional array other than laboriously flattening it into text and expecting the next guy to rotate the hypercube in his mind. That's neither a good nor bad thing, it's purely a fact of our 3+1 dimensional universe.
A shocking number of problems can be best represented in higher dimensions and there's simply no way to encode that information losslessly. Being simple 3D creatures (I'd argue 2D in fact) the only way to do that is by projecting it down into a lower-dimensional space.
Anyone that says text is 1D has a poor model of code in his or her mind.
It's surprising that there is any art at all if 1D textual representation is the ultimate way of representing concepts of the world around us. Incredible really that folks waste their time define colours for such thing as the sunshine.
Oh sorry, of course, you were talking of code - meaning that algorithm concepts are best represented in text? Again, I doubt that very much. Laziness of humans is probably the bigger reason why we're stuck with an inefficient textual representation of higher dimensional concepts.
[1 2 3; 4 5 6; 7 8 9]
|1 2 3|
|4 5 6|
|7 8 9|
In code we split the code into files. Then within the files we arrange the code with lines and indentation. That's all for humans. The computer eagerly throws those away.
ADDENDUM
> meaning that algorithm concepts are best represented in text? Again, I doubt that very much.
One of the (most?) important things that algorithms encode is time. Because an algorithm is a description of a process. The only good representation would have been to snapshot the evolution of state.
But that's wasteful. So instead we have statements and expressions that we assume are atomic. Then we have identifiers for referencing and finally we have procedures and functions to cluster those statements and the associated call/return pattern or the single jump/goto to economize on writing.
So code is at least 2D as operations are described in a line and the lines are arranged by time. But the lines are not linear, instead they are grouped into labelled units and the proper evolution are functions call and jump instructions.
\ | /
.-'-.
-- ( ) --
`-.-'
/ | \
Much like HN is full of textual description and links to images - this entire forum demonstrates the limitations of a textual visual representation.
Yes it works but it's far more verbose than an image would be. Hence an image is worth a 1000 words. And hence HN is more verbose than it needs to be. So is coding more verbose than it needs to be. That's why DSLs (Domain Specific Language) get invented: to reduce the verbosity.
And so it is with a 2D representation: it reduces the verbosity required to transport ideas and concepts. UML is another invention to reduce the verbosity and increase the understanding of the representation of complex systems. Yes UML can be represented as text (see Mermaid[1]) but the UML image is probably a lot more understandable than the Mermaid representation.
It is used to compose songs. You can see the demo in the linked page.
Nitpick - the andFlip function is wasting a whole dimension with unnecessary lines, and also modifying its input argument unnecessarily (yuck!), and it takes 3 arguments as an array for no good reason.
Better: andFlip = lambda a,b,c : not c if (a and b) else c
Except this is really just a normal 2 argument ternary, it does nothing interesting with a or b individually, it treats them as a unit, so I’d argue this shouldn’t even be a function.
I've got my 3D glyph rendering system at glyph3d.dev, and use cases like this help accelerate layout and relationship development immensely. I greatly appreciate your sharing this!
Would you happen to have a trove of similar research or papers I could sponge off of you? Or maybe even a few minutes of your time in some chats / emails to discuss how these tools can be brought to a modern runtime?
The great gift of language is that it allows us to talk about arbitrarily complex things using a stream-like medium. Human speech is fundamentally 1D. The tree like structure of the concepts in language then facilitates the exponential growth in complexity.
Or maybe centuries of human progress just went completely in the wrong direction? Unlikely.
Nothing wrong with being silly, of course.
Or, you stick to oldschool old people. Keep things simple.
As a 2D representation, I've been using flow based programming (FBP)[1] and it's incarnation in Node-RED[2]. The trick here is to understand how to use FBP to create more generalistic programs, i.e., to prove it's Turing Complete.
I think it would be a mistake to just start out with a 2D approach without also taking all the learnings we have made in 1D, i.e. TDD, OOP, KISS, DRY, Functional, Message Passing, Processes etc, and porting those to a 2D representation.
[1]: https://jpaulm.github.io/fbp/
[2]: https://nodered.org/
I think this is because I reason about programs being in some state ~= being positioned at a certain function with some context I carry around. I'm sure it's not the only way to think about it, but it's a reasonable abstraction over what computers do. It's how we oriented our debuggers and early IDEs on as well, and carried this over to modern tools.
Definitely something I'll be thinking about during the next few days.