I'm particularly struck by this thread of images of "apps" generated by Mikael Brockman using Midjourney. No, this isn't a link to a parser library or a tech conference or a blog post about concatenative langs. But to me this is just as interesting and relevant when pondering what the future of programming ought to be. For instance, one could think about borrowing this aesthetic, or an aesthetic. What would it take for a code visualization to make use of detailed geometry and lighting/shading/depth cues and other expressively artistic aspects like the ones on display here? At the moment, code "visualizations" tend to consist of line graphs, grids of numbers, flat little circles with text centred in them, straight lines or simple s-curves, all rendered without light. The way we visualize code isn't even, like, Gourad shaded. And here we see something that crams incredible detail and depth into every pixel. The images themselves aren't of interest — if someone wants to make a programming language out of skulls and leaves and reefs, my god, go as hard as you can! But for my money, it's the way these _semi-_abstract shapes are given an impression of tactility and physicality that interests me most. Another angle would be to think about the process. Mikael generated these images using an AI. I find myself wondering "what if this aesthetic, but for structured data?" (When I say "structured data", I mean source code, cyclomatics, spreadsheets, pages in a book, ASTs, whatever you want.) Perhaps one way to approach answering that question would be exploring the space with the help of an AI. You don't need to come up with something perfect, just something worth running with. We're programmers, so we have a sense of what structured data is in our bones. That probably limits our thinking. It helps to get someone outside the field, someone whose bones are data-hollow, to reflect your thoughts back at you in their own language. I'm sure one of the Oblique Strategies is "Ask an AI to do it".

This is something I’ve been thinking about a lot as well. I hate the feel of the visualizations I produce. I would love to produce something this visually interesting. I have to admit, I just lack the artistic ability. I have lots of data and lots of time. If some wants to collaborate on this let me know.

