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

Of course, as it has been said, a picture is worth a thousand words, but there must be a reason why diagrammatic languages have not received the acceptance as widespread as text-based languages have. Even in "obvious" cases like microcircuit design engineers prefer text-based "hardware definition languages" over diagrams. One explanation could be that human intellect has evolved in the process of perfecting means of communication and thinking, of which a language based on symbols (words) proved to be most efficient, particularly in conveying abtractions, which is exactly where pictures, being concrete,fell short.



Good point, programming is much about communicating not only with the machine but with other people. Writing serially executable code is a bit like explaining to others and yourself what you are doing there. If instead we have a "wire-frame" of a program it presumably naturally calls for some kind of explanation. Explanations need to be textual because humans communicate textually. Humans prefer to give each other instructions textually, not as graphs, because less interpretation is needed with strictly serial text.

Visual programs are a bit like if you were presented a program which needs to be read from bottom up right to left. Would that be somehow easier to understand? Visual language presumably can combine both left-to-right and right-to-left and up-down and bottom-up interpretations. While it's possible that such model would be more expressive than conventional programs, that is not certain to be so from the outset.


Personally, I think that drag and drop is a really bad UI for doing this sort of thing. I think that the lack of an effective means of editing graph based information has been a big reason. I think that the seccond reason, is that all of these tools have used their own, complicated serialization format, rather than using something more unixy that you could build a real ecosystem around.

I'm trying to solve these problems with textgraph: http://thobbs.cz/tg/tg.html and while the ecosystem is still in daipers, I am finding that using a simple and LIMITED file format, that can do nothing more than use text based edge lables and text based vertex contents, makes development of the ecosystem much faster than if I were to go crazy with having ecosystem features like edge collors, box vertex and arrow shapes ect.


I think part of the reason is that programmers simply aren't used to thinking solely in terms of dataflow. People have had no problem using flowcharts to represent flow of control.

Text is intrinsically one-dimensional, and that is perfectly fine for sequential execution of algorithms. But if you want to exploit MIMD concurrency, text limits you.


I disagree with that. I think programmers don't even like to use flowcharts very often because they are too limiting. As you're perfectly aware, when you code you quickly stop thinking in terms of "this happens, then that happens, than maybe X or else Y". You're more likely to think like "I need those two things combined and spliced into that third thing in a way that depends on Z".

The way we work with text makes it easier to construct and layer abstractions. Having twenty thousand different boxes in a graphical language is not something we're used to in a way we can have twenty thousand different words in code (or in a sentence) - and if you start treating boxes as letters and grouping them, you're essentially inventing a textual language right there.

I'm not saying visual programming is a dead end - but I feel we need a much different style than just boxes with arrows. For one, text seems to exploit human ability to pattern-match much better than box diagrams; that's why we feel text is denser in information. Making diagrams more information-dense is not an area I recall to have seen explored in visual programming, but maybe we need to go there.

Anyway, best luck with the work on FMJ!


Well, first off, program code is not one-dimensional; you would be more correct saying that it's "two-dimensional", which is is why indentation is helpful at all. Also, saying " text is one-dimensional" is almost as superficial as saying that a book is just a stack of paper. No, it is more than that, of course, and so is text in general. When you are reading, do you imagine a one dimensional world? Of course not, and that is how text's "dimensionality" should be measured, not by its appearance as a mere sequence of markings on paper or a computer screen.


Max/MSP has been very successful, though it's specialized for the music/visuals world. Given the text-based alternatives in that realm (csound, supercollider), it's not surprising.


I have some experience with a visual language (webMethods, currently owned by Software AG).

Guess what I miss the most when I use it?

diff -c

And all the rest you get with text (versioning, global search&replace, static analysys...)


Programming by using a GUI to generate an XML file was a 1990s trend that still hasn't died. The thinking was "we need to make a visual programming tool for non-programmers," which is sort of condescending to begin with, and then the people who use it run into all these real problems that normal text-based programming languages have already solved (automated testing, version control with diffing, merging, etc.)


Programs are stored on disk as lists of program elements in S-expression format, so are still accessible to grep, diff, etc., and there's no reason why a version control system couldn't be used. Even with text-based languages, use of diff runs into problems when text is moved about or reformatted.

It was never my intention to develop a language that anyone could use. It's for programmers. You still need to write algorithms. It will attract different people, just like different text-based languages.

I am planning to incorporate automated testing into the language, but haven't decided upon the best way to do this yet.


