3 ms·

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.

by beagle3 10y ago

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/ http://www.lamdu.org/

jbpetersen 10y ago
> ...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 10y ago
  Can you elaborate?
  - jbpetersen 10y ago
    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 10y ago
Use a caret for your "2", you confused me with that equation.
tluyben2 10y ago
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 10y ago
  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 http://code.jsoftware.com/wiki/Guides/JAndroid
  - beagle3 10y ago
    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 10y ago
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 10y ago
  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 10y ago
    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.

by beagle3 10y ago

jbpetersen 10y ago

> ...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 10y ago
Can you elaborate?
- jbpetersen 10y ago
  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 10y ago

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

tluyben2 10y ago

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 10y ago
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 http://code.jsoftware.com/wiki/Guides/JAndroid
- beagle3 10y ago
  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 10y ago

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 10y ago
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 10y ago
  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.