Was this post prompted by this year’s ICFP competition?
Spatial languages: Writing code in 2D
11–20 of 48 posts
Re: Spatial languages: Writing code in 2D
#12Earlier quoted context omitted.
I think humans are pretty good at thinking/operating in a 3D space. It's just that digital interface and programming tooling is not there. Obviously because usually there is no direct translation from domain model to physical 3D shapes. But it can well for those that translate: 3D modelling, spatial reasoning, motion tracking, mechanics, etc.
I imagine this varies by person, but thinking about a source file is already reminiscent of 2D space navigation, where the X axis is typically gated by conditions. In a similar vein, when I think about functions from different source files, I do hold some type of "depth", or "stacked panels" in my brain. I think this is because I reason about programs being in some state ~= being positioned at a certain function with…
For real! Good contenders for 3 dimensions: individual expressions, call stack, time.
Re: Spatial languages: Writing code in 2D
#13"All this time we’ve been writing expressions in 1D space, but what happens when we unlock an extra dimension?" 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.ycombinat…
1D languages encode these relations grammatically. There is no reason why a 2D language couldn't also be grammatical. Sure it is harder to write a 2D parser perhaps, but people have still played with the idea a little bit. There is just no huge economic incentive to do so other than simple aesthetics.
Re: Spatial languages: Writing code in 2D
#14"All this time we’ve been writing expressions in 1D space, but what happens when we unlock an extra dimension?" 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.ycombinat…
A certain subset of programmers apparently just really, really hate this whole messy concept of "thinking about things". 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 laborious…
And also we treat text as an higher dimensional concepts, like the concept of lines and indentations. Jumping around in code navigation, the tree structure in code organization. The separation of mutable semantics for the code in our projects and immutable ones in the libraries that are added. And that’s without diving into the abstraction represented by the symbols and the relationships between them.
Anyone that says text is 1D has a poor model of code in his or her mind.
Re: Spatial languages: Writing code in 2D
#15This is just silly.
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.
Re: Spatial languages: Writing code in 2D
#16Earlier quoted context omitted.
A certain subset of programmers apparently just really, really hate this whole messy concept of "thinking about things". 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 laborious…
And also we treat text as an higher dimensional concepts, like the concept of lines and indentations. Jumping around in code navigation, the tree structure in code organization. The separation of mutable semantics for the code in our projects and immutable ones in the libraries that are added. And that’s without diving into the abstraction represented by the symbols and the relationships between them. Anyone that say…
So the textual representation of the Mona Lisa would actually be more suitable and beautiful?
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.
Re: Spatial languages: Writing code in 2D
#17I find it endlessly fun that one of the best environments for playing with befunge is written for the zmachine.
Re: Spatial languages: Writing code in 2D
#18Soon we have an IDE that works in 3D. So, not only do you have to look left-right, then top-bottom, but also before, and behind. That's scaling code! You write in 3D now. Or, you stick to oldschool old people. Keep things simple.
My approach is to start out with a 2D programming environment and once that becomes a general programming environment, to scale that up to 3D and explore how to map 2D to 3D. So first map 1D concepts to 2D and then move on.
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/
Re: Spatial languages: Writing code in 2D
#19> Cube is a three-dimensional, visual, statically typed, higher-order logic programming language, designed to be used in a virtual-reality-based programming environment. In this paper, we give an informal overview of the language and describe a prototype implementation.
Re: Spatial languages: Writing code in 2D
#20Earlier quoted context omitted.
And also we treat text as an higher dimensional concepts, like the concept of lines and indentations. Jumping around in code navigation, the tree structure in code organization. The separation of mutable semantics for the code in our projects and immutable ones in the libraries that are added. And that’s without diving into the abstraction represented by the symbols and the relationships between them. Anyone that say…
So the textual representation of the Mona Lisa would actually be more suitable and beautiful? 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 r…
You're saying that text are 1D, while we're saying that it's not. If it were, we would write text on a long rolling tape. If it were, we would write matrices like this:
[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.