Full Metal Jacket: A visual dataflow language (2016)
fmjlang.co.uk
fmjlang.co.uk
As for general computing, the most thought out language I've seen so far is probably https://en.wikipedia.org/wiki/DRAKON. Apparently you can now even try it online: 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 Some people really struggle with recursion initially and if they are visual learners this might be helpful.
http://forum.6502.org/viewtopic.php?f=8&t=2208
(Russian) video: https://www.youtube.com/watch?v=43zPp01i6So
Refactoring fun for all the family.
In my experience with both visual and textual languages, the same happens in textual languages too, except we’re trained to use software engineering principles to attempt to manage the complexity (to varying levels of success). In my (somewhat limited) experience with visual languages, if you apply those same principles (especially some of the OO ones like encapsulation) and factor things into their own functions/nodes, it’s manageable too. Whether better or worse than textual probably depends on the use case and persons comfort level with either type of language and in practice most visual code I’ve seen was not written by a programmer and therefore the author did not know the software engineering principles that would have helped keep their code manageable.
Yeah good point. I think visual languages are often used by people who haven't had experience with software engineering, and that's fine, it's one of their main selling points.
But think there is a general limitation when abstracting connection between nodes. In a programming languages, one could for example do a loop and connect an array of a thousand structs to point to some pointer. In a visual language it would be drawing thousands of connections/wires by hand between nodes. So visual languages in a way hit an abstraction ceiling if you will. In some domains it doesn't matter and there are a few trick around it, so there is room for such languages, but I am pessimistic about a general approach.
If a language doesn’t support that, then it’s probably because it was deemed unnecessary for the target users, not because of an inherent shortcoming in visual languages.
But I’ve only used a small number of visual languages (Max/msp and Synthmaker being the two I’ve used most), so maybe you do see crazy numbers of connections in the wild (but again, I feel this could be avoided if the language designers wanted to)
A text-based function with 3000 lines starts to look messy, too. That's purely a function of size, not building materials.
The analogous solution to "a simple script" is "a simple graph", i.e., abstraction.
Right and abstraction is exactly what doesn't work well with visual languages.
With a script you can do a for loop from 1 to 3000. With 3000 components connected to one node in a visual language there is not obvious facility to handle it. You can think of group functions in components/namespaces/folder maybe. Or say generate implicit connections where they are not really drawn on the screen.
have you ever actually used one?
> Even then, once a "program" gets complex it can get tangled fast.
because this is a common complaint, but it applies to text-based languages as well. what happens with visual languages is that it's easy to get going, but then people don't apply the same software engineering principles once projects get large. i do, and i find visual languages no worse than text-based languages. in some ways, there are direct improvements. so basically, these complaints are levied by people who have never seriously programmed in a visual programming language.
> 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.
this doesn't even make sense. i use labview, arguably the best designed and most powerful visual programming language environment around (and a powerful environment period). it isn't even possible to create a node with 3000 edges (well maybe for some definition of the word node, but it would be an extreme case and an exercise in shenanigans). what you've stated here sounds like "a function with 3,000 arguments starts to get messy". it's a ridiculous statement.
> As for general computing, the most thought out language I've seen so far is probably DRAKON
have you used labview? you can program windows, mac os x, linux, real-time linux, and fpga, all with the same language. this inculdes modern GUIs, web-servers, actor-based systems, oop, etc. it's extremely powerful. it has its warts, and i have many complaints, but none of them are the usual complaints by people who have opinions against visual languages despite not having used one.
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/ [2] https://github.com/search?q=ballerina
>once a "program" gets complex it can get tangled fast. A node with 3000 edges starts to look messy.
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... [2] https://www.uxbooth.com/articles/a-usable-guide-to-cognitive...
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.
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?
In a source based language, would it have 3000 arguments or connections to other parts of the program?
This seems to be an issue of complexity management which would be the same (or worse) in source form.
If anything with a visual language you would be able to have it only show some specific nodes of those 3000 (e.g. those of a certain type, or going to a certain receiver), jump to a higher level view, and so on. With text it's all a big dump.
A visual language UI is a superset of text (and can go down to a just-source representation and source editing if needed.
The reverse is not true -- a source editor is not a superset of visual editing.
> 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.
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.
Is this not available to the public yet?
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.
It was also pretty unstable.
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.
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.
Then I read the author's explanation (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.
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?
I "wouldn't hold that against" the tool if it had technical merit.
In particular, in the UK, I suspect the terminology for bullets is almost unknown, so it would be seen exclusively as a film reference.
Call it FMJ and it would be fine, though!
This is arguably NOT true. Visual languages have consistently failed to match, let alone out-do textual languages for decades, and with good reason.
I think it sits between both worlds. The interface and main interaction is visual, yet the actual logic is textual.
This seems to hit the sweet spot, making it useful for the non-programmer yet providing significant depth and complexity.
Note that personally I hate using plain Excel because the formulas seem so restrictive and the functions I want are never there, but again this seems to be ideal for the target audience.
Using rows and columns instead of code blocks helps a great deal in reducing the cognitive load of having to address every part of the language through an ID, either for variables of functions. Not to mention intermixing code and data values, which is not considered part of conventional languages (though is common in interactive debugging sessions, which are typically considered "visual" debugging).
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
The error is thinking that "visual languages" are adequate for the same general purpose as textual languages. But for certain Domain Specific Languages, visual tools can be and have shown themselves to be quite useful.