pond’ring aloud: I wonder if the problem with VPLs is the word “language”. It appears to me that the word “programming” has been generally accepted to mean “sequential language” or writing sequential codes (aka “coding”). I view this view as being too restrictive. Programming is more than just commanding a machine with sequentialistic instructions. Programming a CPU, though, is - by definition - sequentialistic. But,,, programming a machine(s) need not be sequentialistic. Especially in the age of nothing-is-central. In fact, LLMs are an example of non-sequentialism. The machines that run LLMs were programmed, arduously, in sequential notation, but, the inner success of LLMs is not sequential, but something else (massively parallel plinko?). VPLs and DPLs are, to me, not sequentialistic things. Maybe they should be called “notations” instead of “languages”? VNP and DNP? Visual Notation for Programming, Diagrammatic Notation for Programming? [In which case, “programming languages” as we know them, are TNPs - Textual Notations for Programming]. In fact, programming is not the difficult part. Re-programming is the novel aspect of Design that computers bring to the world. We have been programming machines to do single things for centuries (using metal lathes, etc.). This time through, though, we have built machines capable of doing many things.

On one end of the spectrum we have dumb machines, where we use “language” to make it do things, on the other end of the spectrum, we have human beings, we use “X” to make them do things. I think we need to find a word between “language” and “X”

observation: Electrical Engineers create 2 manifestations of each circuit. (1) is the circuit itself and (2) a schematic on paper for other Engineers to read. You can understand (1), but you have to spend time to reverse-engineer what’s there. #2 is (usually) more useful in communicating to other Engineers what is going on, without needing them to reverse engineer the actual circuit #1. You still have to spend a few years in university to understand #2, but, once you learn how to read #2, you can devise circuits and show other Engineers what you intended to accomplish. Likewise, Structural Engineers build bridges with bolts and I-beams, and built human-understandable drawings using blueprints. Programmers are trying to squeeze both #1 and #2 into the same notation. AFAICT, concern #1 usually wins and programmers have to spend time reverse-engineering code, since #2 doesn’t exist. In programming, programmers should be able to create #1 from #2, but, instead programmers create #1 from #1 and leave #2 mostly unaddressed.

@guitarvydas Programmers squeeze #1 and #2 together, only if you consider the code to be the product. However, what if you consider the (running) program the actual product? Wouldn’t that put programmers back in line with electrical and structural engineers? A schematic or a blueprint are a state description optimized for legibility, so there is complexity missing, which is present in the instantiation of the schematic or blueprint in the real world. I believe the same could be said about the process description of an algorithm, which leaves out the actual values that are processed when the program runs.

@guitarvydas love your thoughts here! I try to use “notation” (or “executable notation”) as a replacement for “programming language” these days. It’s more inclusive to non-textual programming languages and alternative paradigms of computing. You might also like “diagrammatic” from https://github.com/Little-Languages/reading-club/blob/main/topics/visual%20notation%20and%20diagrams/Trace%2C%20Writing%2C%20Diagram-%20Reflections%20on%20Spatiality%2C%20Intuition%2C%20Graphical%20Practices%20and%20Thinking.pdf

@Stefan Good point. In reading your reply, I begin to wonder if there’s something between #1 and #2 (#1.5?) in software that isn’t there in other kinds of engineering. I don’t think that programmers are doing a good job of communicating to other programmers what their Design Intent (DI) is…

The closest to a design intent would be a formal specification.

@guitarvydas The only difference I see between electrical/structural engineers and programmers in this example is that the former create state descriptions (blueprints), whereas the latter create process descriptions (recipes). • State descriptions are declarative and describe the spatial structure of the result. • Process descriptions are imperative and describe the temporal behavior of how to generate a result. But both are generalizable in the sense that they are both abstract descriptions, leaving out detail. I suspect what makes them feel qualitatively different is the cross-over from temporal to spatial domain in one that’s missing in the other. When programmers have to inspect the actual result — the running program in a debugger that makes state visible — then they “have arrived” on the same level the electrical/structural engineers operate at. But usually programmers describe the thing that “builds” the thing, whereas engineers build the thing. (Which is why I asked previously To build or not to build?) “But what about declarative programming languages?” While they tend to describe results and are less concerned about the process, they are still ultimately generative — they generate a result from specific input (functional programming) or from axioms (logical programming). (I’m just thinking out loud because I just read Out of the Tar Pit again and thought I try applying what I learned…)

