60 ms·

I'm always torn when I see visual programming languages (e.g. DRAKON, LabView, Simulink...). Obviously, they don't represent the way a computer works very well.

I'm always torn when I see visual programming languages (e.g. DRAKON, LabView, Simulink...). Obviously, they don't represent the way a computer works very well. Simple visual programs are arguably easier to understand than their text-based counterparts, but large programs quickly become a complete and utter mess of tangled wires and hierarchical blocks. The deal breaker for me (having worked on a large LabView program that controls machinery for a wind energy system) is the lack of reasonable source control systems and the fact that it is very hard to structure a large program in a comprehensive manner.

avaer 9y ago
Actually I'd say the visual languages do a much better job representing what the computer circuit is doing. But that's exactly the problem. Handling that complexity is the reason we invented textual programming languages.
- hatmatrix 9y ago
  I think textual programming languages predates visual languages on account of the hardware available at the time...
- TuringTest 9y ago
  We have better abstractions for textual programming because there has been much more research poured into them, but there's nothing preventing visual languages from being used at higher abstraction levels - they don't necessarily represent the computer circuit level. The typical strongest point of visual languages is that you can represent relations by proximity. This way, you can directly indicate the connection between a caller and its calles with an anonymous connector line, whereas in text you would need to declare a variable name, pass it as a parameter and assign it to a local variable. This makes moving data between components much more verbose in text than in graphs. Textual programs try to approximate this relations-by-proximity with indentation levels, but the expressive possibilities in a visual language are stronger. This makes them also more difficult to lay out and organize, though. But I foresee than in the future, better support in IDEs will make it easier to mix visual and textual languages.
  - seanmcdirmid 9y ago
    It is worse than that: we have 100k years invested in language and 5k years invested in writing language down. Pure visual communication went out of style with the cavemen and was never very effective beyond being used as supplementary material. Visual has some large advantages as well as drawbacks. It uses a different part of the brain for reading that works more in parallel, and can actually augment your short term memory. However, making visual work requires taking advantage of its concreteness, which textual language styles can't do very well.
Quequau 9y ago
I've also worked with LabView and completely agree with your assessments. I'd also add that line between a simple project which reasonable men might agree that was well suited for LabView and a large project which is destined to eventually become 'a complete and utter mess of tangled wires and hierarchical blocks' is not at all obvious or delineated... and that's when the suffering really begins.
- posterboy 9y ago
  Indeed, I guess. But really, that's the fault of the editors, not the concept. Xilinx graphical editor downright crashed frequently. The professional developers used vhdl or verilog instead, obviously (and even that would have been subpar because of a half assed linux port, I bet). What I mean is, if the devs had to dogfood their own product, if labview was self hosting, it could become a lot better. But in the background it's all just lowered to an intermediate programming language, the front-end is just grafted on. It's a marketing tool, just look at the camel case name. I hate it with a passion every time it comes up. Edit: I said "just" a lot, although, apparently it's quite good for it's intended purposes so take that with a spoon of salt. Edit: This thread repeatedly features screenshots of visual demo tools, for scenegraph and asset creation, e.g. werkkzeug 3: http://www.pouet.net/topic.php?which=8787&page=127 http://www.pouet.net/topic.php?which=8787&page=127
  - gugagore 9y ago
    I had never thought about the importance of being self-hosting like that. I missed the point about the camel case name. In any case, it's marketed as LabVIEW (VIEW standing for Virtual Instrument Engineering Workbench), not LabView.
    - posterboy 9y ago
      Probably it's not intended as a full development environment, more like a scripting language. The name just strikes me as unprofessional, or at least not very serious, just like the programming environment that it is, and I guess that's not even a bad thing if that's intended, considering the target group (of technically inclined but uninitiated or at least slow with a key board kind of lab rats).
avip 9y ago
Well LabView has internal revision control. The only prob is there's no reasonable concept of a "diff". Anyhow agree. Large LabView constructions are extremely difficult to grasp, modify, and test.
bluetomcat 9y ago
The clear advantage of text-based programming languages for complex programs is that all the wires and arrows are represented by symbolic names. Instead of drawing a wire, you simply use an entity with the same name (be it a variable, a function, or a data type). This is much closer to natural languages than a tangled mess of wires which becomes unmanageable after a certain level of complexity.
- ygra 9y ago
  Having recently finished playing MHRD I think there are contexts where the graphical representation is a lot more clear. Granted, that game's language is at a very low level where you write your wires kinda DOT-esque, but I basically had to draw everything from the ALU onwards on paper first.
