6 ms·

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 y

by grueful 14y ago

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.

K2h 14y ago
Labview was the first thing that came to my mind as well. everyone thought I would love it (I am an electrical engineer) and assumed i would relate to a schematic representation to code. some may like it, but I find it far too verbose to draw code with wires and functions. I find that I far prefer writing a for loop with text than putting a window in and hiding everything behind drop downs, hidden windows and wires that go off the screen.
- grueful 14y ago
  The perks come in where situations like "I want to set up an experiment in the lab, but I want to monitor it from home so I'm not stuck there all weekend" are only slightly more difficult than Hello World. Academic classes that introduce Labview tend to focus on basic programming tasks. This is not a good way to showcase its benefits.
gizmo686 14y ago
Labview was also the first thing that came to my mind. In my experience, apart from complex number-crunching (for which it does have a stripped down textual-code vi), I found it easier to work with than java. I think that is more related to my hatred of unnecessary state (which an OOP only model supports). In Labview, the easiest way to store state is to pass the output of the vi (function) into its input at the next time it is called. I still don't enjoy using Labview, but I haven't felt like there was something I couldn't do in it (in terms of resulting program).
- mechanical_fish 14y ago
  I found [LabVIEW] easier to work with than java 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.
  - gizmo686 14y ago
    The new versions of Labview are pretty good about layout. The auto format command (^e I think) usually produces easy to read code. Diff is still pretty bad though.
jliechti1 14y ago
My experience with Labview is that it makes (relatively) difficult things easy (creating GUIs), and easy things difficult (complex number crunching).
makmanalp 14y ago
Oh god, the frustration. 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).
misnome 14y ago
I was forced to use it for some time. I used to bang my head in frustration working out how to wire something up that I'd know how to do in two lines of code. 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.

by grueful 14y ago

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.

K2h 14y ago

Labview was the first thing that came to my mind as well. everyone thought I would love it (I am an electrical engineer) and assumed i would relate to a schematic representation to code. some may like it, but I find it far too verbose to draw code with wires and functions. I find that I far prefer writing a for loop with text than putting a window in and hiding everything behind drop downs, hidden windows and wires that go off the screen.

grueful 14y ago
The perks come in where situations like "I want to set up an experiment in the lab, but I want to monitor it from home so I'm not stuck there all weekend" are only slightly more difficult than Hello World. Academic classes that introduce Labview tend to focus on basic programming tasks. This is not a good way to showcase its benefits.

gizmo686 14y ago

Labview was also the first thing that came to my mind. In my experience, apart from complex number-crunching (for which it does have a stripped down textual-code vi), I found it easier to work with than java. I think that is more related to my hatred of unnecessary state (which an OOP only model supports). In Labview, the easiest way to store state is to pass the output of the vi (function) into its input at the next time it is called. I still don't enjoy using Labview, but I haven't felt like there was something I couldn't do in it (in terms of resulting program).

mechanical_fish 14y ago
I found [LabVIEW] easier to work with than java 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.
- gizmo686 14y ago
  The new versions of Labview are pretty good about layout. The auto format command (^e I think) usually produces easy to read code. Diff is still pretty bad though.

jliechti1 14y ago

My experience with Labview is that it makes (relatively) difficult things easy (creating GUIs), and easy things difficult (complex number crunching).

makmanalp 14y ago

Oh god, the frustration. 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).

misnome 14y ago

I was forced to use it for some time. I used to bang my head in frustration working out how to wire something up that I'd know how to do in two lines of code. 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.