Re:Visual Programming and Why It Sucks
by Too on Sunday September 09, 2012 @04:51PM
(#4496943)
Thank you for saying all this so i don't have to. I also have a hate list which i don't have availible at the moment but i can easily add a few things to your list from the top of my head. Frustration really is the right word when working with labview.
The lack of diff/merge alone is reason alone not to use it. Add to this the fact that you can hide wires and blocks under other blocks, often by mistake, and you are left with a mess that can't be diffed neither by machine nor visual inspection.
Imagine a programming language where you can remove code by putting tipp-ex on it and then adding new code on top of the tipp-ex and both the new code and the old code would run.
If/switch-statments are blocks where you can only see one case at a time. Again, visual inspection takes forever since you have to manually click through every single case. Imagine a code editor where code folding is on all the time and you can only expand one section at a time. Add nested switch-statements to this and you will have a lot of fun.
The refractoring is as you say a nightmare, you start using a few blocks for a task that you later realize you have to use in 10 places so you make a subvi for it (labviews notation of functions). Now you have to manually rewire everything! Ahhh. Find and replace, forget it.
Only way to use it is the mouse, and you have to use it alot. Just accept the fact that you will get premature RSI.
Dataflow programming. Haha. Every program of scale i've seen uses the "error-in-error-out" pattern connecting every block into a fixed sequence of execution. For those of you who haven't used labview, the error-in-error out pattern is basically a big "master-wire" going through every single block to force the execution to resemble a sequence and if there is an error in any block the output will contain an error. With Dataflow programming the program is supposed to choose execution path automatically by lazy evalutation so you don't have to, but with error-in-error-out you loose all that benefit.
Readability...yes. Any function that is not a simple mathematical operation or some standard block from control theory is impossible to figure out how it works without opening up. Have you ever seen bad function names? Wait until you see badly drawn 32x32px blocks trying to explain 1. What they do and 2. What the different inputs/outputs mean.
Try to draw array_map(), substring(), implode() or any other favorite function from your standard lib into a 32x32px icon. You will probably end up with a few boxes pointing at each other. And EVERY function will look like this! I tell you, putting chinese characters in the boxes would be easier to understand.
Another funny thing is opening a vi that someone with a 32" inch 6400x4000px resolution created when you yourself is on a shitty 15" laptop. You have to scroll back and forth both vertically and horizontally like a mad man. Minimum requirement for being close to productive is 2x 24" monitions.
-----------
It does however have some bright sides i havn't seen in any other languages. One thing i like is that if-statements always work like the ternary operator(disregard the ternary operators ugly syntax in most languages). You are forced to assign the output to a variable in all cases as soon as you assign to it in any other case. This makes it impossible to miss assignment for odd cases and you can always trace the dependencies and follow the source of the variable. Basically you create a new variable every time you go through an if-box where assignment happens inside the box and after that you don't have to worry that your old variable is used anywhere anymore.
Another nice thing is that once you realize wires=variables, you can quickly determine how much state your application uses, not for performance reasons, but more for logical reasoning.
The type system is also interesting. The best way to describe it is typesafe ducktyping. Say you have a function sum(x,y) { return x+y }. If you wire an integer to the x-input the output will automatically become an integer, if you wire a float to the input the output becomes a float. And this is determined at compile time! If you wire the float output to another int output you will get compile time error! Actually even before compile time because you will see the error as soon as you connect the wires.
The lack of diff/merge alone is reason alone not to use it. Add to this the fact that you can hide wires and blocks under other blocks, often by mistake, and you are left with a mess that can't be diffed neither by machine nor visual inspection.
Imagine a programming language where you can remove code by putting tipp-ex on it and then adding new code on top of the tipp-ex and both the new code and the old code would run.
If/switch-statments are blocks where you can only see one case at a time. Again, visual inspection takes forever since you have to manually click through every single case. Imagine a code editor where code folding is on all the time and you can only expand one section at a time. Add nested switch-statements to this and you will have a lot of fun.
The refractoring is as you say a nightmare, you start using a few blocks for a task that you later realize you have to use in 10 places so you make a subvi for it (labviews notation of functions). Now you have to manually rewire everything! Ahhh. Find and replace, forget it.
Only way to use it is the mouse, and you have to use it alot. Just accept the fact that you will get premature RSI.
Dataflow programming. Haha. Every program of scale i've seen uses the "error-in-error-out" pattern connecting every block into a fixed sequence of execution. For those of you who haven't used labview, the error-in-error out pattern is basically a big "master-wire" going through every single block to force the execution to resemble a sequence and if there is an error in any block the output will contain an error. With Dataflow programming the program is supposed to choose execution path automatically by lazy evalutation so you don't have to, but with error-in-error-out you loose all that benefit.
Readability...yes. Any function that is not a simple mathematical operation or some standard block from control theory is impossible to figure out how it works without opening up. Have you ever seen bad function names? Wait until you see badly drawn 32x32px blocks trying to explain 1. What they do and 2. What the different inputs/outputs mean. Try to draw array_map(), substring(), implode() or any other favorite function from your standard lib into a 32x32px icon. You will probably end up with a few boxes pointing at each other. And EVERY function will look like this! I tell you, putting chinese characters in the boxes would be easier to understand.
Another funny thing is opening a vi that someone with a 32" inch 6400x4000px resolution created when you yourself is on a shitty 15" laptop. You have to scroll back and forth both vertically and horizontally like a mad man. Minimum requirement for being close to productive is 2x 24" monitions.
-----------
It does however have some bright sides i havn't seen in any other languages. One thing i like is that if-statements always work like the ternary operator(disregard the ternary operators ugly syntax in most languages). You are forced to assign the output to a variable in all cases as soon as you assign to it in any other case. This makes it impossible to miss assignment for odd cases and you can always trace the dependencies and follow the source of the variable. Basically you create a new variable every time you go through an if-box where assignment happens inside the box and after that you don't have to worry that your old variable is used anywhere anymore.
Another nice thing is that once you realize wires=variables, you can quickly determine how much state your application uses, not for performance reasons, but more for logical reasoning.
The type system is also interesting. The best way to describe it is typesafe ducktyping. Say you have a function sum(x,y) { return x+y }. If you wire an integer to the x-input the output will automatically become an integer, if you wire a float to the input the output becomes a float. And this is determined at compile time! If you wire the float output to another int output you will get compile time error! Actually even before compile time because you will see the error as soon as you connect the wires.