Hacker News Reader

Comment by Jun8 | Hacker News Reader

What would be the point of this? Sure, you can come up with a more general purpose visual esolang (http://en.wikipedia.org/wiki/Esoteric_programming_language) but how would this match the efficiency of programming in, say, C? This would be meaningful only when the visual element adds some value.

One such place I can think of would be a video/image query language, e.g. for querying Flickr, that allows users to create complicated queries from image primitives.

View on HN

I work on a graphical (dataflow) programming language called LabVIEW. It is primarily used by scientists and engineers for measurement and automation, but is also useful for general purpose problems. The code looks similar to a circuit diagram, where nodes are wired together to form your functions. Various constructs are available, be it loops, conditionals (case structures), etc. It is a very different programming model that takes some getting used to - if you try to program as a C programmer in LabVIEW you'll have poorly written code and will be grossly inefficient to boot. But if you understand the paradigm and use it to its maximum benefit you'll can be very efficient.

Asking if it matches the efficiency of C is a difficult question as it ultimately depends on what type of problem you are trying to solve. For instance, if you're looking at performance-critical low-level bit-banging code, I'd choose C over LabVIEW. But if it involves data acquisition, analysis, and display, I'd choose LabVIEW over C. Each language has its own domain that it excels at where its efficiency (and expressiveness) peaks.

Spreadsheets are also arguably dataflow languages, albeit with single values rather than continuous or streams of discrete values (though this changes when you're using a Solve function, or playing around with scenarios). But they benefit from not being programmed in a visual way - i.e. the expressions are normally textual, even if they are marked up (e.g. referenced cells highlighted) to aid understanding.

That is, dataflow orientation is distinct from being visual.

I implemented a dataflow-like language for UI binding in a web framework once upon a time, and it worked very well. Changes to domain objects in business rules were reflected on the web front end without explicit effort on the programmer's behalf, other than binding expressions associated with the front end's control layout description. The update responses to front end requests (e.g. button click events) were communicated via minimal AJAX, because the binding knew only to send an update when a calculated value actually changed.

But having had all this experience, I would still not recommend using a graphical language for it except for UI control positioning.

What would be the point of this?

I think many seasoned programmers forget that for the non-programmer, syntax is a sizeable impediment to getting a working program and so I'd imagine removing syntax as a source of errors would open up programming to more people.

Sure, you can come up with a more general purpose visual esolang (http://en.wikipedia.org/wiki/Esoteric_programming_language) but how would this match the efficiency of programming in, say, C?

I don't think this comparison makes sense — how can you compare the efficiency of a programming environment to that of a programming language?

Many non-programmers get around this by relying on learning by example, most notably by copy-and-paste code, with minor adjustments of the parameters, in a kind of cargo cult style. But even this is more awkward with visual languages; it's far harder to e.g. do web searches, ask for help on forums, etc.

I don't think visual necessarily implies non-textual. I remember once seeing an old terminal app used by an airline that would allow you to escape the bounds of the input area if you used the arrow keys. You could literally type anywhere on the terminal which as you'd expect, effectively trashed the session till it was reset.

The analogy I'd draw is that programming in most editors is like that terminal app, you can do anything even if it's totally illogical and breaks horribly. When I read the question posed at the end of the article, the image that came to mind wasn't a pointy-clicky diagram monstrosity but more of an Intellisense with a tight input guard and strong visual delineation of blocks; a Python with even tighter structural rules rather than a UML on steroids.

An analogy with natural languages may be useful: there are no languages without syntax, i.e. no completely visual (ideographic) ones, except for simplistic signage domains, e.g. signs in airports, traffic signs, etc. The reason for this is: if you push aside syntax, there is very little expressive power left in a language. The prog lang space mirrors this behavior well, I think: you have very specialized languages, like kudo, but developing a visual language with enough expressive power to be general is very hard, not to say impossible.

I didn't understand your point about a "programming environment"

The comparison you asked for is that of an apple and an orange. I think you may have also misunderstood my comment on syntax — I wrote "removing syntax as a source of errors" not "remove syntax".

But then aren't you just replacing syntax errors with "why can't I attach this visual thingy to that visual thingy"?

Either way, they the essence of what they need to learn is the same: translate their ideas into a weird language. I'm not convinced that fitting shapes together is more helpful in that regard than a parser with good error messages and an IDE that does syntax coloring and code completion.

But then aren't you just replacing syntax errors with "why can't I attach this visual thingy to that visual thingy"?

Yes — the idea being to replace syntax and/or logic errors with just logic errors.

I seem to be the only one for whom the words "visual programming" don't conjure an image of weird shapes and diagrams — but I've already said that http://news.ycombinator.com/item?id=1496529

Reply on news.ycombinator.com