Shading, or anything that suggests continuous space as opposed to discrete components, is likely to remain surplus to requirements for the most part. :) Continuous/smooth features belong to a world where objects matter proportionally to their size (yes, not always, but the counterexamples are notable for their rarity), which is emphatically not the case for anything close to math or logic. Which is not to say you couldn't employ it for aesthetic purposes, but I can't think of how you would use high-res detail like that for representing the semantics of a program. (There are those digram heatmaps you see in binary analysis and the like, but I'd put those in a different category, certainly more syntactic). To be a little more precise, it will be hard to make small details meaningful in proportion to their visual weight, neither too small (hiding things) or too big (distracting). Similar for 2d topology vs whatever passes for topology in a program. Maybe that's an angle to approach the question: how do you visually represent something small but impactful like a logical negation? A region with visually changed properties, maybe different color? You could use visual texture as an information channel in a broadly discrete visualization, in a similar role to color. Definitely needs a careful hand to avoid horrible visual clashing, but if you're really clever you might even be able to weaponize it to make bad patterns look bad. Organic-looking shapes would be cool, no clarity problem as long as they're distinct. Is there a way to make subtle changes in the outline of an object meaningful? My FSM node is kind of bean-shaped because... something. Visual media are really high-bandwidth, and programs are pretty low-bandwidth. The way you get lots of data from a small program is by running it, maybe a bunch of times, so maybe incorporating runtime data into the visualization is the key. When you look at the code, you're also looking at all possible runs/outputs. Flame graphs are already in that region, but still resolutely rectangle-based. Only marginally related: I would like to see a continuous visualization for music/audio creation, where you sort of paint in (time, frequency) space, e.g. chords are parallel lines running along time. I feel like that has to exist, right?

Andrew, you make good points about "hard to make small details meaningful in proportion to their visual weight." The trick with any good visualization is making important features of the domain pop in the diagram. When you say "[size] emphatically [does not matter] for anything close to math or logic," I can only assume you have in mind the fact that a small change to an expression "like a logical negation" has a big impact. However, if the visualization is faithful to the effect on, say the shape of possible runs of a program, then a negation can cause part of that shape to change significantly. As for non-aesthetic smoothing, well the simplest example I can think of is using a line of best fit as a summary for a bunch of datapoints. In cases of strong correlation, you can mostly ignore underlying points. I've got a good musical example handy of the interplay of continuity, aesthetics, and emphasized dimensions. Here smalin diagrams a performance of the Art of Fugue, which has, more or less, one repeating structure subject, primarily using a fancy piano roll with horizontal for time, vertical for pitch, and color for voice. Sometimes the subject is delimited using a sort of axis L. Starting at 10046, he tries something a little different.

@wtaysom Re: continuous visualisations not being appropriate. I think what @Andrew F meant was that a function from logical expressions into logical expressions (notably the substitution function) is not continuous (whatever it means, you'd have to provide a metric on logical expressions). Since programming as done today is performed basically only using substitution (everything can be modelled by untyped lambda calculus), there's no point in trying to make visualisations continuous. Therefore, it makes more sense to give the colours more of an "algebraic" meaning, which I think is what he describes in the mid-to-latter part.

"There's no point in trying to make visualizations continuous" Why not? Why limit oneself?

I meant: "Trying to make the function (which visualises program features) continuous." (In the mathematical sense; the function is taken to be from expressions and expression transformations to a 2D space with smooth colours)

To be clear, even if it does turn out that visualizations similar those above don't work out, we should still try to come up with counter examples. :) Another approach: what kinds of useful information exists about structured data that can be expressed in such a detailed, real-number-oriented way? Statistical summary is an interesting angle for structured data, like @wtaysom mentioned with regression. Summary, being inherently lossy but still useful, seems like a good way to get useful fuzzy data from structured data. Like if the representation of a database table gave you a pretty good idea of the distributions of its columns. Can you have a good graphical representation of the row that just stacks in the z-axis (with transparency) to get a passable summary? Can something like that work for less regular structures? (Of course this kind of merges with showing summarized runtime results if it goes far enough.)

Question: What do you see this syntax being compiled-to for a digital computer? Orthogonal brainstorming: Then, there’s the forgotten form of computing called Analogue Computing. I wonder if this syntax has application to analogue computing? If so, what operations does this syntax represent?

Yes! Analog computing where the essential feature is that features of the mechanism match the domain. Rather than connections being symbolic and arbitrary, they have to be intrinsic and, well, analogous. So I don’t think the essence of analog is the quality of being contiguous rather than discrete.

aside: The Nyquist Sampling Theorem says that you have to sample at at least 2x the speed at which the thing is changing state. Practically, if the thing changes state much, much faster than you are sampling, the thing looks like it is continuous. Analogy: a Retina display has many more digital pixels than your wetware can distinguish ; vinyl is better than MP3 because vinyl packs more data into a unit of sound-space (I guess that FLAC is a digital attempt to compete with vinyl). aside: Ironically, transistors were first used for analog circuitry (e.g. audio amplifiers). Transistors have a “linear region” which is used in analog circuitry. If you slam transistors to be ON or OFF, they are said to be operating in their “non-linear” region and you get 1's and 0's

Thinking about the kinds of infovis, I like best. This XKCD nails it. https://xkcd.com/2701/

Yes! Any problem can be viewed from multiple perspectives. Some views are more fruitful than others. How do you know which views to use? You don’t. Experts, Senior Architects, Senior Engineers know which views to use. How do Experts know this? 1. Trial-and-error over the years. 2. Apprenticing with Experts who preceded them. Can a machine figure out which views are the best? No. A machine cannot figure out which views are the best. Only an Expert can tell you which views to use. A machine is but a tool. An expert can specify which knobs to put on a machine and how much to turn each knob to achieve the most fruitful perspectives, but, the machine can’t figure out how to do this by itself. The 2022++ computer medium is like a piece of paper and a pencil. In the right hands it can convey a great deal of meaning. In fact, 2022++ computers allow humans - for the first time?- to explore and visualize issues in 4 dimensions - x/y/z/t. Paper and pencil and clay tablets forced humans to collapse 4D concepts down to 2D for the sake of the written notation. How does all of this manifest itself in Software and Programming? For starters, we might use multiple languages for any problem. Nano-languages - I call them SCNs (Solution Centric Notations). Examples: • one view of computers is “everything is a byte” - the notation is C • one view of computers is “everything is a string” - the notation is Perl, Icon, SNOBOL, Tcl/Tk, etc. • one view of computers is “everything is a browsable web page” - the notation is HTML • one view of software is “everything is a hierarchical wrapper” - the notation is Smalltalk (OO) • one view of software is “everything is a function” - the notation is FP, Lambda Calculus, etc. • one view of software is “everything has state” - the notation is StateCharts, Actors • one view is that “history matters, sequencing matters” - the notation is state machines - the anti-notation for this is functional notation, which outright discards history • one view of programming is “everything is a sequential set of functions” - the notation is FP and written mathematics • one view of programming is “everything is an asynchronous Component” - the notation is FBP, Actors, UNIX shell pipelines, ė[^eh], etc. [^eh]: I happen to be interested in exploring the rathole of asynchronous, pluggable Components. I am exploring a notation/functionality/IDE/... that I call ė. I think that I have isolated some sub-atomic particles of concurrency and call the main one “0D”. Conclusion: Don’t try to guess, let the Experts tell you which Views to use. How? Find a way to allow Experts to create views - SCNs - quickly (in minutes instead of in years). Recursive Q: what is a fruitful view of the problem of how to let Experts create SCNs easily and quickly? A: Create multiple grammars to drape multiple syntaxes over various paradigms, let Experts reach into a toolbox to let them pull out and use bits and pieces of useful functionality. Suggestion: 1. use Ohm-JS for creating syntaxes 2. use Lisp as the toolbox[^js] 3. use debuggers, honed by Experts over the years[^debuggers] 4. build software as pluggable Components[^0d] [^js]: Aside: if you have an allergy to using Lisp, I have found that JavaScript and Python work acceptably, too, as toolbox languages (except for their pesky syntaxes) [^debuggers]: After all, the Experts in debugging have determined - by trial-and-error, and, by listening to customer demands, and, by learning from others - what works best when debugging and what doesn’t work when debugging. [^0d]: 0D, IMO, is the secret sauce of Componentizing software LispWorks is a better debugger than SBCL. SBCL is a better debugger than VSCODE. Iterative design is better than waterfall design. Debugging is a better way to design something than just inventing all of it in one fell swoop without a debugger and without iteration. Optimization should be applied only after-the-fact to a working design (i.e. eschew “premature optimization”). Type checking mainly helps when optimizing (it attempts to guarantee that the optimized code faithfully represents the original design, but, it gets in the way of free-thinking during Design). Ohm-JS is better than PEG. PEG is better than Language Theoretical compiler generators (e.g. YACC, LR(k), etc., etc.). Lisp and Assembler share common traits: • expression language • easy to bolt pieces together to make bigger pieces • Assembler pieces are arranged as lines of text • Lisp pieces are arranged as recursive trees of Atoms and trees (tree is also known as list) • lack of pesky syntax (you don’t want your toolbox language to have an opinion about which syntax/view you need to be using). Maybe there are other languages that have these traits? I don’t know. OTOH Lisp (and Assembler) has been around for looong time and Experts have tuned it to be a good toolbox. And, I am comfortable with Lisp. FP has been around a loooong time, too, in the form of written mathematics. In fact, Lisp was based on mathematical notation. Computer hardware goes beyond what can easily be described using written mathematics, e.g. history (sequencing, DAWs, iMovie, robotics, blockchain protocols, IoT, etc.), mutation (RAM), asynchonosity (non-von-Neumann architectures), etc. It should be noted that FP is simply one notation that can be fruitfully used to describe computer programming. There are other notations that fruitfully describe non-FP aspects of computers better than FP can describe them. Claiming that one notation is The Best notation is a common human behaviour. It is so common, that it has been given a name - “fad”. IMO, it is fruitless to continue inventing new languages and amazing features as one-shot deals. We need to invent new ways to invent new languages quickly (i.e. in minutes). We need to solve problems by inventing multiple SCNs (nano-languages) for the various views of problems. We need to use multiple SCNs to solve little sub-problems, then bolt the solutions together into larger solutions. Recursively.