Why isn't there a general purpose visual programming language? | Hacker News Reader

Why isn't there a general purpose visual programming language?

blogs.msdn.com

12 pointsAlfredTwo34 comments

Because they're awful?

The author doesn't mention LabVIEW, perhaps because he is not a scientist. LabVIEW is a visual programming language -- you construct software by connecting little icons together with wires.

LabVIEW has been around for decades and is a big success. Lots of science labs use LabVIEW, because (a) it's a National Instruments product and interfaces perfectly with National Instruments interface cards -- which have been the industry leaders for years; (b) it has drivers for every instrument ever; (c) the visual paradigm does work great for GUI design and layout. (Which shouldn't surprise anyone who has used XCode or Visual Studio.) Scientists love the ability to throw together a chart recorder application in ten minutes, and then wire it up to everything else in the lab, and LabVIEW works great for that particular use case.

Unfortunately, as you go beyond the most basic of computations or out of the environment's sweet spot -- in other words, as you try to use it as a general-purpose programming language -- LabVIEW just gets more and more painful. It has its own special vocabulary, semantics, and design patterns that are unlike everything else you've seen. Every time you want to define a subroutine you need to create a little icon for it, and define its arguments in terms of little panes on the icon. That's slow and painful and limiting; it makes writing Java in Notepad feel like luxury. But you have to stay disciplined and keep defining those subroutines, or your code will literally turn into spaghetti. Oh, the horrors I have seen. It's particularly awful if the code sprawls over more than one screen.

You can't effectively print out the code. It's hard to blog and hard to quote snippets from. To refactor you have to manually rearrange icons; there's a lot of time wasted laying things out. There's no way to use version control or create a patch. There's no search-and-replace.

Think of emacs. Now think of Notepad. Now think of something that is less useful than Notepad, to the same degree that Notepad is less useful than emacs. That's a visual programming language.