In my experience (and, as I said before, this is confined to one specific product/language) while the whole stuff was, in fact, represented as XML files, trying to work at the XML level was a nightmare. Each single graphical element had 2 or 3 different XML "source" files, distributed in different subdirectories, and there was no support (official or unofficial) to operate at the source file level. In other words, any trivial mistake would probably corrupt your project in some subtle and not easily recognizable way.

Now that I think about this, it was exactly the same with a large Sharepoint installation (around 2009/2010?).

In my experience there is a world of difference (and a world of pain) between "this is a source file, you can compile or interpret it and if there is a mistake you will get an error message" and "this is the XML serialization of a complex hierarchy of objects and if you mistype a GUID somewhere you will only find out at runtime, usually because something not even remotely connected to your mistake starts behaving erratically".

I am not saying that your project has no merit or that it will fail, I am just commenting on why, in my opinion, visual programming never really became a serious contender for general purpose programming.


As someone working on TIBCO BusinessWorks, a competitor/alternative to webMethods, this sounds all too familiar. We have had major challenge ourselves in bridging this gap - semantic diff/merge on process/flow engines like BW, WM, etc. with visual tooling.

Typically developers care about this, business buyers don't and they direct budgets and in many ways, product prioritization. To a large extent the proprietary or obscure nature of integration DSLs never helped bootstrap any meaningful tooling for users.

That's changing though with developer-power driving prioritization and investment. In our case, we hope to make good progress with an upcoming project called Flogo. Currently in stealth and soon to be OSS.

Disclaimer: I work at TIBCO on integration


I think the problem here is that if you want to go visual, you need to go visual all the way. There should never be a case you need to manually debug a serialized representation. If your environment can't support that to an acceptable level of reliability, then you need to explicitly stick with a double-form approach, where the visual form and serialized form are "equal citizens" and both are meant for the user to work on in parallel.

Trying and failing to go with option one is what leads to the XML mess you describe.


For what is worth, the reason we tried (and promptly abandoned) the idea to work at the XML level was the following: in a visual language some stuff like:

- "Find all places where I am using records of type X and replace that with a record of type Y"

- "where did variable RunningTotal gets initialized? when do we reset it"?

- "Can I write a simple script to verify which temporary variables are not removed from the dataflow after being introduced?"

(Debug in the more traditional sense works reasonably well in webMethods - but this was not the problem - the problem was that it is impossible to reason about a "program" as a series of instructions and analyze it as such, even if at the end of the day a webMethods flow service is just that: a series of steps that manipulate data in a tuple space).

So this is not a critique of webMethods (or FMJ) - I am explaining what the problems you encounter are when you try to use the graphical metaphor to work on reasonably complex programs. Most of the successful examples cited so far seems to be mostly about audio manipulation. I suppose this means most of the time you compose smallish "scripts", you work alone and not in a team, logging is not an issue, building large, reusable components is not an issue, extending existing logic is not an issue, and so on and so on.

Having also worked a lot with an ancient 4GL application (where the language was supposedly "more expressive") I can sum it up all my doubts as follows:

Certain paradigms work well as long as the programs are written and maintained by a single developer to automate simple tasks but do not scale very well past that point


That sounds absolutely horrendous, and there's no good reason why they had to be like that. It's unreasonable to assume all visual programming languages do things the same or a similar way.


But you said yourself that the s-exp storage format for your language is neither easy nor safe to modify, so how is it better than XML?

Anecdotally, I've also used webMethods, SSIS, and several other visual dataflow programming languages, and they look remarkably similar to FMJ.


I was referring to this:

> Each single graphical element had 2 or 3 different XML "source" files, distributed in different subdirectories

S-expressions with equivalent content are smaller and just as readable, and don't need an extra parser. XML is OK for text mark-up, but not as good for storing data (including programs).


Granted. But keep in mind that both products were made by capable companies and were used to deliver value to customers.

I would be more than happy to explore viable alternatives to traditional text-based development but so far I haven't found anything that really impressed me.


This is a great point. When you think about it his idea is being explained in words which kind of shows that often words are the best way to describe complex ideas.

On a side note I remember seeing this which is kind of a hybrid for clojure.

http://www.clojureatlas.com/


I suspect that VR is going to open new ground here.


> ... but there must be a reason why diagrammatic languages have not received the acceptance as widespread as text-based languages have.

Or maybe because of the Deutsch limit (text is denser):

https://en.wikipedia.org/wiki/Deutsch_limit


I think so. And related, I haven't seen a good way of managing abstractions in a way we do it with text. The dataflow paradigm feels a bit too weak for that (but maybe it's only my impression). With textual programming languages we're used to, there's - for better or worse - pretty much no upper limit for the stack of abstractions we can create.




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

Search: