
Full Metal Jacket: A visual dataflow language (2016) - mr_tyzic
http://www.fmjlang.co.uk/fmj/FMJ.html
======
rdtsc
I have seen visual dataflow languages and even worked on some of them. They
usually work better in specific domains like stream processing, control
systems, signal processing and such. Even then, once a "program" gets complex
it can get tangled fast. A node with 3000 edges starts to look messy. There
are some things you can do to fix it but then you just kind of wish to use a
simple script.

As for general computing, the most thought out language I've seen so far is
probably
[https://en.wikipedia.org/wiki/DRAKON](https://en.wikipedia.org/wiki/DRAKON).
Apparently you can now even try it online: [https://drakonhub.com/try-
me?example=mind157](https://drakonhub.com/try-me?example=mind157)

I like Full Metal Jacket in that it starts with a functional approach (it
seems to be based on LISP) and might actually be a good way to introduce
functional programming to newcomers. For example, here you just have a
"factorial" node when you define the factorial function:
[http://www.fmjlang.co.uk/fmj/tutorials/Recursion.html](http://www.fmjlang.co.uk/fmj/tutorials/Recursion.html)
Some people really struggle with recursion initially and if they are visual
learners this might be helpful.

~~~
RantyDave
Visual effects lives breathes and eats visual languages. It's not necessarily
a good thing - people get (very) competent with them then start writing C++
using the same style namely, copy-n-paste a go go.

Refactoring fun for all the family.

~~~
coldtea
That's C++'s (and its IDE's) problem though. In visual languages copy-n-paste
is not copy and paste, it's reusing a component.

------
Eli_P
Visual representation for code has its own niches for certain.

The most newfangled thingy I've encountered is Ballerina[1], it's kind of text
<-> diagram convertible code, cloud-oriented. Looks cool; there are some codes
on github[2].

But anyways, I think it may be worthy as a domain-specific environment only.
Because as a general-purpose language, visual languages are claimed to have
improved _perceptible difficulty_ , but in general case, they don't.

Try to define perceptible difficulty, or search for implementations in code
linters, I believe it's always subjective, like max lines of code per
function. The _true_ code representation is multidimensional and
incomprehensible for a monkey brain, even if you'd made it look like a multi-
layer Manhattan-like glowing graph.

[1] [https://ballerina.io/philosophy/](https://ballerina.io/philosophy/) [2]
[https://github.com/search?q=ballerina](https://github.com/search?q=ballerina)

~~~
asn0
I'm curious how Ballerina avoids (or does it?) this problem mentioned in
another comment:

>once a "program" gets complex it can get tangled fast. A node with 3000 edges
starts to look messy.

~~~
TuringTest
That wouldn't be messier than a textual function making 3000 function calls,
or accepting 3000 parameters. The way you handle this complexity should be the
same in both cases: creating abstractions that bundle together related items,
hiding the details on a lower layer and exposing only the general ideas at the
outer level.

Unfortunately, visual languages tend to be quite poor at abstraction. We've
been developing and improving ways to make better abstractions in textual
languages for the last 50 years, but somehow visual languages seem to be using
the same abstraction tools we had with ALGOL, when not the same ones we had
with Assembler.

For a mental framework on how to analyze and design visual languages for
usability, see Cognitive Dimensions of Notations.[1][2]

[1]
[https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notati...](https://en.wikipedia.org/wiki/Cognitive_dimensions_of_notations)
[2] [https://www.uxbooth.com/articles/a-usable-guide-to-
cognitive...](https://www.uxbooth.com/articles/a-usable-guide-to-cognitive-
dimensions/)

~~~
zozbot123
> Unfortunately, visual languages tend to be quite poor at abstraction

It's not as simple as that. Visual languages tend to be _very_ good at
portraying a fairly large subset of abstractions - loosely speaking, many and
perhaps most abstractions that you'd want to model using category theory are
almost inherently "visual" \- and just not very helpful at portraying others.
I think the answer is a tighter integration of textual and visual "modes" on
the same codebase, rather than just using visual for everything no matter
what.

~~~
TuringTest
Yes, I would expect that. Algebra expressions are best written with infix
operators, rather than graphs. And data or control flows benefit from the
boxes-and-arrows representation of visual languages.

The problem is, how to decide what parts of the program ti represent as text,
which ones are better as graphs, and where to place program data values?

------
xvilka
Something like Luna[1] language looks saner - where it has both textual and
visual representation.

[1] [https://luna-lang.org/](https://luna-lang.org/)

------
ken
There's one thing here I strongly agree with:

> There is no point developing new programming languages unless they're
> radically different from existing languages.

95% of the time, any language from the past few decades would work fine for
what I'm doing, and I run into far more problems from languages changing than
from languages lacking features. (Python 3 is the poster child for this right
now, but I don't think it's even the worst offender.) One of my favorite
languages is Common Lisp, and that hasn't changed since the 1980's.

There's also something here I strongly disagree with:

> Programs are composed almost entirely with the mouse rather than keyboard,
> and type inference and other checks take place while you edit your program.

If there's one thing that's true of all programmers today, on any platform,
it's that they _love_ their keyboards. You'll never get anywhere trying to get
them to edit a program with just their mouse. Graphical programming languages
are cool, but they need to incorporate keyboard editing. Like any IDE, you
should be able to work with a mouse, but not required to. Put "graphical
representation" and "mouse-only editing" in the same boat and the latter will
sink the former.

I've known a couple programmers who hooked up foot pedals to their editors. I
know nobody who's ever written programs with just a mouse. So based on my
experience, you're going to have a tougher time selling anyone on this than if
you'd made a programming language which required you to use your feet.

~~~
nikofeyn
regarding the mouse and keyboard use in visual programming, i have used
labview extensively. with labview, one normally assumes one hand on the mouse
and another on the left side of the keyboard, which is used in a chorded
manner in that it provides modifications to what the mouse is doing. this is
common i think to other visual environments such CAD programs. then the hands
join back on the keyboard for searching and quick drop.

i think a hybrid setup like this can be powerful. it is under researched
though. i am learning emacs at the moment, which is in the pure keyboard camp.
while seemingly powerful, it does feel like a blast into the past and not so
efficient in terms of learning curve or reasoning. so all keyboard and all
mouse are a miss. i personally think a mix of keyboard, mouse, and touch is
something to be explored.

------
lincpa
The Clojure threading macro provides language-level support for The Pure
Function Pipeline Data Flow
[https://github.com/linpengcheng/PurefunctionPipelineDataflow](https://github.com/linpengcheng/PurefunctionPipelineDataflow)

------
merricksb
Discussed at the time:

[https://news.ycombinator.com/item?id=12106259](https://news.ycombinator.com/item?id=12106259)

------
Hyperborian
I'm just a few pages in to the tutorial and I already want to try it out
myself... but how? Where's the link?

Is this not available to the public yet?

~~~
scottlocklin
I'm pretty sure Labview has a free version and works better.

------
IshKebab
Looks like Labview. Nobody who has used Labview would try to recreate it.

One of the main problems I find with these type of systems, is that although
you _can_ add comments and maybe even organise your diagrams nicely, it is
such a pain to do that nobody does. You always end up with literal spaghetti
code with zero comments.

------
hjek
Looks a lot like Pd[0].

[0]: [https://puredata.info/](https://puredata.info/)

------
drivingmenuts
My first thought was “it’s Visual Lisp”. My second was that it reminded me of
an old music tracker program called Buzz Tracker. It was a bitch to learn, but
once you got a few concepts down, it was insanely powerful.

It was also pretty unstable.

~~~
bane
Sadly, the source to Buzz was lost and development stopped. A hacker community
kept it going for quite a while. It's apparently been restarted.

[http://jeskola.net/buzz/](http://jeskola.net/buzz/)

~~~
drivingmenuts
The main thing I remember about Buzz was that every time there was an update,
all the sound generators changed. If you were relying on producing a certain
sound for a certain song, you didn't dare d/l any updates.

Also, apparently the generators and effects left off some limiters when they
were trying to emulate certain synths. You could easily produce something the
original machine wasn't intended to. Personally, since I didn't know much
about hardware synths, I didn't notice. A much more knowledgable roommate
informed me and I just took his word for it.

That was fun program to work with though.

------
sidcool
This is pretty cool. I am looking for a tool that can help with visualization
of Linear Programming/Optimization problems. How constraints interact etc.
Would be pretty cool.

------
6nf
Hmmm I'm trying to picture what a debugging session with something like this
might look like... I can't decide if it would be amazing or impossible

------
ivanhoe
Considering that I spend at least 30% of my work time in the command line I
really have some doubts about these "text is obsolete" ideas.

~~~
ken
I spend at least 30% of my time in the command line, but at least 90% of that
time using it to parse complex formats before I can do what I really want to
do with my data -- or fake it (e.g., plain grep on structured data, because
properly parsing it is not well supported by any tools yet).

That doesn't tell me text is dead. It tells me text is the best we've got so
far, and we're desperate for something better.

When a C=64 was the only computer I had, I spent most of my time writing
assembly language. That wasn't evidence that assembly language was the way to
go. I just had insufficient perspective, from having to use insufficient
tools.

------
deadmanku
when you look at code it's hard to recognize. if there is a way to success of
a visual programming language that is the code should appeal more recognizable
than text.

------
theshadowknows
Funny how so much of the underlying code used to make this “keyboardless”
language was written on a keyboard. I’ll be more impressed when there’s a
“FMJ” implementation written purely in “FMJ.”

------
vectorEQ
i dont see how this is different from regular programming to be honest.
perhaps that you dont have side effects as a possibility, but i just see
someone making functions and tying them together and supplying inputs and
outputs? :/ seems super tedious to have to use the mouse, like with most
things programming related, a keyboard is generally much easier to use.

------
caymanjim
The name of this language is stupid. It evokes violence, either via the bullet
reference, or via the film of the same name. I'm not thin-skinned or even
prone to political correctness, but I still find it slightly insensitive for
no compelling reason.

Then I read the author's explanation
([http://www.fmjlang.co.uk/fmj/Name.html](http://www.fmjlang.co.uk/fmj/Name.html)),
which makes a comparison between lisp (the programming language) and
stereotypes about homosexuality (with the requisite "I have gay friends!"
disclaimer).

Maybe the author should grow up.

~~~
ravenstine
> I'm not thin-skinned

Are you sure about that? The gay thing is weird, yeah, but you basically are
thin skinned if the connection between bullets and violence is that bothersome
to you. Most people aren't that bothered by references to violence; if they
were then violent shows and movies wouldn't be the best-sellers they currently
are. What if I wrote a useful library and called it "Bomb"? Would that be
insensitive of me?

~~~
gavinpc
At least "Bomb" would be short. "Full Metal Jacket" is a dreadful name in
every sense, worsened only by the author's cringeworthy backstory. To
paraphrase the parent, it reeks of immaturity.

I "wouldn't hold that against" the tool if it had technical merit.

------
hliyan
"Text-based languages are so 20th century"

This is arguably NOT true. Visual languages have consistently failed to match,
let alone out-do textual languages for decades, and with good reason.

~~~
_wmd
Would you consider Microsoft Excel a visual language?

~~~
6nf
I'm going to say 'yes'. It's a good question and I think Excel qualifies even
though in normal use Excel shows the data but not really the logic / formulas
etc.

~~~
_wmd
Excel succeeds at its job so thoroughly that I think people fail to realize
(or cope with the realization) that spreadsheets are probably the most
successful democratized programming environment we have. It may not have been
intentional, but the 2D grid representation for data interlaced with an
acyclic dependency graph is by far superior to any alternative representation,
visual or otherwise, I can think of for either of those concepts.

Users don't even think about graphs or data, often they don't even understand
those terms. Due to this IMHO spreadsheets are pretty much peak computer
science

