6 ms·

In order to make a serious comparison of textual and visual programming, you'd be better off using a serious system such as Labview for the comparison, not a..

In order to make a serious comparison of textual and visual programming, you'd be better off using a serious system such as Labview for the comparison, not a... toy for children.

Junk_Collector 8y ago
Agreed. Simulink is an extremely serious visual programming language that powers many of our modern high technology. Spacecraft and the like. The authors point on assuming reduced complexity makes me think that he doesn't understand how complex mathematical function models are even when the block diagram looks very simple to the untrained observer.
- wenc 8y ago
  Simulink isn't really a visual programming language? It's a block-diagram simulator for simulation and analysis. You link together simulation blocks, and Simulink runs a ODE solver to "solve" for the time-varying output. Simulink can generate C code for productionization, but to write custom algorithms, you typically need to write S-functions, which are typically in C, C++ or Fortran. Visual environments let you set up topologies quickly and reliably. It's not really programming as such though -- kinda more like scaffolding. Any kind of complex logic is still more efficiently achieved in code because many abstract ideas cannot be efficiently expressed graphically. Visual abstractions are more useful for ideas that can be concretized (typically data-flows type ideas). Source: used and taught Simulink for many years for control systems engineering.
  - Junk_Collector 8y ago
    I think it really depends on how you define a programming language. Simulink can generate a variety of codes from models, the most common being C as you mentioned, but Simulink models can also be compiled into an executable using the Real-Time Workshop toolbox. This packages the simulation engine into the model. You're right about needing code scaffolding like S-functions to compile into C but those physical model simulations are often used directly in the control system program. While not efficient, thanks to Turing completeness and it's analog relatives, anything you can implement in code you could implement in Simulink flow. It took me about an hour to gin up Pong for example. I think that if it is fair to consider Scratch a visual programming language, then Simulink fits the bill.
    - wenc 8y ago
      I'm not entirely sure about that. Simulink solves an ODE (more or less) system internally. How did you write Pong in it, with interactive controls? I'm also not sure if Simulink (without S-functions, .m or any external programming language) is Turing complete, and even if it is, Turing-completeness is a very low bar for a programming system. Not trying to be contrarian, but from my experience, despite its many logic subsystems, Simulink isn't really meant to be a general purpose programming system so much as a simulation system for time-varying outputs. It's difficult to impossible to write most normal programs in it.
      - Junk_Collector 8y ago
        I wrote pong by encoding the ball position as a continuous complex variable and used a star chart (I-Q) with minimal persistence as the output. The paddle inputs were just variable sliders bound to a limit threshold equation. Ball motion was implemented as a normal physical system of momentum and boundaries. Simulink models are Turing complete. You can set a discrete clock simulation (very common with the DSP toolbox) and implement Flip-Flops/Boolean logic. They are also for lack of a better term, Shannon complete, that is they have all the analog components to satisfy general function computability. They also have flow control outside of those conditions and full memory storage. If you were infinitely bored and long lived, you could write Windows in Simulink flow logic and run the modeler to make a VM. I agree with you here. Simulink absolutely isn't meant to be a general purpose programming language. It's an extremely domain specific programming language but one that in it's specific domain offers considerable advantages over textual programming. I don't want to advocate writing software in Simulink because it's a bad idea, and I only do it myself in very limited cases because I have a hobby of analog computing and Simulink is very good for that at a certain level of abstraction. Mostly, I just take umbrage with the Article and the author's reasoning. Simulink is a counterpoint to some of his arguments but those counterpoints were made well elsewhere in the thread so I was just providing an example. Sorry if I am starting to drone on or come across hostile.
jmngomes 8y ago
Or an enterprise platform with actual enterprise customers: https://www.outsystems.com https://www.outsystems.com
- jtwaleson 8y ago
  Or their main competitor (with an online IDE): https://www.mendix.com/ https://www.mendix.com/ which was sold to Siemens earlier this year for $730M
