One way to categorize FoC projects is to consider the following spectrum. (Go with me here — resist the urge to treat this as a multidimensional space.) In the center, we have projects that resemble typical programming languages. These tools are designed with particular semantics that the programmer will employ to structure their problem solving. They are general purpose. They don't have much regard for the particular kinds of problems being solved. This is your Java, Clojure, Vulkan, brainfuck, etc. Off to one side, you have programming tools that have both tightly defined semantics and a focus on solving particular kinds of problems. These are specialized. This is Excel, Notion, Max/MSP, OpenGL, bash, etc. Off to the other side, we have programming tools that, while they still have semantics, don't expect you to work entirely within those semantics. They have even less regard for the problem domain. These are tools that expect you to first build some new tools from or within them, then solve your problem with those tools. This is Racket, and arguably REST, RDF, stored procedures in a DB, and other things. Now my question: are you building an FoC project that falls into the latter category? If so, talk about that a bit. What's the rationale?

One important aspect of what I want to build, is the possibility for the users to define their own visual representations for their programming artifacts. Of course the programming environment will come with some visual semantics as building blocks or general tools, but I would like to allow anybody to add new one. The idea is that the history of visual programming is full of unsuccessful attempts (for an "incomplete"/old list see for example: http://blog.interfacevision.com/design/design-visual-progarmming-languages-snapshots/). So I feel that finding and designing the "good one" from start is quite hard and will most certainly miss essentials features. So I want to provide some core functionalities that are enough to build complete things but also let some other visual tools emerge from actual usages. This idea is in fact at the core of my project.

I’m having a hard time resisting that urge to at least turn this into a 2-by-2, but ok… I’ll play by the rules. Given that spectrum I guess I fall into the latter extreme, because I think the power that programming gives to programmers is to improve their own process and often through building their own tools (albeit “tool” here can have a much broader definition). If you can program, you can make computers do things that regular people can’t make them do. To democratize access to that power, a great alternative to teaching everybody how to code is to instead make building things easier. And I still believe that is very much possible, because we currently live deep in just one specific branch of the solution space which was strongly influenced by the needs to not just create things, but to satisfy certain success metrics (revenue, popularity, engagement, etc.). That’s why we can find so many promising ideas closer to the trunk of the tree in the papers of the 60-80s, when using computers was much closer to programming them, and when visions were mostly driven by imagination and less warped by specific incentives. The most important reason for giving people the power to build their own tools instead of building them for them is that they know what they need best and I will never be as good as them to really understand what they really want or need. They might not understand it fully themselves. That’s why they need to build it themselves. They need to invent it themselves. They need to discover solutions on their own. And to do so, they need to have the power to do that. And that needs to be simpler than it is today.

i’m trying to build the latter but i’m trying to make it explicitly feel like the opposite side, where the problem domain is the transformation of data over time. hard to describe with words but i’ll give it a shot: if your tools let you describe and transform structured data, and they can take unstructured data and turn it into data, and you describe those transformations and build the tool in the same data format, then you should be able to use the tool on itself to make the tool look like your domain

@ogadaki

One important aspect of what I want to build, is the possibility for the users to define their own visual representations for their programming artifacts. Of course the programming environment will come with some visual semantics as building blocks or general tools, but I would like to allow anybody to add new one

When the user defines a new visual representation, is that like defining a new datatype or function, or is it more like defining a new paradigm or means of evaluation — new semantics — like imperative, FP, stack-based, CSP, eager-vs-lazy, curried, etc.?

Ivan, it is exactly what I have in mind and what I want to build: an environment that provides tools to allow the definition of visual representations and how these representations are used to produced a behavior. Even if it can stay at the "new datatype or function" definition level, the real plus is to allow the user to tell what to do with the information in the visual representation. So, one can define some nodes and wires representation for a build system, where rounded boxes defines files, squared boxes for bash building rules and links for dependencies, and that this produces a

Makefile

. Someone else might use something similar but to produce a

.gitlab-ci.yml

file. And a third one will have the rules in something else than bash (maybe another visual?) and that it is plugged directly to a "live" customed building system (maybe a serverless infra).

If I understand it correctly, that's all stuff you could do with a programming language like C or Java, right? In your system, the programmer defines some data or a function and binds it to a certain graphic ("rounded boxes defines files, squared boxes for bash building rules"), which is akin to binding symbols/identifiers to functions or data in a text PL, and then the programer decides which of those graphics to invoke in various contexts and at various times ("links for dependencies") much like writing the main() function. That means what you're designing will be a peer to a traditional general purpose programming languages, whereas most visual languages currently aren't even designed to be that powerful. But what you can't do within C or Java is change their semantics. You can't change the way code is executed, not without changing the compiler/interpreter (at which point, you're no longer making a typical C or Java program that'd work with any C compiler or JVM). You can't turn C into a lazy evaluated language. At best, you can use C to create a new language that is lazy evaluated. An example in a hypothetical visual language where code is tree-structured would be: can you, working entirely within the language, decide whether execution is "pushed" from the root node down, reevaluating every node as it goes, or whether execution is "pulled", starting from a leaf and evaluating back up to the root? Another example — a visual programming environment in which you can define the "grammar" and how it's parsed. So you could build an execution strategy that makes use of color, or that makes use of proximity, or that makes use of the fineness of detail. You aren't saying "round boxes represent files", but rather "roundness of corners is a semantic detail, so whenever a corner is rounded, here's how to interpret that". For instance, you could say that shapes should be evaluated in order of roundness: circles come first, roundrects second, and boxes last. Another example — a node-and-wire environment where you can control whether edges simply associate something on one end with something on the other end (as like a function call), or mutably remove a value from storage on one side and insert it into storage on the other side (as like an inbox/outbox), or are themselves mutable storage (as like a queue). I think what you've described is a big improvement on what currently exists. But it doesn't feel like it fits the (admittedly, very poorly defined) region of concept space I'm trying to map out. I wish I had better theoretical PL chops so I could know what, if any, terminology to use here.

i don’t know if there are specific terms for that but it’s exactly what VPRI was working on

First, I must say that as I haven't yet actually worked on all this, I have not a precise vision of how this will work, and maybe the examples are not very well chosen/realistic/etc. But the idea is really to try to give the maximum opportunities to users to define some visual representations and what they means in terms of behaviors. So ultimately, all your examples are really good illustrations of the kind of things I would like to allow the users to do. I agree, my examples are too simple: only mapping visuals to text languages, I definitely want to go further!

link spam (none of these are visual, unfortunately): • open, extensible composition models: http://www.vpri.org/pdf/tr2011002_oecm.pdf • open, extensible object models: https://www.piumarta.com/software/cola/objmodel2.pdf • the reflective language Black by Kenichi Asai: http://pllab.is.ocha.ac.jp/~asai/Black/ • some pretty cool video content on this subject by Nada Amin: • another one on towers of interpreters: • red/rebol programming language (this is not well documented. if anyone wants to go on a hunt i’m looking for study partners): https://www.red-lang.org/ • in particular: its weird binding methodology https://en.wikibooks.org/wiki/Rebol_Programming/Advanced/Bindology (rebol and red are very similar) • the kernel programming language: https://web.cs.wpi.edu/~jshutt/kernel.html • the io programming language: https://iolanguage.org/ • the ioke programming language: https://ioke.org/ • the factor programming language: https://factorcode.org/ • especially the “parsing words” section here: https://andreaferretti.github.io/factor-tutorial/

trying to figure out a good visual representation [...] i don’t know what to call them

This dissonance is delightful.

“link spam”—and dissonance is the house i live in, baby

Not sure if I'm getting it right, but I don't think these are programming 'tools' as much as they are 'programming material'. These could allow a fair bit of diversity in not just what kinds of tools emerge but what kinds of paradigms emerge as well. The main thing is whatever is built on top can be mapped back into the 'material view' where you just look at the built system through a view showing 'blobs of the original material'. Would you say Unix is such material - (tends to be flexible in terms of what the static structures and dynamic processes mean). Unix with byte files and OS processes provides some structure for static/dynamic structures but within that we have a wide variety of programming paradigms. Another example maybe could be apparatus? (http://aprt.us/)

Yeah, I think "programming material" is a good hand-wave to throw into the dance we've got going.

The main thing is whatever is built on top can be mapped back into the 'material view' where you just look at the built system through a view showing 'blobs of the original material'.

I mean, that'd be cool, but it depends what one's goals are. That's why I'm curious to see what folks here are doing that might fit this jello mold (as in a mold made of jello) — what rationale might one have for wanting to force so much responsibility onto the user? Yeah, Unix probably counts as something like this, in that it's a "thing that sits under my compiler and generally doesn't force my compiler into a particular paradigm". But on the other hand, it's not exactly like you are building your language paradigms out of the pieces unix provides. Unix is just there to facilitate reading, writing, and executing. So in that sense, it might even be too far to that latter extreme of the spectrum. I think the VPRI connection was the best fit, so far, for what I have in mind. So — who here is taking another crack at that chestnut?

OK I got a couple of more terms that might be of interest: Language Workbench and Language oriented programming: https://en.wikipedia.org/wiki/Language_workbench (you said Racket and Racket is an example on page, so..)

ah, i found a better link for Red: https://www.red-lang.org/2013/11/041-introducing-parse.html#:~:text=It%20is%20an%20embedded%20DSL,implementing%20embedded%20and%20external%20DSLs. the parse dialect is really where it starts to shine IMO

I also like a lot "programming material". It conveys the good meaning: some things that can be used/assembled/combined for programming, without being to precise about its origin which can exist a priori or that can be set up on need.

@shalabh Wondering if your term "programming material" is an explicit reference to Alan Kay's comment about Lisp not being a language but building material.

@Konrad Hinsen that wasn't in my active memory, but I have heard that quote.

what rationale might one have for wanting to force so much responsibility onto the user?

In my vision, the idea is not to force the user but instead give this ability to those who want/need it. I.e mainly power users. And once a user has create an expressive visual representation it can be shared to other users that can use it without having to take this "responsability".

I'm also on the latter end of the spectrum. I want to provide means for whatever the programmer (or user) is making to be represented in whatever form (e.g. visual or otherwise) is desired, with whatever semantics, and even editor-behaviors. And all the same for the tool itself, as it's its own live-editor. I'll do this by providing a model (e.g. direct manipulation entities), and having the live code of the tool itself exposed for direct manipulation within that same model, so that anything about it (down to the metal if desired) could be altered (the rendering, the execution model, the data model, etc.). The point is to bootstrap the incredible power of programming, onto programming itself, with immediate turn around / feedback. And if the initial tool for doing so sucks (e.g. if only I could just drag like this to change that), then change it. If the means for changing how you change that sucks ... well there's no endless tower because it's all live implemented in itself; it's a closed loop.

@Dan Cook I fully agree with you!

I dream of making a language in the last category, where 1. The syntax is switchable (plug in a parser you want), syntax conversions are plausible, and multiple syntaxes can be used in a single proram 2. The semantics are customizable (e.g. the concept of a "function call" is broken down into parts that can be customized) and multiple semantics can be combined in a single program... 3. The language is designed to support and encourage "parameterized" libraries, whose exact behavior and interface can be customized by a user of the library (e.g. libraries that let you select between different kinds of floating-point math after-the-fact, instead of hard-coding

float

or

double

) 4. The standard library is designed to evolve over time by supporting "skinnable" types. A simple example would be that in version 1.0 we have

Array.shift

and

Array.unshift

, but in a later version we decide those were terrible names and change them to

Array.popFirst

and

Array.pushFirst

- but old code can use the old names by continuing to import the older "skin" of the

Array

type. 5. Advanced metaprogramming including compile-time code execution is supported I want a language that takes the best ideas around and combines them with my own ideas ... an ultimate language. The really key part, which is maybe the hardest thing to get right, is to set it up so that some of the best features of the language can be designed and built by other people, because the foundation is good enough to make this possible.

@David Piepgrass - There might be some overlap / similarity between what you described, and @François-René Rideau's "first class implementations"