Hacker News new | past | comments | ask | show | jobs | submit login

Where's the data?

A "data flow language" that only visualizes functions isn't. IMHO.

I agree with most of the perennial discussion that takes place here for all of these projects: text is good, but not for everything and everyone, yet graphical programming has never taken off... why?

Because if people want a data flow, they care more about the data than the flow. Spreadsheets have secured a rock-solid place in the "lingua franca" of userland, without ever visualizing the "connections," which are seldom enlightening.

I would not criticize something for failing to achieve what it doesn't attempt, and FMJ may be fantastic for developing logic. But it calls itself a "visual dataflow language," and I'm not seeing any data. (Yes, code is data in lisp, that's not what I mean.)

To visualize code is to focus on the means to the end. I would respectfully disagree that "21st-century" programming will resemble the static modelling of systems represented by code in whatever form. Systems will be "live" as a rule. And that is what will improve the lives of programmers. Remember that "interactive computing" was once a radical idea, the realization of which required people to spend their lives and resources fighting for it (Licklider, Englebart, and Bob Taylor et al, to name a few). Well, if you feel any resistance to the idea of relinquishing your rinse-and-repeat development cycle, I have two words for you: punch cards.

I hope I am not trolling here. Just this month I've been "sniped" by a data flow side-project that has me thinking about these things, and I'm extremely interested in how other people approach the subject (and their discussions here).

edit grammar, wording




Thanks for your comment - it's insightful, and definitely not trolling.

> Remember that "interactive computing" was once a radical idea, the realization of which required people to spend their lives and resources fighting for it (Licklider, Englebart, and Bob Taylor et al, to name a few).

Yeah, but the funny thing is that this radical idea only sparked for a while, and then was extinguished. Present world, with all the hip languages we use on our $dayjobs[], is pretty far behind what Englebart et al. were working on. Event the present Lisp (and Smalltalk) systems are mere shadows of the "interactive computing" of the past. People are slowly rediscovering the concept again though, gently pushed by visionaries like Bret Victor.

I 100% agree with your comment about data. The most successful dataflow languages I've heard of were always tied to some particular data processing tasks - like music and general DSP. It's a good driving force that helps immediately verify the feasibility of the language and the environment.


You certainly aren't trolling, and your point is valid.

Directed graphs are the most general data structure, and the language is homoiconic. So data definitely will be represented graphically: not just directed graphs, but other structures such as arrays.

But there's only one of me, and if I'd done this already, something else wouldn't have got done. However, it is high on my agenda, and will be done soon.


PigPen had this right... it visualized syntax that you typed. You could technically code with the mouse but that wasn't the intention of the tool. It made it easier to get a gestalt view of things, without hiding the essential details of operations. It was just another window into your code in Eclipse. I think Microsoft's IDE has similar stuff for OO code? But I've never used it.

https://wiki.apache.org/pig/PigPen

I tried to commercialize this technology in 2010, with Cloud Stenography (a joke name): https://github.com/rjurney/Cloud-Stenography https://vimeo.com/6032078

More recently, a company has done some similar stuff, albeit for Spark, in Seahorse: http://seahorse.deepsense.io/


There's also Apache NiFi




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: