while text is 2D, together with rich formatting options, program code is only 1D. have a look at the 'subtext' programming language concept that combines tables and graphs together with text based procedures, finally getting away from the constraints of program code that is designed around teletypes.

https://en.wikipedia.org/wiki/Subtext_(programming_language)

Code is always written with "indentation" and other things that demonstrate that the 2d canvas distribution of the glyphs you're expressing actually does matter for the human element. You're almost writing ASCII art. The ( ) and [ ] are even in there to evoke other visual types.

It's ultimately 1D for the computer (a string); but so is an image (which according to you would encode 2D media) and any other media expressible in a countable number of bytes.

This seems wrong. A view of your program is 1d. Conceptualizing a program is often n-dimensional. This is a large part of the difficulty. And is why some visualizations work. They effectively act as dimensional reductions, and draw on known visual metaphors.

That was exactly the point I was trying to make. If you have a 2D problem and you want to represent it in today's commonly used code you either

1) flatten it down to 1D (e.g. a table becomes a JSON array of objects)

2) move it into a higher dimensional structure like a database. Now you have two problems.

If your programming paradigm supports higher dimensions to tackle your problems, it just gives you a higher level platform to start tackling your problems. Before you could maybe deal with 4 dimensions at the same time at most, now you can deal with up to 5 or even 6 - we don't yet know what new solutions to problems smart people could come up with when being given such tools.

Just as an example, how often do you see binary logic problems in the form of complex if-then-else procedural structures - what if you could represent two decision factors in a tabular form and let the IDE work out the missing cases for you? That's one of the ideas behind subtext.

Point is I think we agree - if you think I'm fundamentally wrong I'd like to know more exactly where.

I guess I just don't agree that those are your only two options. Consider, a nested JSON structure is essentially N-dimensional. Even something as simple as a list of people is effectively multidimensional. You have the dimension of the list, and then you have the dimension of the the structure representing the people. Which, itself, my have multiple dimensions.