erk__ 9y ago
I really like to use drakon to visualize algorithms. When I had a course that was going thourgh it last year i wrote the algorithms we used up in drakon. I felt it gave a good overlook of the algorithm.
coldtea 9y ago
>I'm always torn when I see visual programming languages (e.g. DRAKON, LabView, Simulink...). Obviously, they don't represent the way a computer works very well. Citation needed. A graphical language can "obviously" represent anything a text-based language can.
- mannykannot 9y ago
  One could just as validly make the much-overused "citation needed" call on the assertion in your second sentence - except that we can reasonably require a purely graphical response in this case.
  - coldtea 9y ago
    What citation do you need? At the very least, a visual environment could always trivially display each syntax/AST node, which will be the same as seeing a plain text version of the code (but better -- closer to something like Apple's Dylan IDE or Smalltalk environments).
    - mannykannot 9y ago
      Strip out the text and see how clear it is.
      - arethuza 9y ago
        About as minimal a graphical representation as you can get would be to have a tree of application nodes with S and K combinators as leaf nodes. You can compile any lambda calculus expression down to S and K and "run" them as a graph. Doing this on real calculation probably wins a prize for non clarity though...
      - coldtea 9y ago
        Who said you need to "strip out the text"? Text has been part of graphical representations for milennia. The cool part is that you get to decide WHAT text you get to see -- you're not just left with seeing the lower level code. It could be that, but it can also be boxes representing objects or functions, program modules, interacting programs, at any level of abstraction one likes.
jlg23 9y ago
> arguably easier to understand than their text-based counterparts, but large programs quickly become a complete and utter mess of tangled wires and hierarchical blocks. Or the other way around: When you write a tangled mess of code you can still navigate it with /bin/grep, this gets much harder when your code is a picture (though, when stored in SVG, it should be trivial to write a /bin/svg-code-grep). BUT: If you follow pure functional design principles, you rarely have to keep more than one screenful of diagrams in your head. I think we have to differentiate between "general purpose visual programming languages" and "visual programming languages actually used". Drakon, respectively its visual aspect, for example was, afaik, developed initially to allow physicists and chemists to model their domain specific knowledge in a much more intuitive way and I think it overall succeeded there. The few snippets I saw were very convincing demos[1]. Of all the attempts at purely visual, general purpose programming languages I cannot remember one that did not fall into any of these 2 camps: * academic exploration of visual programming languages - nobody expected tangible results but we got squeak, etoys and drakon * attempts to make programming easier by people who know just enough of programming to understand it is hard[2] - they usually promise tangible results by yesterday but never deliver anything that could count as a practically usable language [1] http://drakon-practic.ru/ http://drakon-practic.ru/ [2] Excluding all environments created specifically to teach children to code - they might be turing complete but I'd not call them "general purpose".
- seanmcdirmid 9y ago
  I think you mean scratch, not squeak.
  - jlg23 9y ago
    No, strictly speaking I was speaking of Morphic[1], squeak's main interface. But scratch[2] indeed should have been in the list. [1] https://en.wikipedia.org/wiki/Morphic_(software) https://en.wikipedia.org/wiki/Morphic_(software) [2] https://scratch.mit.edu/ https://scratch.mit.edu/
    - seanmcdirmid 9y ago
leni536 9y ago
About source control: do they have custom diff and 3-way merge tools? If they do they could potentially be used with git.
shortsightedsid 9y ago
While I don't disagree with your comment, it's a little ironic that hardware is designed visually. Instead of writing a netlist by hand, it's drawn as a schematic. The same applies to mechanical, construction or any traditional engineering fields. LabView targets engineers in those fields rather than those in software. So, you are right that visual programming doesn't represent how a computer software works.. But it's exactly how computer hardware works.
- donquichotte 9y ago
  I don't disagree with your comment either. In fact, my sentiment extends to hardware design, which is why I've been toying (and building real stuff for work) with SKiDL lately, a Python extension that allows for text based schematic capture for printed circuit board design. Of course, the actual routing of the traces still must be done by hand. However, during schematic capture, instead of drawing the same Zener diode input protection 100 times with a mouse, I just call the code that builds it in a loop.
  - shortsightedsid 9y ago
    Interesting. I have not tried SKiDL. All my designs are in Cadence or Eagle. Thanks! I will try itout
- marcosdumay 9y ago
  Simple hardware is designed visually. When things get more complex people resort to hardware definition languages and scriptable CADs.
  - shortsightedsid 9y ago
    I really meant circuit/physical design rather than high level design i.e pre-tapeout. Also PCBs are visually designed though I learnt about using python above and need to check that out.
    - marcosdumay 9y ago
nikofeyn 9y ago
i don't think it's obvious at all that visual programming languages don't represent how a computer works, but actually, i don't even see how that matters at all. for labview, i feel large programs benefit tremendously from its dataflow nature. every labview project i have worked on has exceeded 1,000 VIs, and it's often very easy to componentize things such that local changes stay local. labview works fine with source-code control. the diff and merge story could definitely be better, but they are at least usable, particularly the diff.
hurricaneSlider 9y ago
Source control shouldn't be a deal breaker I feel. The on disk representation would just need to be optimised for source control. For example an AST in the form of s-expressions could represent the visual structure of the program and would be amenable to VCS manipulation

avaer 9y ago

Actually I'd say the visual languages do a much better job representing what the computer circuit is doing. But that's exactly the problem. Handling that complexity is the reason we invented textual programming languages.

hatmatrix 9y ago
I think textual programming languages predates visual languages on account of the hardware available at the time...
TuringTest 9y ago
We have better abstractions for textual programming because there has been much more research poured into them, but there's nothing preventing visual languages from being used at higher abstraction levels - they don't necessarily represent the computer circuit level. The typical strongest point of visual languages is that you can represent relations by proximity. This way, you can directly indicate the connection between a caller and its calles with an anonymous connector line, whereas in text you would need to declare a variable name, pass it as a parameter and assign it to a local variable. This makes moving data between components much more verbose in text than in graphs. Textual programs try to approximate this relations-by-proximity with indentation levels, but the expressive possibilities in a visual language are stronger. This makes them also more difficult to lay out and organize, though. But I foresee than in the future, better support in IDEs will make it easier to mix visual and textual languages.
- seanmcdirmid 9y ago
  It is worse than that: we have 100k years invested in language and 5k years invested in writing language down. Pure visual communication went out of style with the cavemen and was never very effective beyond being used as supplementary material. Visual has some large advantages as well as drawbacks. It uses a different part of the brain for reading that works more in parallel, and can actually augment your short term memory. However, making visual work requires taking advantage of its concreteness, which textual language styles can't do very well.

Quequau 9y ago

I've also worked with LabView and completely agree with your assessments. I'd also add that line between a simple project which reasonable men might agree that was well suited for LabView and a large project which is destined to eventually become 'a complete and utter mess of tangled wires and hierarchical blocks' is not at all obvious or delineated... and that's when the suffering really begins.

posterboy 9y ago
Indeed, I guess. But really, that's the fault of the editors, not the concept. Xilinx graphical editor downright crashed frequently. The professional developers used vhdl or verilog instead, obviously (and even that would have been subpar because of a half assed linux port, I bet). What I mean is, if the devs had to dogfood their own product, if labview was self hosting, it could become a lot better. But in the background it's all just lowered to an intermediate programming language, the front-end is just grafted on. It's a marketing tool, just look at the camel case name. I hate it with a passion every time it comes up. Edit: I said "just" a lot, although, apparently it's quite good for it's intended purposes so take that with a spoon of salt. Edit: This thread repeatedly features screenshots of visual demo tools, for scenegraph and asset creation, e.g. werkkzeug 3: http://www.pouet.net/topic.php?which=8787&page=127 http://www.pouet.net/topic.php?which=8787&page=127
- gugagore 9y ago
  I had never thought about the importance of being self-hosting like that. I missed the point about the camel case name. In any case, it's marketed as LabVIEW (VIEW standing for Virtual Instrument Engineering Workbench), not LabView.
  - posterboy 9y ago
    Probably it's not intended as a full development environment, more like a scripting language. The name just strikes me as unprofessional, or at least not very serious, just like the programming environment that it is, and I guess that's not even a bad thing if that's intended, considering the target group (of technically inclined but uninitiated or at least slow with a key board kind of lab rats).

avip 9y ago

Well LabView has internal revision control. The only prob is there's no reasonable concept of a "diff". Anyhow agree. Large LabView constructions are extremely difficult to grasp, modify, and test.

bluetomcat 9y ago

The clear advantage of text-based programming languages for complex programs is that all the wires and arrows are represented by symbolic names. Instead of drawing a wire, you simply use an entity with the same name (be it a variable, a function, or a data type). This is much closer to natural languages than a tangled mess of wires which becomes unmanageable after a certain level of complexity.

ygra 9y ago
Having recently finished playing MHRD I think there are contexts where the graphical representation is a lot more clear. Granted, that game's language is at a very low level where you write your wires kinda DOT-esque, but I basically had to draw everything from the ALU onwards on paper first.

erk__ 9y ago

I really like to use drakon to visualize algorithms. When I had a course that was going thourgh it last year i wrote the algorithms we used up in drakon. I felt it gave a good overlook of the algorithm.

coldtea 9y ago

>I'm always torn when I see visual programming languages (e.g. DRAKON, LabView, Simulink...). Obviously, they don't represent the way a computer works very well. Citation needed. A graphical language can "obviously" represent anything a text-based language can.

mannykannot 9y ago
One could just as validly make the much-overused "citation needed" call on the assertion in your second sentence - except that we can reasonably require a purely graphical response in this case.
- coldtea 9y ago
  What citation do you need? At the very least, a visual environment could always trivially display each syntax/AST node, which will be the same as seeing a plain text version of the code (but better -- closer to something like Apple's Dylan IDE or Smalltalk environments).
  - mannykannot 9y ago
    Strip out the text and see how clear it is.
    - arethuza 9y ago
      About as minimal a graphical representation as you can get would be to have a tree of application nodes with S and K combinators as leaf nodes. You can compile any lambda calculus expression down to S and K and "run" them as a graph. Doing this on real calculation probably wins a prize for non clarity though...
    - coldtea 9y ago
      Who said you need to "strip out the text"? Text has been part of graphical representations for milennia. The cool part is that you get to decide WHAT text you get to see -- you're not just left with seeing the lower level code. It could be that, but it can also be boxes representing objects or functions, program modules, interacting programs, at any level of abstraction one likes.

jlg23 9y ago

> arguably easier to understand than their text-based counterparts, but large programs quickly become a complete and utter mess of tangled wires and hierarchical blocks. Or the other way around: When you write a tangled mess of code you can still navigate it with /bin/grep, this gets much harder when your code is a picture (though, when stored in SVG, it should be trivial to write a /bin/svg-code-grep). BUT: If you follow pure functional design principles, you rarely have to keep more than one screenful of diagrams in your head. I think we have to differentiate between "general purpose visual programming languages" and "visual programming languages actually used". Drakon, respectively its visual aspect, for example was, afaik, developed initially to allow physicists and chemists to model their domain specific knowledge in a much more intuitive way and I think it overall succeeded there. The few snippets I saw were very convincing demos[1]. Of all the attempts at purely visual, general purpose programming languages I cannot remember one that did not fall into any of these 2 camps: * academic exploration of visual programming languages - nobody expected tangible results but we got squeak, etoys and drakon * attempts to make programming easier by people who know just enough of programming to understand it is hard[2] - they usually promise tangible results by yesterday but never deliver anything that could count as a practically usable language [1] http://drakon-practic.ru/ http://drakon-practic.ru/ [2] Excluding all environments created specifically to teach children to code - they might be turing complete but I'd not call them "general purpose".

seanmcdirmid 9y ago
I think you mean scratch, not squeak.
- jlg23 9y ago
  No, strictly speaking I was speaking of Morphic[1], squeak's main interface. But scratch[2] indeed should have been in the list. [1] https://en.wikipedia.org/wiki/Morphic_(software) https://en.wikipedia.org/wiki/Morphic_(software) [2] https://scratch.mit.edu/ https://scratch.mit.edu/
  - seanmcdirmid 9y ago

leni536 9y ago

About source control: do they have custom diff and 3-way merge tools? If they do they could potentially be used with git.

shortsightedsid 9y ago

While I don't disagree with your comment, it's a little ironic that hardware is designed visually. Instead of writing a netlist by hand, it's drawn as a schematic. The same applies to mechanical, construction or any traditional engineering fields. LabView targets engineers in those fields rather than those in software. So, you are right that visual programming doesn't represent how a computer software works.. But it's exactly how computer hardware works.

donquichotte 9y ago
I don't disagree with your comment either. In fact, my sentiment extends to hardware design, which is why I've been toying (and building real stuff for work) with SKiDL lately, a Python extension that allows for text based schematic capture for printed circuit board design. Of course, the actual routing of the traces still must be done by hand. However, during schematic capture, instead of drawing the same Zener diode input protection 100 times with a mouse, I just call the code that builds it in a loop.
- shortsightedsid 9y ago
  Interesting. I have not tried SKiDL. All my designs are in Cadence or Eagle. Thanks! I will try itout
marcosdumay 9y ago
Simple hardware is designed visually. When things get more complex people resort to hardware definition languages and scriptable CADs.
- shortsightedsid 9y ago
  I really meant circuit/physical design rather than high level design i.e pre-tapeout. Also PCBs are visually designed though I learnt about using python above and need to check that out.
  - marcosdumay 9y ago

nikofeyn 9y ago

i don't think it's obvious at all that visual programming languages don't represent how a computer works, but actually, i don't even see how that matters at all. for labview, i feel large programs benefit tremendously from its dataflow nature. every labview project i have worked on has exceeded 1,000 VIs, and it's often very easy to componentize things such that local changes stay local. labview works fine with source-code control. the diff and merge story could definitely be better, but they are at least usable, particularly the diff.

hurricaneSlider 9y ago

Source control shouldn't be a deal breaker I feel. The on disk representation would just need to be optimised for source control. For example an AST in the form of s-expressions could represent the visual structure of the program and would be amenable to VCS manipulation