I think phrasing spreadsheets as 2D code is mostly misleading, as it makes it seem like it's the code's 2D-ness that makes them useful.<p>Spreadsheets are one way of consuming 2D _data_, which most business data is. They also provide a very easy interface for thinking about basic transformations on this data: the data is very visible, and every transformation you make is therefore very visible as well. Really: it means folks don't have to worry about control flow.<p>I agree with other commenters as to the effects of 2D code. I've spent the past year talking to 100s of Excel power users, and it's pretty clear: at any scale, spreadsheets get incredibly hard to follow, audit, and maintain.<p>The best of both worlds, IMO, is a spreadsheet for data visibility, and a program for transformation visibility. I'm a bit biased though, because this is exactly what we're building at Mito [1].<p>If you want to see more of our thoughts on the topics above - check out this blog [2] exploring the relationships between REPL environments, spreadsheets, and noteboooks!<p>[1] <a href="https://trymito.io/hn" rel="nofollow">https://trymito.io/hn</a>
[2] <a href="https://trymito.io/blog/repl" rel="nofollow">https://trymito.io/blog/repl</a><p>claiming that it's the code's 2D-ness that makes it beneficial
The thing that I've kind of settled on with respect to text is that it's actually 2D variable width. The line ends, right? The 1D-ness is an encoding detail. The interface and presentation of an interactive editor is clearly a 2D one, albeit tailored around dealing with the variable-widthness.<p>What we get from spreadsheets that is quite nice, formatting-wise, is the cell data being of a rich type. A number of larger size doesn't take up more symbolic space, and therefore it remains fungible as a whole, rather than being round-tripped between number, string, number as is often the case.<p>When we use plaintext, suddenly a need for explicit binding of literals arises, and we become prone to "thinking" in terms of that binding layer and its apparatus, versus, say, something with a spatial analogy like a stack machine. They're Turing-equivalent, but one or the other may solve a problem more adeptly.
Whenever someone mentions 2d code layouts they typically show examples of "node and links" or "spreadsheet" coding. However, those examples are largely focused on one presentation. I'd really like a language/editing environment to be able to handle all three styles, depending on what I was trying to do.
Many multiplayer video games have a radar that provides a high-level summary of the positions of teammates and hostiles. This is useful information that helps navigation, and it's usually a small element tucked in a corner.<p>A 2D view of code layout could be useful in this sort of secondary radar way for learning a new codebase, refactoring, etc.<p>As a primary mechanism for writing code, outside specialized applications like graphics shader development, I'm not sure it makes sense.
For most applications, having used a few 2D "programming languages", I disagree.<p>2D layouts are simply too hard to follow once things start getting complex. You spend a lot of time reorganizing stuff. If you find writing clean code hard, making clean graphs is hard squared. As for spreadsheets, they are good for manipulating data, but for logic that is a little bit complex, they are terrible.<p>The author claim it is better for parallelism, but even for the most parallel application: chip design, most people use text-based "1D" programming languages (HDL) when things get serious.<p>Also, do you remember UML? It used to be super trendy in the 90s. Now, I almost never see it used. Sometimes you get a class diagram, usually generated from code.<p>2D layouts can be nice on a very high level. Connect the boxes. Digital audio workshops tend to work like that, but behind the boxes, this is regular code.
Excel as a code editor would be cool. Each cell could be a function or variable, watch them update in real-time, highlight which functions are being called, which variables are being used.
I'm currently working with a massive spreadsheet used to calculate CNC paths for manufacturing parts built in an online ordering system. It is not an advantage, it's a horrible way to do things. If I were working in code is be done by now, I'd have unit test and processing would be a factor of 1000 faster ( Excel interior is slow).<p>I see no benefit to a 2d layout except in a few special cases.
This guy needs to learn R. Matrices are first class citizens.<p>They don't need to live in R but it's a nice place to visit to understand the paradigm they're discovering.
And there is the world of 2D barcode (Matrix) including the ubiquitous QR code:<p><a href="https://en.wikipedia.org/wiki/Barcode#Matrix_(2D)_barcodes" rel="nofollow">https://en.wikipedia.org/wiki/Barcode#Matrix_(2D)_barcodes</a>