I use Labview.
For anything reasonably complex, it is by far the slowest language I've worked in.
It's still 100% worth it for its use case, and 90% of what you'd want it for is not all that complex.
For anything reasonably complex, it is by far the slowest language I've worked in.
It's still 100% worth it for its use case, and 90% of what you'd want it for is not all that complex.
The main problem, I think, is that it retains the vestigial features of being designed by electrical engineers who just refused to take any lessons from the 50+ years of experience we have had with programming languages.
---> Readability
You fall into the trap of thinking a flow diagram is an easier way to understand things. You are wrong. On any project that is not trivial, it's impossible to look at things and grok what they are doing or even what they are part of, or why that cable is going into that other system. You want to know what that cable does? Better follow it through the wormhole to see what variable it is! Realized you need a variable from somewhere else? Good luck bringing it over without a) creating a rat's nest or b) making it not obvious that it is coming from miles away. I could show you a simple for loop with an iteration variable, building up an array as it goes, and it'd take you a minute to get what it does. Readability sucks. Ignored lesson #1.
---> Refactoring
Fundamentally, the way you build code in labview tends to cause the problem where stuff gets added on all the time and it's all spaghetti. Granted, you can split things out into smaller modules initially (and interfacing them sucks). But there is no simple way to refactor things after you've written spaghetti. And because it's hard to manage external imports, you will write spaghetti. Ignored lesson #2.
---> Spatial Issues
The spatial paradigm is a culprit in many of these cases. Part of the problem is that it's hard to create spatial scope and visually import variables from elsewhere, all the while making the imports clear and easy to inspect all at once.
Don't even think of keeping things tidy, wires will be everywhere, and the auto-arranger doesn't work well.
You want to add code? Well, you should have left space for it in the first place! Now you have to move all your code aside to make space for the new stuff. Are you fucking kidding me?
So, you want to copy and paste. Good luck. All your wires disappear and since you haven't memorized what the code looks like, and you have to understand the code again before rewiring everything. Just like how you have to rename variables after copy-paste except dumber and takes much longer. This is why refactoring is hard.
---> Modern Tools
Version control you say? Forget about it! No diffs, no patches, no merging, no collaborative coding. Do NOT EVER EVER use anything but the master copy of the code (tm) or otherwise you'll end up with two versions and no one will know what is in which etc. Unit testing? Costs $1500 and is total junk regardless. Continuous integration? What is that even?
---> The UI
The UI has its own misgivings. Slow as balls even on a fast computer. Limited undo (are you shitting me?). Undo history used to disappear after you saved, maybe they fixed that. The window management is a mess. Sometimes when you try to quit, it says you made changes but you have no idea what changed. Good luck if you accidentally dragged some fucking wire somewhere so that now your robot flips out when reading gyro input. You can't know.
---> The Libraries
Extremely verbose and difficult to use. (especially math and strings).
Labview is just an all-round bad experience. Like I said, they've learned NOTHING from modern programming. And yet they tout this ignorance to you (and unsuspecting electrical engineers) with pride. This is just what I have off the top of my head. I don't even have my hate-list with me (yes, I compiled one to let off steam every time something was frustrating).
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.
This is what we call "damning with faint praise".
I agree that the de-emphasis of state and the stream-based programming model are wins for LabVIEW. (Though the real win is: It seems to support every piece of lab hardware by one means or another. This is a difficult feature to give up.) It's the mere mechanics of LabVIEW programming - the need to massage a layout of wires that were difficult to draw, read, print out, diff, or version-control - that used to drive me crazy.
Though the last time this came up on HN a National Instruments employee turned up to say that things have improved since last I used LabVIEW. Apparently they've lavished attention on the design problem of virtual-wire layout and tracking.
Academic classes that introduce Labview tend to focus on basic programming tasks. This is not a good way to showcase its benefits.
That, and I was using the built in fitter to fit a straight line, that would randomly screw up the fit on data almost identical to that which it worked on the previous iteration.