Further reading: 1972 - Mark Wells' A Review of Two-Dimensional Programming Languages
And I think not everybody is like this, though! I think there's a difference between "visual programmers" and "text programmers", and this is what causes the flamewars between people who want to "remove noise" by getting rid of parens, braces and semicolons, and people like me who use them as a sort of "signage".
The real problem is that I bet the "text programmers" also write more, well, normal text, and are overrepresented in blogs, articles, and whatnot. (Even though they're wrong XD)
I'm not sure this characterization appropriately divides "text" from "visual" programmers. The argument I usually see for removing symbols is that the general shape and flow of your program should be able to stand on its own and that minutiae like a misplaced semicolon shouldn't be allowed to play tricks on your eyes -- it's not that the visuals are unimportant, but that they _are_ important and that too many extra symbols lead to hard-to-parse visual clutter and more easily facilitate deceptive control flow.
Whether that argument has any merit or not is its own debate of course.
It’s sort of there in my mind and I can see how things are connected, grab stuff and move it around, etc. Super handy for dealing with systems complexity
EDIT: Ahh, I see another comments that this is more of a block based no code kind of thing. I'm not looking to replace my program with purely visual constructs, I'm more interested in representing the file, object, and function layout on a 2D space. Nested folders of files seems so limiting when I want to put particular functions next to each other, and grouped over _here_, while another set of functions should be placed over _there_.
I don't think the greatest power comes from doing away with textual code, I would just prefer that the units which compose a program can be organized, described, and related to each other in a richer way.
For your file example, you could have a "File Open" block that takes a filename as input and outputs a "File Reference" datatype, and then wire that reference to various file blocks (File Read / File Seek / File Write / etc) to perform operations on the file. When needed you could wire a reference to an arbitrary code block, perform whatever operations you want on the file using textural programming, and then output the reference to continue putting it through other blocks. Objects (as in JSON objects) could be represented in the same way, twisting and turning throughout your program as they are manipulated. Ditto for databases, file storage (like S3 or hard drives), sensors and their values, etc. As for functions, you'd be able to build your own blocks from existing ones, so you could take a textual function and turn it into a visual block that integrates with the rest of your code.
You could group blocks together in the editor so that they are literally next to each other as you said, but one feature I'm particularly excited about that was inspired by SmallTalk is the Block Search: instead of searching by name, you describe the input and output types of the block, and the editor will search through the global database for any kind of block that matches your description. For example, you could describe a block that takes two strings and outputs one, and you could get a block back like "String Append." For our hypothetical file example, you would just search for blocks that take in File References, and you'd be able to find every block that does anything to a file, including your own.
I know it's hard to imagine, which is why I'm working on building a demo ASAP so I can show and not tell. I saw from your bio that you're interested in STEM edutech so if this doesn't scratch your itch it may still be helpful for students to get started with software a la Scratch! Let me know if you're still interested - no worries if not though!
My language is a lot simpler: it uses functional programming principles to transform input to output without storing state. The programmer would place down blocks on the screen and draw lines between them to indicate where they want data to flow. They'd start on the left (input side) and end on the right (output side). The cool benefit of this paradigm is that it's recursive; you can build blocks that contain blocks that contain blocks etc... all of which shuttle and transform data from the left to the right.
The other part of this is that it won't just be a language, I'm planning on building an actual cloud environment where you can click a button to deploy your code onto a REST endpoint, so you can integrate it with your existing websites + scripts + apps.
https://en.wikipedia.org/wiki/Jeskola_Buzz
(which is admittedly a terrible pitch, unless you're trying to hook an old demo scenester...)
Not so far fetched but I’m not sure you need a new language to support that. You could press a button and get this view. But I think the idea is to build with always this view on sight ? I have no idea.
The idea also rhymes a lot with George Lakoff theory that we build concepts as towers of analogies and metaphors, whose bases are quite instinctive and frequently spacial (high is good, broad space gives you options, etc.)
it would be interesting to evolve a language from 2D or 3D to more abstract, higher dimensional representation of objects and topologies, like the cognitive spaces described in the article which operate on sparse vectors in a multidimensional system of coordinates (aka "grid cells").
i'm wondering if there is a language for defining network topologies like that, having some abstractions for JOIN/LINK operators to form & evolve a network [0] and FIND or FIND_SIMILAR operator for traversing that graph (looking for similar objects or clusters of objects), and something that allows to simulate "small world networks" effects, heuristics and shortcuts we see in real world graphs (including neural connectivity and distributed communication we observe in the brain)
[0] Leslie Valiant, Memorization and Association on a Realistic Neural Model https://web.stanford.edu/class/cs379c/archive/2012/suggested...
Not only are the data structures 2D/3D, but the language itself is homoiconic.
I'm thinking of things like 2D+ spreadsheets.
Like this from Alan Kay in 1984 (https://pbs.twimg.com/media/E1UAukcUYAAI9lS?format=png&name=...).
A more recent things along these lines that I worked on: https://www.youtube.com/watch?v=0l2QWH-iV3k
At first I actually thought you meant human languages, which are already 3d to a large extent, because they're full of movement metaphors.
Python programs to not copy/paste well into spreadsheets (a simple test for "2Dness").