(Disclaimer: I work on LabVIEW.) For refactoring and layout, there is a diagram cleanup tool that will automatically re-layout your diagram for you with just a button press. It does a pretty good job IMO, and really changes the way you code. Also, version control is supported, and allows for graphical diff and merge. While there is no search-and-replace, there is a search function. (Search/replace has quite a different meaning when you're dealing with graphs rather than text.)

Ah, I forgot to mention another of LabVIEW's good features: The company has been improving it steadily for decades. ;)

Diagram cleanup tool sounds interesting. I'm old enough to remember the earliest version of LabVIEW, which as I recall forced you to rewire every connection to something whenever you moved it. Now that was torture. When I went back a few years later and found that wires would automatically follow you around it felt like Christmas. Perhaps the cleanup tool is an equally big win.

Version control and diffs sure would have been handy when trying to clean up some of the terrifying things I inherited back in the day.

None of those problems are intrinsic to visual programming, only to the IDE for one. None of those problems seems particularly hard to solve as far as I can see.

When you have to rely on an IDE for printing, sharing code, quoting etc., you've already lost.

From the perspective of a text-based language that would make sense, but its completely inapplicable to a visual programming language. The IDE is the language. Printing/sharing/quoting would need to be features of the IDE and the language.

LabVIEW is only one of many others I could have named. The three I named are the ones I personally use the most but of course there are many others. Several for programming robots for example.

You always see the same basic demo when people show visual languages. Here is your homework. Pull up the source code to the program you most like to use. Take an average-sized function in it. Break it up into a Lisp-like syntax tree. If you have fewer than about a hundred nodes, you are probably cheating; get a bigger function. (The purpose of my asking you to get an average sized function is not to minimize the problems, it is so you can actually complete this task.) Draw this tree on a piece of paper using any visual syntax you like.

If you've still managed to dodge enlightenment, repeat one layer down on all functions your function calls. If you happen to ascribe to the "one method = one line" school of OO design, then this is mandatory, and you have to complete the transitive closure of your call graph. Complexity can not be removed, only moved around. If it took you less than five minutes, you are now assigned to take the largest function in the source code.

You will attain enlightenment.

If you still don't believe me, grab a literal pen and a literal piece of paper and literally, in real life, conduct this exercise until you do believe me. The human mind is quite skilled in handwaving to itself; the paper will not permit that.

The idea of visual programming is that we'll make the syntax easier for people by using colors and shapes and connecting things together in 2D.

To me that seems misguided. When it comes to parsing a stream of text into concepts, humans have hardware acceleration. You're doing it right now, effortlessly.

Visual formatting cues can help, but only at a pretty crude level, compared to our sophisticated understanding of language and grammar.

Furthermore programming requires that you extend the notation every time you use it. This implies that programming can only be represented well with combinations of symbols, of which the example par excellence is text.

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.

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

I have said this argument in HN before, but let me repeat.

There's strong evidence that evolution of human language and ability to think with abstract concepts are related. Programming is all about abstractions. It might be even harmful to move to mainly visual programming paradigm.

Visualization certainly help in certain subdomains, for example state machines, but, as said, there might be even biological bias in favor for text-based programming languages.

So SmallTalk and Self are not visual enough?

http://www.smalltalk.org/ also http://www.squeak.org/ http://selflanguage.org/

I am convinced that this is because the primary input method for PCs is the keyboard, so user input is primarily text. Perhaps a visual programming language will emerge on the iPad, or some other platform where primary user input is graphical rather than textual.

Primary input for coding on PCs may be the keyboard. Doesn't need to stay that way.

For the same reason we still use text to communicate: iconography is insufficiently rich to express the degree of complexity required to abstract, describe, and solve hard problems.

Visual programming languages are great as a teaching tool, but I fail to see how they would be useful as a general purpose programming language. There is no need to be filled.

I believe that a visual programming environment or state visualizer for concurrency will be essential for a next generation programming language. The need to be filled is the need for representing many dimensions of computation simultaneously. It's 2020 and you've just written a program to run on 1024 machines with 1024 cores each. How do you reason about that?

How do you visualize a subspace delimited as segments in 1024 axes? Visualization doesn't scale in this way. You need to focus on the small, and have strong and reliable guarantees about those fundamental particles; combined with a safe and reliable way to compose those particles, and combinations, and so forth. You need proofs, and easy ways of asserting that certain properties are true, with help from the machine such that it can tell you - for certain - whether your assertion is true or not for all possible numbers of threads.

Now dataflow programming languages, which are often visual, are naturally parallelizable in the same way functional languages are, but this is not related to their visual implementation.

You certainly don't make each processor or core a dimension if that is what you are suggesting.

The small is type systemic. Machine proofs show that you have written your typable logic correctly.

This is still not at the level of concurrency or machine assistance to which I am referring.

You are getting closer with dataflow programming languages. Pipeline and compute farm visualization, spatial/resource quota policies and control, and process calculi equivalences proven across visual/spatial refactorings is what is needed.

Of course you can do all of this with a linear byte array. Of course you can get more dimensions with names and references.

Unfortunately, these methods are very specific and very technical and, despite their accuracy, are relatively devoid of meaning at-a-glance. In the future, a domain expert will work with a programmer to build an application which the domain expert will then operate and monitor. This is not possible without heavy use of graphical interfaces and visual representations. This is not possible without an advanced type system and an easily constructible syntax for DSLs and DSL graphical front-ends.

Perhaps you wouldn't classify this as a "visual programming language" as most of the programming itself is not done via virtual objects and connections. However, visual system tools will become increasingly important as programming moves from implementation to specification and control.

> In the future, a domain expert will work with a programmer to build an application which the domain expert will then operate and monitor

This has been in the future for at least 30 years, by my knowledge of the literature. In fact, it's been in the future for so long by now that it seems to be in the past, by my reckoning.

VVVV is probably the closest you'll get:

http://vvvv.org/tiki-index.php?page=Tutorial+Hello+World

Also interesting in this space (audio/visual/performance) is Pure Data: http://puredata.info/

java studio for sun tried to do this but sun was a failure of a company and didnt succeed in staying in alive.

i have dabbled in creating a visual programming language for c#. i have a lot of code written. contact me. http://www.thedirtydeveloper.com

Let's one statement = a 100x100 images..

Now, imagine 1 million line of code.

That mapping seems to undervalue the expressive power of pictures, which is commonly taken to be: 1 picture = 1000 words.

Reply on news.ycombinator.com