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.
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.
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.
> I have seen visual dataflow languages and even worked on some of them.
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.
> Even then, once a "program" gets complex it can get tangled fast.
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.
> except we’re trained to use software engineering principles to attempt to manage the complexity
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.
In my (again, limited) experience with visual languages, you don’t need thousands of connections. There’s nothing technically preventing a visual language from having complex data types flow through connections and I know some visual languages can unpack arrays (that is, the node outputs a value for every element in an array) so you can have a similar loop. (I’ve seen the reverse too: packing lots of individual items into an array). If I were to design a visual language, I’d have nodes to access keys in KV tables, iterate through lists/arrays/trees and everything else I take for granted in textual languages.
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)
> 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.
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.
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]
> 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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.”
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.
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), which makes a comparison between lisp (the programming language) and stereotypes about homosexuality (with the requisite "I have gay friends!" disclaimer).
Yeah, I find the name very off-putting. It just doesn't sound professional, and I can't picture myself explaining to a client that I would be providing them with Full Metal Jacket source files.
In particular, in the UK, I suspect the terminology for bullets is almost unknown, so it would be seen exclusively as a film reference.
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?
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.
Visual languages fare very well for the use cases where they're adequate, and with good reason: dataflow specifications, data mungling, circuit design, and end-user development.
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.
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.
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.
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
Excel is cartesian, which is hardly 'graphical'. There are virtually no superfluous graphical detail (e.g. placement of shapes, arrows, thickness etc.) -- the only part of the flexgrid that has semantic meaning is the row and column reference.
Giving meaning to coordinates in a 2D chart makes it a graphical language. It certainly is different from conventional languages, which use a tree metaphor (nested expressions) and a linear syntax (everything is considered a long stream of text to be parsed).
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).
visual languages are good for very specific domains. look at Reaktor from native instruments, thats something which does work a lot better visually as a lot of the people who need that functionality aren't programmers neccesarily, and programming dsp units is not an easy task. you have applications for visual programming, but often it's very very specific or just purely for educational purposes. (teaching logic can be handy to do visually for some audiences.)
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.