Benefits of 2D code layouts (2018) | Hacker News Reader

Benefits of 2D code layouts (2018)

twitter.com

30 pointschrispsn16 comments

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.

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.

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.

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].

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!

[1] https://trymito.io/hn [2] https://trymito.io/blog/repl

claiming that it's the code's 2D-ness that makes it beneficial

This looks pretty cool, some questions, which I'm asking with the hope that they're helpful to you more than that I am desperate for a response.

1. What's the pricing model. I'm guessing it's not free or open source, but I can't even confirm that from the website. This is enough to bounce me from a product like this.

2. Is there reference documentation somewhere? I've been bitten before by enterprise products that only have getting started documentation, and I'm not keen to be bitten again.

3. I can find documentation for importing data, but not exporting. I assume it's available, but I can't quickly confirm it, and that feature is absolutely critical for the use case I have in mind. This sort of goes back to the reference documentation point as well...

Here's the use case I have in mind. My Mom, who is somewhat capable of programming but not an expert (anymore), runs a online plant store. As part of running this she has a bunch of scripts that transform one spreadsheet into another, e.g. combining a supplier price list, a list of images, and a bunch of data cleaning, into a csv that can be uploaded to shopify to create a list of products. Or turning a list of orders from shopify, fetched via json, into a spreadsheet that can be sent to the supplier as a single order.

Tooling that made this process simpler, easier to debug, etc would be (or have been) great (especially for me, the professional software developer who gets pulled in to help whenever things get too complicated). I took a look at this product with an eye towards that.

To be honest I'm not much of a sales lead, apart from the fact that the business is tiny, the software definitely isn't being rewritten during the summer (busy season), and it's probably not being ported to a new framework at all (why would it be, what exists works). Still, I'm curious about what your software can do, and if it would have been appropriate.

> The best of both worlds, IMO, is a spreadsheet for data visibility, and a program for transformation visibility.

Having used Excel way more than I expected last year, I agree with this. Transforming data one time to explore it on Excel is really easy and nice. On the other hand, trying to automate the steps that other people do manually is often not so nice and easy and I'd love to be able to use something else than VBA, something like pandas for exemple.

As an aside, I've been looking for a tool to handle spreadsheets with a few millions rows and that can be used by people without too much experience with programming. Do you think Mito would fit this use case?

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.

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.

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.

A 2D view of code layout could be useful in this sort of secondary radar way for learning a new codebase, refactoring, etc.

As a primary mechanism for writing code, outside specialized applications like graphics shader development, I'm not sure it makes sense.

Sublime has the minimap, a name which sounds like it was borrowed from the videogame world.

Isn't this just a map? Usually maps are smaller than the territory.

I haven’t really found a use for the minimap in VSC. I’m not sure if there’s some strategy or concept that it’s supposed to assist with, besides navigating large files more quickly.

A mini-map is a cool idea! In Excel I often temporarily zoom out to get a big picture view of the program structure.

For most applications, having used a few 2D "programming languages", I disagree.

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.

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.

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.

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.

They added lambda functions to excel so it's pretty much there.

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).

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.

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:

https://en.wikipedia.org/wiki/Barcode#Matrix_(2D)_barcodes

Reply on news.ycombinator.com