wenc 8y ago
It's also a long-term maintenance challenge, especially when you have complex models. Great for prototyping stuff fast, but hard to maintain in production. It was designed for people who aren't programmers to be rapidly productive especially when interfacing with hardware (in a lab environment). However, debugging complex topologies can be a real challenge. We have Labview models that are being rewritten in conventional programming languages due to aforementioned challenges.
- jki275 8y ago
  It really ultimately has to be if it's to be maintained. LabVIEW is fine for basic prototyping, the problem is that EEs tend to think they've created the mona lisa of program design when they've built a barely functional prototype and then distribute it as a finished product.
dpwm 8y ago
There are people who swear by Labview, especially those more familiar with electronics than code. There are very good researchers I know of in soft condensed matter Physics who know they can't code but feel confident using Labview. One of the interesting things I found was that the 2-dimensional layout helped a lot in remembering where stuff was: this was especially useful in larger programs. I believe Labview barely scratches the surface of what is possible.
- blululu 8y ago
  Having spent a lot of time using Labview I would agree that it can be an amazingly useful tool (highly performant code and easily interfaces with data acquisition devices). That being said, LabView shows the limitations of Visual Coding: Sharp Learning Curve Difficult to find help or code snippets online Lack of decent Version Control Finding the function you want is hard (requires navigating several submenus) *All of the icon symbols look the same Also, while LabView offers a great platform for an object oriented coding style, I feel like the 2d layout always results in a messy sprawl rather than layers of abstraction. This could be because LabView is used by people with less traditional software background, or it may be that making new functions in a bit of a pain in LV.
  - Junk_Collector 8y ago
    Some of your complaints come from the fact that LabVIEW is pretty niche. It would need at least an order of magnitude more developers to see numbers like C/C++. That's why you're not finding much online help. There is also the fact that LabVIEW is old. Like REALLY old. LabVIEW came out over 30 years ago and as such has a lot of legacy cruft along with lacking some of the more modern goals such as good scaling source control. LabVIEW was also designed by a hardware first company and has always been geared towards building that hardware ecosystem. Finally, yea, poor programming practices exist in all languages. In visual languages, it makes them hard to read. Sometimes this forces you to be clever to reduce the flow complexity by increasing the logic or mathematical complexity which is it's own can of programming worms we could debate for hours.
    - 8y ago
jki275 8y ago
LabVIEW is a... toy for children.
- alliecat 8y ago
  Don't be rude. LabVIEW is used in production in a lot of serious environments.
  - jki275 8y ago
    I've been in those environments. I've had to try to repair horrific "code" written in it. I've participated in "code reviews" where the straightness of the lines was carefully assessed in the massive mess of spaghetti code they had created and thought was good code. LabVIEW is a toy for EEs to write prototypes in. That would have been okay if it had stayed there -- but the problem is that people are actually distributing "applications" using it, and trying to maintain them is nearly impossible.
    - stinos 8y ago
      I still don't get why you call it a toy, or just for prototypes. Maybe think somewhat broader and not just about the bad experience(s) you had with it. For the things it's good at, it just works and it's pretty hard to find alternatives (well, Measurement Studio is ok, but for simple things it's usually still a bit more work than Labview). The hard part is figuring out what Labview is good at and not make the mistake of trying to use it for everything. Sound like that's where most of your bad experiences come from. Here's an example of a place where Labview just shines: I needed something to plot 'rolling' analog and digital signals, i.e. basically provide a visualization of the inputs of a combined analog/digital input card. With ability to pause the thing, each line in a different color, data cursors, ... The data is acquired by C++ code, but since Labview has this stuff built in getting the whole thing up and running is just a matter of setting up a communication protocol between the C++ part and Labview. I just went for TCP/IP and got the thing up and running in a couple of hours. Has been used like that for years now. Not exactly a prototype, nor a toy. It just does this one thing, it's all we needed, and it does it extremely good.
lucozade 8y ago
I was very impressed by Mark Elendt's talk at CppCon about the Houdini system. It contains a very sophisticated visual programming "language". My view on this is that text is one of the best media we have for representing precise, information dense data. What I got from the Houdini presentation was that, when someone is trained to produce precise, information rich data using other media e.g. artists then other representations can be as effective.
- jonkalb 8y ago
  Link: https://www.youtube.com/watch?v=2YXwg0n9e7E https://www.youtube.com/watch?v=2YXwg0n9e7E
maxxxxx 8y ago
I find LabView absolutely horrible once you reach a certain level of complexity. We are converting most LabView code to C# and Measurement Studio and it's so much easier to deal with.

