Text is a graphical, visual representation. While there are sometimes alternate ways of expressing things, this idea that text is not visual is weird. "Non-textual" representations is better, because we already have a rich, complex capability in good ole symbols.
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.
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.
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.)
that sounds like a cool way of seeing things, could you explain what dimensions you're referring to?
That make sense?
Everything we can see is visual in that regard. That's what not "visual" in visual programming (or visual diagram etc) means.
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.
> 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.
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.
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.
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
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 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.
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".
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". 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.
 "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."
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 ;)
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.
This is called "mathematical notation".