@Konrad Hinsen Formal specifications are too flat (not layered) and too detailed and too ivory-tower. Comments are disconnected and become misleading. I hope to prove that we can do better.

@guitarvydas I fully agree that the state of formal methods today needs some serious improvement. There are some good ideas for getting out of the ivory tower in by Shriram Krishnamurthi. As for flatness, that's something I write about in my submission to Onwards! Essays this year. And something I am working on under the title "Digital Scientific Notations", which are just formal specifications under another name and with a different intent.

@Konrad Hinsen I’m watching this talk and loving it, meanwhile thinking … The description (including words like “verification”, “view” and, even, “moldable development”) makes me think that the emphasis is on understanding programs /after/-the-fact (that’s my impression, even if it’s incorrect). Yes, the claims of usability made in papers are not being subjected to fundamental testing for veracity. Yes, the programming community tends to ignore research in other fields. FYI, my interest is in devising notations /before/-the-fact and using specific notations to solve specific problems. Revelation (a): we don’t need to use text for every notation - our current tech likes to parse text, but, many syntactic elements (e.g. drawings) can be reduced to text (e.g. XML) before parsing by machines ; in fact, text and function-based notation is horrible in many situations, (b) ensuring total decoupling and isolation makes this a lot easier (i.e. what I call “0D”) and makes it possible to fight flatness (by enabling layering) (c) using OhmJS (or, its ancestor PEG (or ESRAP in CL)) and Ohm-editor, makes it a /lot/ easier to imagine whipping up new, specific notations in only a few hours.

My understanding is that this video presents the beginning of a new line of research, so what you find missing may still come. But yes, it's firmly in the "language" (meaning text) paradigm, in spite of the graphical views in an added layer.

I feel the word “language” is problematic not just for VPLs but for PLs in general. We should be thinking about programmable systems. For instance Unix is a programming system with a popular workflow being as follows: write a program in a PL (usually plain text), compile it into an executable, run the executable as a process, which then modifies some state typically organized in files. The study of PLs is honed in on one aspect of this specific workflow and looks at everything through that lens. By expanding the scope to systems, we can start talking about other workflows of interactions, including things like liveness and notation (great word, btw). Here’s a great starting point that breaks apart these dimensions of programming systems: https://2021-assets.programming-conference.org/conversations-starters/prog21-tech-dims.pdf

That folks synonimise programming with programming languages is hugely distorting. The most successful non-programmer programming systems are Excel and end-user databases like FileMaker and access. Excel has declarative formulas but much of the programming is in the structure of the spreadsheets. A relational database with a strong user-modifiable UI is a great way of solving problems that would otherwise need a programmer. Our whole industry has almost ignored the Relational Model because it has been synonimised with the execrable SQL. I am working toward a system that resembles FileMaker but that brings in any and all data that I can into the same UI. Imagine FileMaker but there are relations representing your calendar, your filesystem, your email and social media feeds, a vast array of online data sources and services, all in one UI and freely joinable etc. This is the way to enable non-programmers to solve their computing problems. I would throw in regular programming also, but a relational query interface over everything just solves so many problems.

I would throw in regular programming also, but a relational query interface over everything just solves so many problems.

Agreed. Prolog and miniKanren seem useful in this respect. Yet, relational languages do not solve - cleanly - the problems of (a) formatting a string (JavaScript does it better than relational languages :-), (b) parsing text (OhmJS / PEG does it better), (c) etc. I argue that we need to compose programs using many languages, each tuned for specific purposes (paradigms). The idea of “one language to rule them all” is a chimera.

Agreed. My point here is that we know how to make a non-programmer friendly relational query interface. We can move much more of what we now do in Turing Complete languages into a relational system instead. We should also make programming better. But reducing the surface area of what we are doing in TC programming by moving as much of it out of there as is practical is another part of the Future of Coding.