In order to make a serious comparison of textual and visual programming, you'd be better off using a serious system such as Labview for the comparison, not a... toy for children.

Junk_Collector 8y ago

Agreed. Simulink is an extremely serious visual programming language that powers many of our modern high technology. Spacecraft and the like. The authors point on assuming reduced complexity makes me think that he doesn't understand how complex mathematical function models are even when the block diagram looks very simple to the untrained observer.

wenc 8y ago
Simulink isn't really a visual programming language? It's a block-diagram simulator for simulation and analysis. You link together simulation blocks, and Simulink runs a ODE solver to "solve" for the time-varying output. Simulink can generate C code for productionization, but to write custom algorithms, you typically need to write S-functions, which are typically in C, C++ or Fortran. Visual environments let you set up topologies quickly and reliably. It's not really programming as such though -- kinda more like scaffolding. Any kind of complex logic is still more efficiently achieved in code because many abstract ideas cannot be efficiently expressed graphically. Visual abstractions are more useful for ideas that can be concretized (typically data-flows type ideas). Source: used and taught Simulink for many years for control systems engineering.
- Junk_Collector 8y ago
  I think it really depends on how you define a programming language. Simulink can generate a variety of codes from models, the most common being C as you mentioned, but Simulink models can also be compiled into an executable using the Real-Time Workshop toolbox. This packages the simulation engine into the model. You're right about needing code scaffolding like S-functions to compile into C but those physical model simulations are often used directly in the control system program. While not efficient, thanks to Turing completeness and it's analog relatives, anything you can implement in code you could implement in Simulink flow. It took me about an hour to gin up Pong for example. I think that if it is fair to consider Scratch a visual programming language, then Simulink fits the bill.
  - wenc 8y ago
    I'm not entirely sure about that. Simulink solves an ODE (more or less) system internally. How did you write Pong in it, with interactive controls? I'm also not sure if Simulink (without S-functions, .m or any external programming language) is Turing complete, and even if it is, Turing-completeness is a very low bar for a programming system. Not trying to be contrarian, but from my experience, despite its many logic subsystems, Simulink isn't really meant to be a general purpose programming system so much as a simulation system for time-varying outputs. It's difficult to impossible to write most normal programs in it.
    - Junk_Collector 8y ago
      I wrote pong by encoding the ball position as a continuous complex variable and used a star chart (I-Q) with minimal persistence as the output. The paddle inputs were just variable sliders bound to a limit threshold equation. Ball motion was implemented as a normal physical system of momentum and boundaries. Simulink models are Turing complete. You can set a discrete clock simulation (very common with the DSP toolbox) and implement Flip-Flops/Boolean logic. They are also for lack of a better term, Shannon complete, that is they have all the analog components to satisfy general function computability. They also have flow control outside of those conditions and full memory storage. If you were infinitely bored and long lived, you could write Windows in Simulink flow logic and run the modeler to make a VM. I agree with you here. Simulink absolutely isn't meant to be a general purpose programming language. It's an extremely domain specific programming language but one that in it's specific domain offers considerable advantages over textual programming. I don't want to advocate writing software in Simulink because it's a bad idea, and I only do it myself in very limited cases because I have a hobby of analog computing and Simulink is very good for that at a certain level of abstraction. Mostly, I just take umbrage with the Article and the author's reasoning. Simulink is a counterpoint to some of his arguments but those counterpoints were made well elsewhere in the thread so I was just providing an example. Sorry if I am starting to drone on or come across hostile.

jmngomes 8y ago

Or an enterprise platform with actual enterprise customers: https://www.outsystems.com https://www.outsystems.com

jtwaleson 8y ago
Or their main competitor (with an online IDE): https://www.mendix.com/ https://www.mendix.com/ which was sold to Siemens earlier this year for $730M

wenc 8y ago

It's also a long-term maintenance challenge, especially when you have complex models. Great for prototyping stuff fast, but hard to maintain in production. It was designed for people who aren't programmers to be rapidly productive especially when interfacing with hardware (in a lab environment). However, debugging complex topologies can be a real challenge. We have Labview models that are being rewritten in conventional programming languages due to aforementioned challenges.

