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.<p>As for general computing, the most thought out language I've seen so far is probably <a href="https://en.wikipedia.org/wiki/DRAKON" rel="nofollow">https://en.wikipedia.org/wiki/DRAKON</a>. Apparently you can now even try it online: <a href="https://drakonhub.com/try-me?example=mind157" rel="nofollow">https://drakonhub.com/try-me?example=mind157</a><p>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: <a href="http://www.fmjlang.co.uk/fmj/tutorials/Recursion.html" rel="nofollow">http://www.fmjlang.co.uk/fmj/tutorials/Recursion.html</a> Some people really struggle with recursion initially and if they are visual learners this might be helpful.
Visual representation for code has its own niches for certain.<p>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].<p>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 <i>perceptible difficulty</i>, but in general case, they don't.<p>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 <i>true</i> 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.<p>[1] <a href="https://ballerina.io/philosophy/" rel="nofollow">https://ballerina.io/philosophy/</a>
[2] <a href="https://github.com/search?q=ballerina" rel="nofollow">https://github.com/search?q=ballerina</a>
Something like Luna[1] language looks saner - where it has both textual and visual representation.<p>[1] <a href="https://luna-lang.org/" rel="nofollow">https://luna-lang.org/</a>
There's one thing here I strongly agree with:<p>> There is no point developing new programming languages unless they're radically different from existing languages.<p>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.<p>There's also something here I strongly disagree with:<p>> Programs are composed almost entirely with the mouse rather than keyboard, and type inference and other checks take place while you edit your program.<p>If there's one thing that's true of all programmers today, on any platform, it's that they <i>love</i> 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.<p>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.
The Clojure threading macro provides language-level support for The Pure Function Pipeline Data Flow
<a href="https://github.com/linpengcheng/PurefunctionPipelineDataflow" rel="nofollow">https://github.com/linpengcheng/PurefunctionPipelineDataflow</a>
Discussed at the time:<p><a href="https://news.ycombinator.com/item?id=12106259" rel="nofollow">https://news.ycombinator.com/item?id=12106259</a>
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?<p>Is this not available to the public yet?
Looks like Labview. Nobody who has used Labview would try to recreate it.<p>One of the main problems I find with these type of systems, is that although you <i>can</i> 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.<p>It was also pretty unstable.
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.
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
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.<p>Then I read the author's explanation (<a href="http://www.fmjlang.co.uk/fmj/Name.html" rel="nofollow">http://www.fmjlang.co.uk/fmj/Name.html</a>), which makes a comparison between lisp (the programming language) and stereotypes about homosexuality (with the requisite "I have gay friends!" disclaimer).<p>Maybe the author should grow up.
"Text-based languages are so 20th century"<p>This is arguably NOT true. Visual languages have consistently failed to match, let alone out-do textual languages for decades, and with good reason.