Consider, a large part of the literature of machine learning is talking about taking a hypercubes and consequences of most distance/volume measures. (Quickly searching, https://datascience.stackexchange.com/questions/27388/what-d... talks about this.)

> A view of your program is 1d. Conceptualizing a program is often n-dimensional.

that sounds like a cool way of seeing things, could you explain what dimensions you're referring to?

Depends on the program. Anything you use to "index" into data is effectively a dimension. This is obvious with arrays, since you can have multidimensional arrays. However, even structs can just be seen as arrays with symbolic indexes. Usually bound by a given cardinality.

That make sense?

yeah, thanks!

>this idea that text is not visual is weird.

Everything we can see is visual in that regard. That's what not "visual" in visual programming (or visual diagram etc) means.

i sure there is probably a term for this type of argument, but this seems hopelessly dismissive on the basis of some pedantic definition of visual in this context. visual programming basically already means non-textual programming. it is about searching for new syntax and paradigms of programming that break out of the idea that one needs to inform the computer with a series of lines of text. text-based programming was born out of convenience and heavily influenced by the underlying implementations. it isn't the result of any detailed study or investigation of how to best represent ideas and concepts or how to properly describe a computation.

That's not really accurate. Visual programming systems have been around for a long time and there have been many studies of programmer productivity in various languages. Those studies have shown that programmers prefer (and perform better with) the languages where they have to type the least. Dragging things around the screen or filing-in dialog boxes (property programming) is appealing to non-programmers but, in practice, seasoned developers nearly always choose text.

Visual programming hasn't taken off because it isn't as good as text for the majority of use cases. This is borne out by more than 50 years of people writing computer programs.

what isn't accurate? there has been extremely little research done in the way of visual programming in comparison to text-based programming.

> Visual programming hasn't taken off because it isn't as good as text for the majority of use cases. This is borne out by more than 50 years of people writing computer programs.

...writing computer programs with text. this bias is massive because nearly no one writes visual programs. a lot of that is due to availability of visual environments, some of which are quite expensive (e.g., labview). most of it is due to bias.

if every single computer science and computer engineering major starts of their education with being taught "this (i.e., text) is how you program and interact with computers" then that sets up a massive bias that is nigh impossible to overcome. any study that does not address this bias is flawed. hence, we have people, who have never even programmed in a visual language, proclaiming visual programming doesn't work. i constantly hear text-based programmers say "oh, visual programming is good for niche things or trivial examples, but it doesn't scale", but yet i have developed large, complex applications with visual programming environments. you know why? because i treat it as real software. i modularize. i take data abstraction seriously. i accept the dataflow paradigm as the key paradigm and build things off of that.

and that leads me to another point. the dataflow paradigm does not map well to text-based languages at all, but it is a very powerful paradigm. visual programming languages are very good at the dataflow paradigm, and so from that alone, they seem to be required if we are to efficiently program dataflow-based systems.

Scratch, the MIT visual programming environment is free. How complex of an app would you like to write with that?

Visual programming is inefficient in its use of screen or paper real estate. How many screens full of Scratch would it take to represent a complex program? Too many to realistically read or scan.

Here again, visual programming is not new. If there were some great advantage in it, it would be more widely adopted. This is a solution in search of a problem.

i completely dismiss scratch as an actual visual programming environment. i honestly don't think of it as visual programming at all because it simply takes a text-based language and replaces the syntax with blocks rather than spaces, semi-colons, brackets, etc. i personally feel it is misguided. dynamicland is more of a visual programming environment than scratch is.

so here, you are taking what amounts to a toy and something directly marketed towards children as your shining example of a visual programming language.

in my opinion, labview is the most complex, general-purpose visual programming environment, and people have clearly written rather large, complex applications with it. why isn't it adopted more? a lot of reasons, one of the biggest ones being cost. the other the association with a particular domain, but i consider it a general-purpose language. even if one gets passed that, there is still a huge bias that text is still THE way to program and interact with computers.

"Scratch" is simply a visual representation of structural editing, with the well-known advantages and drawbacks of the latter. Whether you think of that as "visual programming" is up to you, but the general use case should not be dismissed.

> i completely dismiss scratch as an actual visual programming environment.

well put, couldn't agree more, I often use scratch as an anti example of diagrammatic programming.

visual programming has this topological aspect to it (move a box around and don't change the program), and it demands compatibility with this from the underlying thing, whatever it is, state machines or stream processing functions or whatever.

labview is a great example of a practical use of it, which some relatively minor, but critical modifications you can use it for so many more applications... maybe one day statebox can fill that gap, but we have a lot to do still

I agree completely. Scratch is a snap-together UI for traditional code. Just because the programming text is embedded inside draggable blocks doesn't make it a visual language, its a different UI for a text editor. Sure, its visual, but it doesn't actually change the language at all in any way. It could be just as easily represented as text, the semantics are the same. Its a more beginner-friendly mouse-centric IDE basically.

You've made my point... All languages compile to assembly so every visual editor is just an IDE for a text-based language -- the one actually run by the computer.

That's not what I said at all. I said that Scratch is akin to writing your words on pieces of paper and then arranging them into sentences, instead of writing them as individual letters. Its a text editor that represents words and expressions as draggable boxes instead of giving you a freeform text input. You seem to be saying that since everything is essentially a turing machine, all languages are basically just an IDE for programming a turing machine.

Having a language compile to C (as many languages do) does not at all mean that writing in that language is the same as writing in C and that the compiler is essentially just an IDE or for C. Languages, visual or textual, encourage us to think in a certain way. Even though a visual language compiles down to the same thing as a textual language does not necessarily make them equivalent and certainly doesn't say anything about the kinds of problems they help you solve or the type of thinking that they encourage.

I agree it is dismissive, but disagree that it is hopelessly so. Much of the visual or "graphical" programming hype over the years comes from a lack of understanding what text is and how well it works. The core of the issue with visual programming, is that as soon as you scale to a non-trivial example, it has (almost) always fallen apart.

I actually really, really like the idea of non-textual interpretations of data and code, and use them when text is cumbersome. But they are difficult to do well. Jupyter is an excellent step in the right direction, and a reason it has taken off, I think. Albeit within the statistics subset of software development.

I think it is hopelessly dismissive to denigrate the efforts of software researchers over the past 50+ years and say that they didn't try to figure out better ways of representing ideas. There have been great minds trying to figure out a better way to describe computation. Math and textual programming languages are what they keep coming back to! However, I think we should definitely keep trying, but the basis of new efforts has to be an understanding what text (and math formula) gives us.

> The core of the issue with visual programming, is that as soon as you scale to a non-trivial example, it has (almost) always fallen apart.

people always say this, but it almost always come from people who haven't actually tried to do so or seriously programmed in a visual language before.

> comes from a lack of understanding what text is and how well it works.

i don't think that's the case at all. i am a proponent of both text-based and visual programming languages, hoping to understand hybrid approaches better. if anything, i know where text really doesn't work. for example, text-based languages are terrible at representing the dataflow paradigm and are often more complex than they need to be. visual languages are rather good at this. so we have the situation that text-based languages are terrible at dataflow and no one cares about visual languages, so the dataflow paradigm remains relatively unused, only showing up implicitly in actor-based systems and in minimal ways (simply as pipes) in functional programming languages.

> I think it is hopelessly dismissive to denigrate the efforts of software researchers over the past 50+ years and say that they didn't try to figure out better ways of representing ideas.

i don't think so at all because i really don't think they've tried to specifically understand visual paradigms. i haven't seen efforts to do so, but i would love to see examples if they exist. i have spoken to a rather well-known computer scientist at a conference, and when i mentioned my interest in visual programming, i was immediately cut off mid sentence with the exact phrase "i don't believe in it".

> this idea that text is not visual is weird.

It's worth noting, though, that text is a serial or linear way of encoding information through symbols. In that respect it inherits its structure from spoken language. The significant visual aspect of text is the forms of the glyphs. Typographers definitely do interesting visual things with text, but this hardly ever happens in programming language syntax.

On a similar note, I get annoyed when Eugenia Cheng claims that the diagrams of category theory are "visual"[1]. They are graphs of nodes and edges, which means that they convey topological information, i.e. they are not images of anything in particular. Category theorists deliberately use only a tiny, restricted set of the possibilities of drawing diagrams. If you try to get a visual artist or designer interested in the diagrams in a category theory book, they are almost certain to tell you that nothing "visual" worth mentioning is happening in those figures.

Visual culture is distinguished by its richness on expressive dimensions that text and category theory diagrams just don't have.

[1] "Visual representation has always been a strong component of my work in category theory, which is a very visually driven subject: we turn abstract ideas into diagrams and pictures, and then take those pictures seriously and reason with them."

> Visual culture is distinguished by its richness on expressive dimensions that text and category theory diagrams just don't have.

I think I understand what you mean, but I'd say this unbounded "richness" is precisely what you must avoid in a programming language. In a programming language you want constraints, not freedom. Your visual language must convey specific, unambiguous information and not be open to interpretation or confusion. A program is inherently closer to a formula than to art.

As a complete and irrelevant aside: I wouldn't assume visual artists will consider category theory diagrams artistically uninteresting. Artists are an unpredictable bunch, capable of finding beauty in the most unlikely things ;)

I'm an artist myself, so I said "almost certainly" to qualify what I believe is an almost universal opinion. I don't think category theory diagrams on the wall of a gallery would fly as visual art, though I can imagine an artist (of a more conceptual variety) referencing category theory. I'm not saying there's no possible intersection between category theory and art—just that whatever that intersection is, it's not really about the visual, because we know how constrained the language and appearance of the diagrams is.

Name-dropping category theory via including a diagram in artistic work doesn't mean that the diagram itself is visually relevant. It would essentially be functioning as a sign rather than an image. (Feynman diagrams are a totally different story.)

As far as richness goes: I don't think programming languages have to be austere. "Richness" might be a divisive term to use for it. I just mean high degree of expressiveness. Also, I guess, a high degree of elaboration. A rich type system is not necessarily a dangerously self-indulgent, inconsistent, dangerous one—it might instead be the end result of a rigorous process of elaboration according to strict criteria.

> Maybe we should spend a few thousand years coming up with a compact, information-dense manner of expressing thoughts.

This is called "mathematical notation".

It's called "writing", and mathematical notation is just a subset of that.

I wonder if something along the lines of commutative diagrams would be ideal.