jki275 8y ago
It really ultimately has to be if it's to be maintained. LabVIEW is fine for basic prototyping, the problem is that EEs tend to think they've created the mona lisa of program design when they've built a barely functional prototype and then distribute it as a finished product.

dpwm 8y ago

There are people who swear by Labview, especially those more familiar with electronics than code. There are very good researchers I know of in soft condensed matter Physics who know they can't code but feel confident using Labview. One of the interesting things I found was that the 2-dimensional layout helped a lot in remembering where stuff was: this was especially useful in larger programs. I believe Labview barely scratches the surface of what is possible.

blululu 8y ago
Having spent a lot of time using Labview I would agree that it can be an amazingly useful tool (highly performant code and easily interfaces with data acquisition devices). That being said, LabView shows the limitations of Visual Coding: Sharp Learning Curve Difficult to find help or code snippets online Lack of decent Version Control Finding the function you want is hard (requires navigating several submenus) *All of the icon symbols look the same Also, while LabView offers a great platform for an object oriented coding style, I feel like the 2d layout always results in a messy sprawl rather than layers of abstraction. This could be because LabView is used by people with less traditional software background, or it may be that making new functions in a bit of a pain in LV.
- Junk_Collector 8y ago
  Some of your complaints come from the fact that LabVIEW is pretty niche. It would need at least an order of magnitude more developers to see numbers like C/C++. That's why you're not finding much online help. There is also the fact that LabVIEW is old. Like REALLY old. LabVIEW came out over 30 years ago and as such has a lot of legacy cruft along with lacking some of the more modern goals such as good scaling source control. LabVIEW was also designed by a hardware first company and has always been geared towards building that hardware ecosystem. Finally, yea, poor programming practices exist in all languages. In visual languages, it makes them hard to read. Sometimes this forces you to be clever to reduce the flow complexity by increasing the logic or mathematical complexity which is it's own can of programming worms we could debate for hours.
  - 8y ago

jki275 8y ago

LabVIEW is a... toy for children.

alliecat 8y ago
Don't be rude. LabVIEW is used in production in a lot of serious environments.
- jki275 8y ago
  I've been in those environments. I've had to try to repair horrific "code" written in it. I've participated in "code reviews" where the straightness of the lines was carefully assessed in the massive mess of spaghetti code they had created and thought was good code. LabVIEW is a toy for EEs to write prototypes in. That would have been okay if it had stayed there -- but the problem is that people are actually distributing "applications" using it, and trying to maintain them is nearly impossible.
  - stinos 8y ago
    I still don't get why you call it a toy, or just for prototypes. Maybe think somewhat broader and not just about the bad experience(s) you had with it. For the things it's good at, it just works and it's pretty hard to find alternatives (well, Measurement Studio is ok, but for simple things it's usually still a bit more work than Labview). The hard part is figuring out what Labview is good at and not make the mistake of trying to use it for everything. Sound like that's where most of your bad experiences come from. Here's an example of a place where Labview just shines: I needed something to plot 'rolling' analog and digital signals, i.e. basically provide a visualization of the inputs of a combined analog/digital input card. With ability to pause the thing, each line in a different color, data cursors, ... The data is acquired by C++ code, but since Labview has this stuff built in getting the whole thing up and running is just a matter of setting up a communication protocol between the C++ part and Labview. I just went for TCP/IP and got the thing up and running in a couple of hours. Has been used like that for years now. Not exactly a prototype, nor a toy. It just does this one thing, it's all we needed, and it does it extremely good.

lucozade 8y ago

I was very impressed by Mark Elendt's talk at CppCon about the Houdini system. It contains a very sophisticated visual programming "language". My view on this is that text is one of the best media we have for representing precise, information dense data. What I got from the Houdini presentation was that, when someone is trained to produce precise, information rich data using other media e.g. artists then other representations can be as effective.

jonkalb 8y ago
Link: https://www.youtube.com/watch?v=2YXwg0n9e7E https://www.youtube.com/watch?v=2YXwg0n9e7E

maxxxxx 8y ago

I find LabView absolutely horrible once you reach a certain level of complexity. We are converting most LabView code to C# and Measurement Studio and it's so much easier to deal with.