[beagle3]

I applaud the attempt, and it does look nice, but my impression of visual programming environments is that they never scale, and it might be an inherent issue.

I have never met a single person that, with more than 5 minutes of time, preferes the "distance computation" as given in the skov example, to the simple mathematical (x-x)2+(y-y)2

Lamdu[0], which has been discussed on HN before, is more Haskellesque, and I have also not heard from anyone that it is actually useful (beyond very early Haskell teaching).

Personally, I'm at the other end (preferring the tersest practical language, K) but I understand the appeal of a visual programming language - it's just that I have never seen an example that delivers.

[0] http://www.lamdu.org/

[tluyben2]

K is an example of a language I can code with on my phone. Because you need only a small screen with code to see a lot of functionality and you do not need a lot of input but more thinking it works. Most modern visual programming attempts come from the drive to work on small screen without real keyboards and languages like K (APL likes) and Forth likes (like this one is based on) already work because the code is very terse and you do not have all the issues with copy/paste and scrolling like you do in most languages. I experiment quite a bit with programming while on the move (even walking) and I am close to having something which works about as well as normal coding. It takes ideas from K (oK) and different forth implementations.

[codygman]

What K compiler do you have in your phone?

I have the awesome J Android app[0] on my phone, but J doesn't seem as polished as K.

0: http://code.jsoftware.com/wiki/Guides/JAndroid

[beagle3]

There's John earnest's oK on github (am on phone right now or I would link). It's a JavaScript implementation that runs everywhere.

K is not more polished, it is differently polished. It is much more minimal than J, which makes the syntax simpler and thus the shortest program is often longer and slower in K; however, in my experience typically the length and performance are on par.

[DonaldFisk]

One of the problems with text-based programming is that it scales rather too well. I've had to deal with C functions which were 1000 lines long. You simply can't abuse a visual language like that. As you approach the Deutsch Limit, the complexity of what you've drawn becomes immediately apparent and you have to think about ways of reducing it, by structuring your code better, e.g. splitting up complex functions into two or more simpler ones.

[beagle3]

I can assure you that there's an analogous person who can do the 1000 lines drawing (or whatever the equivalent monstrosity is). And if that is impossible, it means the language is too limited to be of real use.

We've had many programming paradigms over the years, most delivered and we can argue about their merits. To the best of my knowledge the only somewhat successful visual programming systems are simulink and lab view, which are extremely limited, and any nontrivial use does venture into the "dreaded" textual.

I would love to be proven wrong, but I suspect it is inherent. A picture might be worth a thousand words, but movie scripts are still written as text, and graphic novels are a minuscule part of the market.

In my opinion It is similar to the misguided notion that some people have that if only math notation (or physics notation, or music notation, etc) was more graphic/elaborate/readable, it would be easier and accessible. This is wrong: the notation is just the top of the iceberg you see above the water. The underlying complexity is the real issue, and it won't go away with a different notation.

[DonaldFisk]

Movie scripts and novels, graphic or otherwise, contain a narrative which is inherently sequential, and the best way to capture that is in text.

Programs in general are non-sequential (MIMD). They are normally expressed sequentially because early hardware was inherently sequential.

Music notation is graphical. So are Feynman diagrams, circuit diagrams, maps, blueprints, structural formulae, etc. Not everything is best expressed as text.

Other successful visual dataflow systems include Max, Reaktor, and Flow-based programming. The field is in its infancy and we can't be sure yet what works and what doesn't.

[beagle3]

Most of computing is actually sequential, or a small set of sequential computations carried in parallel, often reactively based on an input. So you agree that in cases well described this way (e.g., a Word processor or a Web browser or an Excel spreadsheet) text is a better decription of the computation? Specifically, re:excel, I'm talking about describing Excel itself, not a specific spreadsheet (which may sometimes have a reasonable graphical representation)

Music notation is graphical, and still gets complaints for being "hard to read" by people who haven't mastered it. My intention for bringing it up was not "see, it's not working", but rather "see, it doesn't make things simpler".

Circuit diagrams are graphical only for very small and simple circuits, which illustrates my point about scaling - there is no circuit diagram for any circuit with more than a few tens of elements anymore. Take a simple processor, for example - there are textual descriptions (verilog, vhdl, ihdl, ...) which are compiled into logic gates and/or netlists (textual or binary), and the result of layout (which is graphical, but not for human consumption). There's a block diagram, yes, and a small number of those blocks can be zoomed into another block diagram or a circuit -- but by and large, with the exception of manual layout tweaking, it is textual -- and that's in an area that started with diagrams and still champions them in its courses.

I disagree that the field is in its infancy - we've had pen and paper diagrams for everything in computing since forever, none of which has scaled so far to a complete system (some are ok for toplevel, some are ok at the really bottom level, non work in the middle) , including flow charts, data flow diagrams, UML and its tens of different diagrams, etc.

I would love to be proven wrong, though, but personally I have given up on this kind of things.

[jbpetersen]

> ...my impression of visual programming environments is that they never scale, and it might be an inherent issue.

Eventually they won't need to.

[beagle3]

Can you elaborate?

[jbpetersen]

I think visual programming calls for a dramatically different style of programming (along with the dramatically different tooling) in order to take advantage of it well. And I think part of that is working well with many small snippets of code rather than much more monolithic functions.

Though I'm not sure quite what it'll take for it to make sense for people to collectively give visual programming the attention it needs to improve beyond being a mostly useless oddity.

[Fluxenein]

Use a caret for your "2", you confused me with that equation.