Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Full Metal Jacket: A visual dataflow language (2016)

fmjlang.co.uk

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Full Metal Jacket: A visual dataflow language (2016)

#51

Post by drivingmenuts »

bane wrote: post #15
drivingmenuts wrote: post #4

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.

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/

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.

Re: Full Metal Jacket: A visual dataflow language (2016)

#52

Post by ken »

rdtsc wrote: post #47
ken wrote: post #43

Earlier quoted context omitted.

> 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. 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.

> 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 implici…

What visual language are you using? All of them that I’ve used have for-loops, too.

Re: Full Metal Jacket: A visual dataflow language (2016)

#53

Post by rdtsc »

ken wrote: post #52
rdtsc wrote: post #47

Earlier quoted context omitted.

> 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 implici…

What visual language are you using? All of them that I’ve used have for-loops, too.

A proprietary one. A for loop to create connections between nodes? How would that work? It would have to be a self-modifying connection graph.

Re: Full Metal Jacket: A visual dataflow language (2016)

#54

Post by TuringTest »

zozbot123 wrote: post #46
TuringTest wrote: post #33

Earlier quoted context omitted.

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 an…

> 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 t…

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?

Re: Full Metal Jacket: A visual dataflow language (2016)

#55

Post by dkersten »

rdtsc wrote: post #48
dkersten wrote: post #41

Earlier quoted context omitted.

> 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 one…

> 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 an…

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)

Re: Full Metal Jacket: A visual dataflow language (2016)

#56

Post by nikofeyn »

rdtsc wrote: post #6

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,…

> 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.

Re: Full Metal Jacket: A visual dataflow language (2016)

#57

Post by nikofeyn »

ken wrote: post #45

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…

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.

Post reply on HN