[DonaldFisk]

Me.

I'm working on Full Metal Jacket, a strongly-typed, visual, pure dataflow language (http://web.onetel.com/~hibou/fmj/FMJ.html) with its own IDE.

Things have advanced a fair bit since I wrote those pages, and published the recent paper, so I'll add to the tutorials very soon, and announce this in Hacker News. Type definition, macros, and a few other things have been added to the language.

.303 shared-source release approaches, but I don't do deadlines.

No battle plan survives contact with the enemy, but I have some ideas for future directions, including adding dependent types, running on a multi-core machine with speculative execution, and automatic programming (i.e. user supplies just inputs and outputs). Very long-term ideas involve a developing a variant of the language which enables programs to run backwards, to enable execution on a gated quantum computer.

[pshc]

I'm working on something slightly similar.

But I'm sticking with the keyboard. And the "visuals" will still be text, with the option of other visualizations. Keyboard+text scales better than anything else.

[quadrature]

neat, would be cool to have some pictures on the front page.

[kecks]

Wow, that's oddly similar to an idea I've been playing with.

Who do you see as the core users of these tools?

[mej10]

A lot of people creating multimedia works use visual programming languages that have dataflow models.

Some that are fairly mature projects:

vvvv - https://vvvv.org/

Puredata - https://cycling74.com/products/max/

Max MSP - https://puredata.info/

[qzxvwt]

Am I wrong to think about the "graphical" aspect of visual programming languages as another layer of abstraction? If this is the case, doesn't that take some power away from these users, in the sense that their capabilities are limited to the abstractions/interface given to them by the language's developers?

Not exactly trying to question whether it's a good/bad thing (as I'm aware that for many creators this might be exactly what they need), just trying to understand.

[kecks]

No, because every language has one specific set of abstractions and interfaces chosen by the language's developers. This is the same for textual and visual programming languages alike.

What might well be very hard is making a language where all abstractions and interfaces map to useful graphical representations; I imagine it's much, much easier to represent a JSON object graphically than it is to represent a piece of C code this way.

For instance, how would jumps look? Lines going from far-removed boxes, producing code that literally looks like spaghetti? Moreso, do you even want to graphically represent things like pointer arithmetic, will this be easier to work with? How do you represent variables, globals?

Maybe you would only represent course features such as data flow graphically, and hide finer grained details and code in "blocks" with labels and defined in- and outputs. You would still mostly write your code, but the graphical view might help you mentally model your program.

[seanmcdirmid]

Actually, the graphical aspect of a visual programming language is often an "un-abstraction." Text is pure abstraction with little static context beyond names. VPLs often attempt to provide more context by (a) mixing in execution context (like in Quartz Composer) and (b) through direct mappings to the domain (e.g. a VPL for layout that has you manipulating layouts directly). Much of the usability benefits, as well as scaling problems, that arise in VPLs is due to trying to them trying to be less abstract.

[DonaldFisk]

It doesn't have to be just another abstraction layer. In Full Metal Jacket, there's no underlying human-readable text-based language. The abstract machine it's designed to run on is highly-concurrent (MIMD) dataflow, which is very different from the von-Neumann architecture. You can represent concurrency visually better and more clearly than textually, though a few dataflow-based textual languages exist such as SISAL.

At present, FMJ is interpreted and runs on a virtual dataflow machine. This was a necessary step to ensure the computation model was implemented accurately. Compilation to run on a single processor would actually be simplified, however: there's no parsing or dataflow analysis required. Looking into the future, the question that should really be asked is whether languages designed to run on a single processor, or to execute the same instructions in parallel (SIMD), can be easily adapted to run on MIMD architectures. Do you really want to be using MPI?

[bonobo3000]

Most languages compile the source to an AST, so I would say the AST is one level of abstraction below source code. Then, text and graphical languages could be equally powerful if each can represent any AST the other can.

[mej10]

I have done some programming in these and they are definitely more suited to the applications that their creators had in mind.

I wouldn't want to do general purpose programming in them -- at least as they exist currently.

[DonaldFisk]

Full Metal Jacket is general-purpose. Doing general-purpose programming in it does, however, has required me to think very differently. At present, it's still easier for me to program in Lisp, but that's mostly down to being a very experienced Lisp programmer and a rookie FMJ programmer. Initial difficulties are inevitable when you learn a new programming language different from the languages you already know. I had similar issues with Prolog but mastered that.

Different general-purpose languages are better adapted to different programming tasks, however, and Full Metal Jacket may in time find its niche. I wouldn't write a neural network in Prolog, or an expert system in C, for example.

[mej10]

Just noticed I switched up the PureData and Max MSP links. whoops!

[borplk]

Hat off to you, very interesting. Keep up the great work.