Labview Spaghetti

« Return to Article
  • JakeyC 2011-05-16 09:01
    I'd like to think that after all that, the output is just "Hello World".
  • gac 2011-05-16 09:06
    JakeyC:
    I'd like to think that after all that, the output is just "Hello World".
    That might be the intended output, but it'll almost definitely just crash until National Instruments have helped troubleshoot it over the phone and pointed out which non-documented bits of version-specific code you need to insert, and which as-yet-unreleased toolbox you need to install to make it work.
  • Mike Caron 2011-05-16 09:08
    What does it do? Without context, it may be justifiable.

    (That said, +1 for literal spaghetti code)
  • Madmanguruman 2011-05-16 09:08
    That's actually fairly clean code compared to some LabVIEW that I've seen. If you want to really scare them, do a print-screen of the VI hierarchy for that pictured VI ... think "plans for the Death Star"...
  • QJ 2011-05-16 09:09
    I just tried to edit it in Visio, having got it confused with the document that I'm in charge of keeping updated (another change in requirement, y'know). This sort of thing is worldwidely popular.
  • Donald 2011-05-16 09:10
    Waiting for scary print-screen.
  • 13olle 2011-05-16 09:11
    yes looks very very familar.

    and its made me sad
  • Asiago Chow 2011-05-16 09:15
    I'm not sure if this is why you should, or shouldn't, teach would-be software people some basic electrical engineering.

    On the one hand, if whoever wrote that interface hadn't been an EE, they wouldn't have used the schematic metaphor and the screenshot never would've bubbled up here.

    On the other...if the person freaked out by that image had learned to deal with schematics for even mildly complicated circuit boards, they would shrug off that image as nothing special and it never would've bubbled up here.

    Not judging the quality of the software depicted...I don't know what problems they were trying to solve and I've never used labview.
  • Julia 2011-05-16 09:15
    ...and can you find the six hidden lollipops in the picture?
  • Hoffmann 2011-05-16 09:19
    Lollipops? I found walter (twice)!
  • undefined 2011-05-16 09:21
    Mike Caron:
    What does it do? Without context, it may be justifiable.

    (That said, +1 for literal spaghetti code)


    Mach numbers, EPOS and Omega (), air and fuel pressures, position sensors... It must be something like F-35 aircraft or high-end swiss watch.
  • Lorne Kates 2011-05-16 09:21
    Why would early 21st century humans make something this complex and convoluted. No no no-- HOW could they make something this complex and convoluted. Not on their own-- no, wait, why was a better question. Yes, and the answer..



    EXTERMINATE!!!!
  • J 2011-05-16 09:22
    Nothing a stiff drink can't fix, especially when it is chased by a few more.
  • Herbert 2011-05-16 09:22
    Great. So some people write ugly code in LabVIEW code. Can you find a language that a dedicated programmer *couldn't* write ugly code in with sufficient determination?
  • Zelda 2011-05-16 09:23
    Hoffmann:
    Lollipops? I found walter (twice)!


    I only found Waldo...
  • frits 2011-05-16 09:24
    Do you see what happens when test engineers try to avoid programming?

    Look at it!!!

    Repeat after me: "VI is TRWTF."
  • Will 2011-05-16 09:24
    I think my favourite part is that they're using windows.
  • notromda 2011-05-16 09:26
    The Real WTF is Windows.
  • Severity One 2011-05-16 09:35
    Mike Caron:
    What does it do?

    Credit card processing, of course. After all, it says VISA; no doubt the Mastercard and American Express are in a part of the program that is not visible.
  • frits 2011-05-16 09:41
    Mike Caron:
    What does it do? Without context, it may be justifiable.

    (That said, +1 for literal spaghetti code)


    It controls a wind tunnel by measuring temperature and air pressure, and providing feedback to a wind generator, of course.

    BTW- All Labview code is spaghetti code. It's the "wires" that make it look that way.
  • Zylon 2011-05-16 09:42
    Mike Caron:
    What does it do? Without context, it may be justifiable.

    (That said, +1 for literal spaghetti code)

    And a -1 to you for misusing the word "literally".
  • Anon 2011-05-16 09:46
    QJ:
    I just tried to edit it in Visio, having got it confused with the document that I'm in charge of keeping updated (another change in requirement, y'know). This sort of thing is worldwidely popular.


    I think you might have misunderstood. That isn't a document describing the LabView program. LabView is a graphical programming language, and that is the ACTUAL LabView program.
  • Nagesh 2011-05-16 09:49
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.
  • Nagesh 2011-05-16 09:49
    JakeyC:
    I'd like to think that after all that, the output is just "Hello World".

    Well said, from point of view user who write complexity only of "Hello, World!" program. Now, if you exusing Nagesh, I will writing some serious code.
  • tarnold 2011-05-16 09:56
    You can do a Google picture search for [cycling74 Max] and find similar pictures, this is how programs in graphical programming languages look like. Max is designed for real-time audio synthesis and DSP, and if you've ever seen a classical analog synthesizer environment, the usual cable chaos literally looks like Spaghetti...
  • tarnold 2011-05-16 09:56
    You can do a Google picture search for [cycling74 Max] and find similar pictures, this is how programs in graphical programming languages look like. Max is designed for real-time audio synthesis and DSP, and if you've ever seen a classical analog synthesizer environment, the usual cable chaos literally looks like Spaghetti...
  • Pete 2011-05-16 10:02
    Madmanguruman:
    That's actually fairly clean code compared to some LabVIEW that I've seen. If you want to really scare them, do a print-screen of the VI hierarchy for that pictured VI ... think "plans for the Death Star"...


    Many Bothans died to bring us this information
  • grumpy 2011-05-16 10:15
    Herbert:
    Great. So some people write ugly code in LabVIEW code. Can you find a language that a dedicated programmer *couldn't* write ugly code in with sufficient determination?


    Whitespace...?
  • Yair 2011-05-16 10:15
    That code is terrible (and that's the programmer's fault, not LabVIEW's), but if I had to guess, I would guess that it probably does mostly work.

    Also, with terms like pitch, yaw, mach, air and tunnel strewn around the code, I wouldn't be surprised if the wind tunnel option someone referred to earlier is the correct answer.

    P.S.:




    P.P.S. Here are some other bad LabVIEW diagrams I collected over time. The tinted floating window shows a zoomed out version of the code:




  • boog 2011-05-16 10:23
    This map is confusing. All the big arrows point east and I can't find the interstate anywhere. Who labeled this thing?
  • Axel 2011-05-16 10:23
    Doesn't look more cryptic than Haskell
  • wingcommander 2011-05-16 10:25
    > I think you might have misunderstood. That isn't a document describing the LabView program. LabView is a graphical programming language, and that is the ACTUAL LabView program.

    Exactly so. I use (and sometimes teach) Labview. Many people who use text-oriented languages hate it. However- when used properly- (and this example is a long way from "properly") it can be efficient to write, hierarchical, and re-usable.

    One of the challenges in teaching Labview is persuading people to forget (temporarily) text-based languages.
  • Kiss me I'm Polish 2011-05-16 10:25
    Is it actually possible to draw / write clean code in LabView?
    It kind of looks like a filmstrip, is there a direction to follow?
  • A Gould 2011-05-16 10:25
    Herbert:
    Great. So some people write ugly code in LabVIEW code. Can you find a language that a dedicated programmer *couldn't* write ugly code in with sufficient determination?


    Lolcode. Fairly sure anything written in that language is funny by definition.
  • Steve 2011-05-16 10:27
    Would some of the LabView evangelists please post screenshots of LabView programs that aren't incomprehensible? I've never seen one before. (That last one by Yair is about the best I've ever encountered).
  • Meep 2011-05-16 10:27
    Yar, used labview once, didn't think it was a bad concept, but there's *way* too much futzing around to line things up neatly.

    (Not that I haven't seen people spend hours drawing box comments in ASCII...)
  • Meep 2011-05-16 10:29
    Steve:
    Would some of the LabView evangelists please post screenshots of LabView programs that aren't incomprehensible? I've never seen one before. (That last one by Yair is about the best I've ever encountered).


    Not an evangelist, but I've used it and thought that, while it takes some work to understand, it's not bad.

    Any complex machine is going to take some work to comprehend. Ever tried reading a patent?
  • HellKarnassus 2011-05-16 10:31
    Kiss me I'm Polish:
    Is it actually possible to draw / write clean code in LabView?

    No, it's impossible. When a single boolean or arithmetic operation takes at least three drawings and two wires then you're in for a WTF.
  • Boris Vladamir 2011-05-16 10:32
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!
  • just me 2011-05-16 10:34
    tarnold:
    You can do a Google picture search for [cycling74 Max] and find similar pictures, this is how programs in graphical programming languages look like. Max is designed for real-time audio synthesis and DSP, and if you've ever seen a classical analog synthesizer environment, the usual cable chaos literally looks like Spaghetti...

    Not true. You can actually write quite clean and understandable code in MaxMSP once you know the caveats and apply some discipline (and probably in LabVIEW too, but I've never done anything in this order of complexity in LabVIEW).

    In this respect, graphical programming is not very much different from textual programming.

    I would post some screen shots, but my Max patchers are at home and I am at work.
  • tom103 2011-05-16 10:36
    TRWTF is LabView...
  • HellKarnassus 2011-05-16 10:39
    tom103:
    TRWTF is LabView...

    Seriously, it sits way above VB and PHP in the scale of WTFness
  • Harold III, Sr. 2011-05-16 10:42
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.
  • mung 2011-05-16 10:43
    It is actually possible to produce clean, well documented code in LabView. I write tons of LabView code, and none of it looks like that! NI provides style sheets, and design patterns that programmers can use to create neat diagrams. That being said, LabView does provide spaghetti coders a whole new realm of possibilities. It is incredibly easy to end up with a rats-nest if you do not know what you are doing.

  • Meep 2011-05-16 10:46
    HellKarnassus:
    Kiss me I'm Polish:
    Is it actually possible to draw / write clean code in LabView?

    No, it's impossible. When a single boolean or arithmetic operation takes at least three drawings and two wires then you're in for a WTF.


    Computers are hard!!!!! Call the waaaaaaaahmbulance!
  • Meep 2011-05-16 10:47
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Clearly the idiot is someone who thinks they're going to have graphite dust floating around sensitive electronics.
  • Steve 2011-05-16 10:49
    Meep:
    Steve:
    Would some of the LabView evangelists please post screenshots of LabView programs that aren't incomprehensible? I've never seen one before. (That last one by Yair is about the best I've ever encountered).


    Not an evangelist, but I've used it and thought that, while it takes some work to understand, it's not bad.

    Any complex machine is going to take some work to comprehend. Ever tried reading a patent?


    I don't expect to take one look and instantly know what it does, I just want to see a screenshot that doesn't look like a rats nest. I want to get a sense of organization. I shouldn't have to print the whole dang thing out and trace it with highlighters to figure out how things are connected. That's why I pointed out Yair's screenshot -- the second one does actually appear to have a "flow", but it's just a little too dense.

    Just saying "yeah, I write really great LabView code all the time" isn't very convincing. Pics or it didn't happen.
  • Peter 2011-05-16 10:49
    If this is actually the control program for a transsonic wind tunnel, as it appears to be, TRWTF is using Labview to control something that can kill you.

    Somone has much more faith in National Instruments and Labview than I do.
  • Nagesh 2011-05-16 10:54
    Meep:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Clearly the idiot is someone who thinks they're going to have graphite dust floating around sensitive electronics.


    yes pencil shaving is dangerus in instruments in space. Boris (fake rusian) you have been outed. so quit posting.
  • HipHopAnonymous 2011-05-16 10:56
    I programmed a fair bit of LABView in college. The trick to writing clean code is utilization of modules, sequence frames, and loop structures, which is obviously not happening here. LABView isn't terrible for non-programmer types, and it has great libraries for connecting to various instruments, but I wouldn't go back to it unless I absolutely had to.
  • Nagesh 2011-05-16 10:59
    Meep:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Clearly the idiot is someone who thinks they're going to have graphite dust floating around sensitive electronics.

    If well-designed being electronics, they are not to be suffering with dust, graphite or otherwise. Outside condo window every day I see Internet Cafe witnessing smokers ash falling all over laptops. Have never seen these Windows 98 machines being replaced.
  • Your Dad 2011-05-16 11:00
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    Maybe they would have had time to design an anti-gravity pen if they weren't so busy Russian into space.
  • C-Octothorpe 2011-05-16 11:00
    Nagesh:
    Boris (fake rusian) you have been outed. so quit posting.



    Pot, meet kettle...
  • Nagesh 2011-05-16 11:06
    Nagesh (fake):
    Meep:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Clearly the idiot is someone who thinks they're going to have graphite dust floating around sensitive electronics.

    If well-designed being electronics, they are not to be suffering with dust, graphite or otherwise. Outside condo window every day I see Internet Cafe witnessing smokers ash falling all over laptops. Have never seen these Windows 98 machines being replaced.


    madarchod!
  • Lv Guy 2011-05-16 11:07
    Trust me, if this guy did text-based coding, it would look just as bad. If he had any idea how to create subVIs (function) this wouldn't look half bad. This is basically a program with one giant function.
  • Brett Thwaites 2011-05-16 11:07
    notromda:
    The Real WTF is Windows.


    Since when is Windows 7 a WTF?
  • Childish 2011-05-16 11:07
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!


    The NASA space pen story is false.
  • Harold III, Sr. 2011-05-16 11:08
    Nagesh:
    Meep:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Clearly the idiot is someone who thinks they're going to have graphite dust floating around sensitive electronics.

    If well-designed being electronics, they are not to be suffering with dust, graphite or otherwise. Outside condo window every day I see Internet Cafe witnessing smokers ash falling all over laptops. Have never seen these Windows 98 machines being replaced.

    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?
  • Someone who can't be bothered to login from work 2011-05-16 11:10
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    NASA and the Russians both used pencils to start off with; Fisher actually developed his pens independently and sold them to both the Americans and the Russians after he'd completed his development (although I think the Russians did adopt them later than NASA).
  • Nagesh 2011-05-16 11:14
    Someone who can't be bothered to login from work:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    NASA and the Russians both used pencils to start off with; Fisher actually developed his pens independently and sold them to both the Americans and the Russians after he'd completed his development (although I think the Russians did adopt them later than NASA).

    Why does NASA being employed fisherman for this task?
  • Yair 2011-05-16 11:14
    Steve:
    Would some of the LabView evangelists please post screenshots of LabView programs that aren't incomprehensible? I've never seen one before. (That last one by Yair is about the best I've ever encountered).



    Actually, both of those are really bad examples, because they're very dense and messy.

    Here's an example of one of the functions in the project I currently have opened. It doesn't have any comments, but I can tell you that every time you call it like this it adds a line to a log with timing info and error details (if there was an error) and optionally saves the log to a pipe delimited text file.




    Like other languages, LabVIEW has advantages and disadvantages. Some of the advantages include:

    1. Easy to get started with.
    2. Automatic memory management (and it had that for almost 25 years). No need to assign variables, etc.
    3. Writing parallel code is extremely easy and is almost unavoidable.
    4. The function shown above, for instance, has two return parameters and could have several more if I wanted it to.


    Some of the disadvantages:

    1. Easy to get started with, so you get untrained users.
    2. Automatic memory management, so your options of controlling memory allocations are limited. Might be an issue under some circumstances.
    3. Writing parallel code is extremely easy. If you don't know what you're doing, you're going to have lots and lots of race conditions.
    4. Working with SCC is a big issue, although recent versions of LabVIEW have improved this somewhat. Basic work (check in, check out, commit, update) is not much of an issue, but diffing and merging are. Again, this is not necessarily an issue, depending on your needs.
  • frits 2011-05-16 11:15
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
  • tragomaskhalos 2011-05-16 11:21
    I am working on a project that uses a somewhat similar "visual programming" tool for a lot of its functionality. In my experience these things:
    a) look great in demos to non-technical types (hence sales);
    b) can be good for cobbling something together quickly;
    c) become completely and horribly unmanageable if you try to do anything even remotely complex.
    And since in any non-trivial system (c) will predominate ...
  • iToad 2011-05-16 11:26
    Unfortunately, most LabVIEW code is written by end users, not programmers. I just inherited a pile of literal spahegetti code from the original author to see if I could clean it up, and eliminate a bunch of race conditions and a mysterious latch-up problem.

    One of the first things that I did was create a concurrent state machine description of the logic, and a text-based specification of what all of the sub VIs did. The original developer was astonished. He didn't realize that you could actually design the software before writing it. I also introduced him to comments.

    Moral of the story: Inheriting a large, badly written VBA application is bad. Inheriting a large, badly written LabVIEW application is very bad.
  • just me 2011-05-16 11:32
    tragomaskhalos:
    I am working on a project that uses a somewhat similar "visual programming" tool for a lot of its functionality. In my experience these things:
    a) look great in demos to non-technical types (hence sales);
    b) can be good for cobbling something together quickly;
    c) become completely and horribly unmanageable if you try to do anything even remotely complex.
    And since in any non-trivial system (c) will predominate ...

    c) only if you don't know what you're doing, or if the platform does not provide adequate tools for managing the complexity. LabVIEW does provide these tools (most importantly sub-VIs), so does MaxMSP (sub-patchers).

    The above applies just as well for any text-based languages, so what was your point again?
  • Ganesh 2011-05-16 11:35
    HellKarnassus:
    Kiss me I'm Polish:
    Is it actually possible to draw / write clean code in LabView?

    No, it's impossible. When a single boolean or arithmetic operation takes at least three drawings and two wires then you're in for a WTF.

    To get a single wire from a boolean, it has to have only a single possible outcome (making it not really an operation at all)? So what simplification do you propose?
  • Nagesh 2011-05-16 11:39
    Nagesh(fake):
    Someone who can't be bothered to login from work:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    NASA and the Russians both used pencils to start off with; Fisher actually developed his pens independently and sold them to both the Americans and the Russians after he'd completed his development (although I think the Russians did adopt them later than NASA).

    Why does NASA being employed fisherman for this task?


    madarchod,
    everyone in my compny has heard of fisher pen manufactrer.
  • Richard 2011-05-16 11:40
    Thankfully you can interface to most of the NI devices from C, and you don't need labview at all.

    Incidentally, I have the interesting problem of an NI4462 card which was sold to me a few months ago as being "supported on Linux". This support uses a nasty binary blob kernel driver that is only available for distros about 4 years old (eg Mandrake 2008). Not impressed
  • Anonymous 2011-05-16 11:43
    I'm not really seeing the WTF here, any sufficiently complex LabView system ends up looking like that. Unless the WTF is LabView itself, in which case I wholeheartedly agree.
  • boog 2011-05-16 11:44
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?
  • Nagesh 2011-05-16 11:51
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    मादरचोद,
    तुम खुद को क्या सम्ह्जते हो?
  • tragomaskhalos 2011-05-16 11:52
    just me:
    tragomaskhalos:
    I am working on a project that uses a somewhat similar "visual programming" tool for a lot of its functionality. In my experience these things:
    a) look great in demos to non-technical types (hence sales);
    b) can be good for cobbling something together quickly;
    c) become completely and horribly unmanageable if you try to do anything even remotely complex.
    And since in any non-trivial system (c) will predominate ...

    c) only if you don't know what you're doing, or if the platform does not provide adequate tools for managing the complexity. LabVIEW does provide these tools (most importantly sub-VIs), so does MaxMSP (sub-patchers).

    The above applies just as well for any text-based languages, so what was your point again?


    In the case of the product we are using, it does not provide adequate tools, no - in LabVIEW, which I've not used, YMMD. For example on our project I have reimplemented a big wodge of it in Ruby - goodbye to unwieldy tangled and deeply nested diagrams, hello to succinct DSL-style notation with all the gubbins hidden away. This is the proper way to manage complexity, and is what a properly utilised text-based language will give you.

    Nor does point (a) apply to text-based languages - a big score for visual programming tools in the sales and marketing area is that they are pretty and colourful and allow for an easy sell of the seductive myth that non-programmers can use the thing, but what looks good in demos can quickly unravel in real use.
  • Anonymous 2011-05-16 11:53
    Nagesh:
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    मादरचोद,
    तुम खुद को क्या सम्ह्जते हो?

    Your handwriting sucks, I can't make out a word of that.
  • Nagesh 2011-05-16 11:53
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?

    I am Indian only.
  • Nagesh 2011-05-16 11:58
    Anonymous:
    Nagesh:
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    मादरचोद,
    तुम खुद को क्या सम्ह्जते हो?

    Your handwriting sucks, I can't make out a word of that.


    पहले हिंदी सीखो बच्चे!
  • boog 2011-05-16 12:06
    Nagesh:
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    मादरचोद,
    तुम खुद को क्या सम्ह्जते हो?
    मैं माफी चाहता हूँ.
    मैं हिंदी बोलते नहीं.
  • Boris Vladamir 2011-05-16 12:07
    Nagesh:
    Anonymous:
    Nagesh:
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    मादरचोद,
    तुम खुद को क्या सम्ह्जते हो?

    Your handwriting sucks, I can't make out a word of that.


    पहले हिंदी सीखो बच्चे!

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.
  • frits 2011-05-16 12:07
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    I think you could make just as sound an argument that no black people are reading this site. Why not go there?
  • Nagesh 2011-05-16 12:09
    Boris Vladamir:
    Nagesh:
    Anonymous:
    Nagesh:
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    मादरचोद,
    तुम खुद को क्या सम्ह्जते हो?

    Your handwriting sucks, I can't make out a word of that.


    पहले हिंदी सीखो बच्चे!

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.

    I am not to be spaking the Chinese! Talk clearly, manglerod!
  • frits 2011-05-16 12:10
    Boris Vladamir:
    Nagesh:
    Anonymous:
    Nagesh:
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    मादरचोद,
    तुम खुद को क्या सम्ह्जते हो?

    Your handwriting sucks, I can't make out a word of that.


    पहले हिंदी सीखो बच्चे!

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.


    I'm tired of these MF'n eels in this MF'n hovercraft!
  • boog 2011-05-16 12:10
    Nagesh:
    boog:
    frits:
    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?

    I am Indian only.
    That's highly unlikely.
  • just me 2011-05-16 12:14
    tragomaskhalos:
    ... the seductive myth that non-programmers can use the thing...


    Yes, there's your problem right there.
  • C-Octothorpe 2011-05-16 12:15
    boog:
    Nagesh:
    boog:
    frits:
    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?

    I am Indian only.
    That's highly unlikely.


    Racist!

    What? Am I doing it wrong?
  • Yair 2011-05-16 12:22
    Anonymous:
    any sufficiently complex LabView system ends up looking like that.


    Not "any". "Many". If it's written well, it doesn't look like that, regardless of how complex it is.
  • boog 2011-05-16 12:32
    frits:
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    I think you could make just as sound an argument that no black people are reading this site. Why not go there?
    Fine, I'll go there: If someone insults black people and no black people are around to hear it, are they offended? Technically, no, but that doesn't make it okay, and it doesn't mean anyone else can't be offended too.

    Did you think I was advocating comments offensive to Indians?
  • wakaw 2011-05-16 12:32
    Yeah, like CERN.
  • Al 2011-05-16 12:33
    By the way, is it possible to avoid creation of new file for every function (subVI). I understand that it's not inherently evil, but it just freaks me out a little.
  • Meep 2011-05-16 12:34
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    Yeah, last I heard, the actual Indians were off whining to Congress about how the Bin Laden's code name was Geronimo.
  • Steve 2011-05-16 12:37
    Thanks Yair, that's what I was looking for. Nice breakdown on the advantages/disadvantages too.
  • frits 2011-05-16 12:38
    boog:
    frits:
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    I think you could make just as sound an argument that no black people are reading this site. Why not go there?
    Fine, I'll go there: If someone insults black people and no black people are around to hear it, are they offended? Technically, no, but that doesn't make it okay, and it doesn't mean anyone else can't be offended too.

    Did you think I was advocating comments offensive to Indians?


    You may want to at least delete the context if you're going to write something silly.
  • frits 2011-05-16 12:38
    Meep:
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    Yeah, last I heard, the actual Indians were off whining to Congress about how the Bin Laden's code name was Geronimo.


    Is that where Hoodaticus has been?
  • BentFranklin 2011-05-16 12:43
    In that Snopes article, they twice refer to 100% oxygen atmosphere. Really? 100%? That doesn't seem right. Anyone know this for sure?
  • alegr 2011-05-16 12:48
    Boris Vladamir:

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.
    Somebody has too much trust to Google translator...
  • Anon 2011-05-16 12:54
    Herbert:
    Great. So some people write ugly code in LabVIEW code. Can you find a language that a dedicated programmer *couldn't* write ugly code in with sufficient determination?


    The difference is, in LabVIEW, it's impossible not to write ugly code.
  • Yair 2011-05-16 12:58
    Al:
    By the way, is it possible to avoid creation of new file for every function (subVI). I understand that it's not inherently evil, but it just freaks me out a little.


    Not that this is the place for it, but the answer is no, at least not in the way you want it. LV has two file types which allow saving several VIs inside a single file, but I'm pretty sure that's not what you're after, since you would still need to do all the creation of the VI, etc.

    But it's not a big deal. You get used to it.
  • boog 2011-05-16 12:59
    frits:
    You may want to at least delete the context if you're going to write something silly.
    Duly noted. From now on I'll try to be serious about making silly comments.
  • r2k-in-the-vortex 2011-05-16 13:03
    ah the good ol labview, the very first software project i was tasked to finish looked pretty much like that, in fact first thing i suspected when i opened the artice that it actually was that project. labview has its strong points but they dont lie in making large and complicated applications. its for pretty much what the name says its for, quickly tying together a lab setup by someone who is not nessecarily a programmer. pretty much any measurement equipment comes with labview drivers so for lab technicians its very simple to coordinate many instruments with quick hack of a labview. unfortunately it sometimes also gets used for lot more complicated things and then it ends up like that. it can be a horrorshow
  • Anon 2011-05-16 13:05
    Ah...I hate LabVIEW with a passion. Note that until a few years ago, you couldn't even comment out a portion of your code in LabVIEW, you had to disconnect the "wires" manually, tie together any that couldn't be left dangling, and then when you wanted to put it back in, you'd have to try and remember all the connections you removed so you can put them back again.
    Also, the GUIs generated by LabVIEW are the ugliest things you've ever seen. They may have looked slick in Windows 3.1, but now they look horribly dated with no real easy options to make it look modern. We had a horrible LabVIEW software for a propriety device we developed that looked like shit and ran like it too. I scrapped it and wrote a new software in C# using WPF and now it looks awesome, modern and gets rid of all the stupid GUI baggage that came from LabVIEW.
  • Vaca Loca 2011-05-16 13:09
    Note to self: Do not read the comments section of a WTF until 2 days after said article has posted and subsequent comment purge has occurred.

  • undefined 2011-05-16 13:09
    Boris Vladamir:

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.


    1. You can not to use on-line automatic translation to produce correct russian sentences.

    2. There are no middle names in Russian, we use http://en.wikipedia.org/wiki/Patronymic#Russian
  • r2k-in-the-vortex 2011-05-16 13:10
    gac:
    JakeyC:
    I'd like to think that after all that, the output is just "Hello World".
    That might be the intended output, but it'll almost definitely just crash until National Instruments have helped troubleshoot it over the phone and pointed out which non-documented bits of version-specific code you need to insert, and which as-yet-unreleased toolbox you need to install to make it work.

    heheh been there done that, they have a very helpful forum where you can get that 'particular version of a dll to put into your gac to get your code to compile'. NI softwares really arent meant for mass deployemnt, they suck at that too. but if you need to get a complicated process coordinated, make tons of measurements, control your prodcution line hardware etc, NI has the thing for you
  • Anon 2011-05-16 13:10
    Yair:

    Some of the disadvantages:

    1. Easy to get started with, so you get untrained users.
    2. Automatic memory management, so your options of controlling memory allocations are limited. Might be an issue under some circumstances.
    3. Writing parallel code is extremely easy. If you don't know what you're doing, you're going to have lots and lots of race conditions.
    4. Working with SCC is a big issue, although recent versions of LabVIEW have improved this somewhat. Basic work (check in, check out, commit, update) is not much of an issue, but diffing and merging are. Again, this is not necessarily an issue, depending on your needs.


    5. GUIs look like shit. All those controls that are supposed to look like rocker switches, dials and LEDs just look awful and unprofessional.
    6. Is a proprietary language owned by National Instruments, meaning that it's very difficult to do anything with LabVIEW code without buying LabVIEW from NI. If NI disappear, all that LabVIEW code will be practically useless (especially since recent versions of LabVIEW require online activation).
    7. Is a nightmare to upgrade when NI crap out a new version and pretty much impossible to downgrade to an earlier version.
  • Yazeran 2011-05-16 13:12
    iToad:
    Unfortunately, most LabVIEW code is written by end users, not programmers. I just inherited a pile of literal spahegetti code from the original author to see if I could clean it up, and eliminate a bunch of race conditions and a mysterious latch-up problem.

    One of the first things that I did was create a concurrent state machine description of the logic, and a text-based specification of what all of the sub VIs did. The original developer was astonished. He didn't realize that you could actually design the software before writing it. I also introduced him to comments.

    Moral of the story: Inheriting a large, badly written VBA application is bad. Inheriting a large, badly written LabVIEW application is very bad.


    Amen!

    I have also heard a lot of people saying LabView is soo good: 'you can just take your instrument and within a few minutes get a graph of what it is measuring'. All well and good, but add some 20 different devices (of some 5 to 10 different types) and all of a sudden you end up with some spahgetti like the one shown.
    My beef is that you still can't get a screen big enough that you can properly debug any LabView program doing anything remotely interesting. Add to that some interesting race conditions and you are set for disaster....

    I would prefer a program written in C anytime over Labview, as in C at least you know exactly in which order things get executed, and in my experience, in 99% of the time you never need to do things asynchronous anyways. If your application/problem requires that, then it gets more complicated, but then Labview may not be your choice regardless....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer.
  • zenstain 2011-05-16 13:14
    So you've filched Microsoft's plans for the Zune replacement, impressive.
  • Nagesh 2011-05-16 13:14
    boog:
    Nagesh:
    boog:
    frits:
    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?

    I am Indian only.
    That's highly unlikely.

    Why you think that booger boy?
  • Nagesh 2011-05-16 13:16
    boog:
    Nagesh:
    boog:
    frits:
    Harold III, Sr.:
    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?

    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?


    मादरचोद,
    तुम खुद को क्या सम्ह्जते हो?
    मैं माफी चाहता हूँ.
    मैं हिंदी बोलते नहीं.


    Itis "Bolta" and not "Boltey", dumbass. Get better kwality of Indian person to translete.
  • undefined 2011-05-16 13:16
    Richard:
    Incidentally, I have the interesting problem of an NI4462 card which was sold to me a few months ago as being "supported on Linux". This support uses a nasty binary blob kernel driver that is only available for distros about 4 years old (eg Mandrake 2008). Not impressed


    TRWTF is absence of stable kernel driver APIs in Linux.
  • BitHead 2011-05-16 13:17
    BentFranklin:
    In that Snopes article, they twice refer to 100% oxygen atmosphere. Really? 100%? That doesn't seem right. Anyone know this for sure?
    Wikepedia says it's so (http://en.wikipedia.org/wiki/Apollo_1), and the references back it up. Seems NASA chose 100% oxygen atmosphere to avoid some of the problems with high-nitrogen atmosphere. Once out of the earth's atmosphere they dropped the pressure to 5 psi, but on the launch pad they pressurized the capsule to just above 1 atm.
  • frink 2011-05-16 13:17
    About 15 years ago (during college) I worked for National instruments as a tech support telephone jockey.

    The real WTF is not LabVIEW it's academics who think because they have spent ages learning about something really obscure which no one else knows (or cares) about, that means they are really smart and have the right to patronise everyone else.

    Also because they are so smart the problem must be with whatever they are using because it couldn't possibly be their fault because they're so smart.

    filed under: The O/S is broken.
  • Anon 2011-05-16 13:20
    On the subject on user interface, I give you National Instruments own User Interface Gallery. These are the examples that NI think are beautiful enough that they need special recognition.



    Hmmmm....Windows 95 style.
  • Calli Arcale 2011-05-16 13:33
    BentFranklin:
    In that Snopes article, they twice refer to 100% oxygen atmosphere. Really? 100%? That doesn't seem right. Anyone know this for sure?


    Yes, they really did use a 100% oxygen atmosphere! But not at 14 PSI (about 1 atm). Instead, it was at 5 PSI. That's the partial pressure of oxygen at sea level; you can do just fine without all the nitrogen that normally buffers it, and the fire hazard at 5PSI of oxygen is not really any worse than at 14PSI of air. It saves a hell of a lot of mass, though, and for Apollo, that was a very big deal. The idea was they'd start out at 14 PSI, so nobody'd get the bends or anything, and then bleed off cabin atmosphere until it was down to 5 PSI, which they'd stick with for the rest of the mission.

    Then Apollo 1 happened. On the ground, with only oxygen available to pressurize, they went up to *more* than sea level pressure in order to fully test all of the systems and simulate the pressure differential the capsule would experience in space against a vacuum. Basically, it was a hyperbaric oxygen chamber, and also a massive fire risk. After that, they changed so that when pressurizing to sea level on the ground, the oxygen was buffered with nitrogen, before dropping down to 5 PSI pure oxygen for the bulk of the mission.

    The Space Shuttle is, I believe, the first American spacecraft to have a nitrogen/oxygen atsmophere at 14 PSI for the entire mission, though they used to drop to 10 PSI during spacewalks, to make it easier for the spacewalkers to purge nitrogen from their blood. That's the other upshot of a 5PSI pure oxygen environment -- it makes EVA prep a lot easier, because your body has already gotten rid of all that nitrogen. (Suits are still at 5PSI pure oxygen -- any more pressure and you can't bend them.)
  • Boris Vladamir 2011-05-16 13:34
    undefined:
    Boris Vladamir:

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.


    1. You can not to use on-line automatic translation to produce correct russian sentences.

    2. There are no middle names in Russian, we use http://en.wikipedia.org/wiki/Patronymic#Russian

    Key attribute of Russia: it is big country. All is not Moscow Russian. Please try to get facts straight before posting attempting to spoil my good name.
  • Nagesh 2011-05-16 13:44
    Anon:
    On the subject on user interface, I give you National Instruments own User Interface Gallery. These are the examples that NI think are beautiful enough that they need special recognition.



    Hmmmm....Windows 95 style.

    Tihs is not bad. I am to be using latest release of Sun Java 1.3 next month. Swing is not be be suporting the non-aliasing of fonts. I am to very impressing with level of detail on these grafts. 3D wijets are not to be a turned-on for you?
  • BentFranklin 2011-05-16 13:44
    Calli Arcale:
    BentFranklin:
    Question?

    Facts.

    Neat, thanks!
  • Yair 2011-05-16 13:48
    Anon:

    5. GUIs look like shit. All those controls that are supposed to look like rocker switches, dials and LEDs just look awful and unprofessional.
    6. Is a proprietary language owned by National Instruments, meaning that it's very difficult to do anything with LabVIEW code without buying LabVIEW from NI. If NI disappear, all that LabVIEW code will be practically useless (especially since recent versions of LabVIEW require online activation).
    7. Is a nightmare to upgrade when NI crap out a new version and pretty much impossible to downgrade to an earlier version.


    My GUIs don't look like that. If you know what you're doing, you can create much better GUIs, but that is indeed one of the areas where LabVIEW needs considerable improvement.

    Yes, it's proprietary. If NI disappears (which currently seems unlikely based on their financial reports), the LabVIEW source code is in escrow and will go to another body. Existing LabVIEW versions will continue to work. That's no different that using visual studio and .NET.

    I'm sure upgrading from VB6 to VB.NET was very easy for you? Or from SQL Server 2000 to 2008? Some upgrades go smoothly, others do not. Mine were generally smooth - open the code, find new bugs (if any), build the application.


    As I said earlier, those were some advantages and disadvantages, not all.
  • boog 2011-05-16 13:49
    Nagesh:
    Itis "Bolta" and not "Boltey", dumbass. Get better kwality of Indian person to translete.
    Likewise.
  • Master and Commander of the Troll Amry 2011-05-16 13:50
    Calli Arcale:
    BentFranklin:
    In that Snopes article, they twice refer to 100% oxygen atmosphere. Really? 100%? That doesn't seem right. Anyone know this for sure?


    Yes, they really did use a 100% oxygen atmosphere! But not at 14 PSI (about 1 atm). Instead, it was at 5 PSI. That's the partial pressure of oxygen at sea level; you can do just fine without all the nitrogen that normally buffers it, and the fire hazard at 5PSI of oxygen is not really any worse than at 14PSI of air. It saves a hell of a lot of mass, though, and for Apollo, that was a very big deal. The idea was they'd start out at 14 PSI, so nobody'd get the bends or anything, and then bleed off cabin atmosphere until it was down to 5 PSI, which they'd stick with for the rest of the mission.

    Then Apollo 1 happened. On the ground, with only oxygen available to pressurize, they went up to *more* than sea level pressure in order to fully test all of the systems and simulate the pressure differential the capsule would experience in space against a vacuum. Basically, it was a hyperbaric oxygen chamber, and also a massive fire risk. After that, they changed so that when pressurizing to sea level on the ground, the oxygen was buffered with nitrogen, before dropping down to 5 PSI pure oxygen for the bulk of the mission.

    The Space Shuttle is, I believe, the first American spacecraft to have a nitrogen/oxygen atsmophere at 14 PSI for the entire mission, though they used to drop to 10 PSI during spacewalks, to make it easier for the spacewalkers to purge nitrogen from their blood. That's the other upshot of a 5PSI pure oxygen environment -- it makes EVA prep a lot easier, because your body has already gotten rid of all that nitrogen. (Suits are still at 5PSI pure oxygen -- any more pressure and you can't bend them.)

    YHBT. YHL. HAND.
  • boog 2011-05-16 13:51
    Nagesh:
    boog:
    Nagesh:

    I am Indian only.
    That's highly unlikely.

    Why you think that booger boy?
    Why not?
  • Yair 2011-05-16 13:51
    Anon:
    These are the examples that NI think are beautiful enough that they need special recognition.





    No, they aren't. That's a document listing some of the control types you can find in LabVIEW (the majority of which I personally don't like and don't use as-is).
  • Mildred Bonk 2011-05-16 13:52
    I used to program LabVIEW for a living. While I was stuck doing that I made this demotivator:


    It's possible to write structured code in LabVIEW, but the IDE makes it difficult. The simple act of defining a new function (in LabVIEW parlance, creating a VI) is kind of a pain in the ass, especially compared to every other programming language.
  • Kuba 2011-05-16 13:54
    Anon:
    Yair:

    Some of the disadvantages:

    1. Easy to get started with, so you get untrained users.
    2. Automatic memory management, so your options of controlling memory allocations are limited. Might be an issue under some circumstances.
    3. Writing parallel code is extremely easy. If you don't know what you're doing, you're going to have lots and lots of race conditions.
    4. Working with SCC is a big issue, although recent versions of LabVIEW have improved this somewhat. Basic work (check in, check out, commit, update) is not much of an issue, but diffing and merging are. Again, this is not necessarily an issue, depending on your needs.


    5. GUIs look like shit. All those controls that are supposed to look like rocker switches, dials and LEDs just look awful and unprofessional.
    6. Is a proprietary language owned by National Instruments, meaning that it's very difficult to do anything with LabVIEW code without buying LabVIEW from NI. If NI disappear, all that LabVIEW code will be practically useless (especially since recent versions of LabVIEW require online activation).
    7. Is a nightmare to upgrade when NI crap out a new version and pretty much impossible to downgrade to an earlier version.
    It's worse than that. The graphical notation used in LabView is patented to hell and back. Even if you wanted to do a clean-room reimplementation simply to provide a 2nd-vendor fallback for your investment in your own VIs, you couldn't. Good luck licensing anything from NI, haha.
  • Nagesh 2011-05-16 13:54
    Boris Vladamir:
    undefined:
    Boris Vladamir:

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.


    1. You can not to use on-line automatic translation to produce correct russian sentences.

    2. There are no middle names in Russian, we use http://en.wikipedia.org/wiki/Patronymic#Russian

    Key attribute of Russia: it is big country. All is not Moscow Russian. Please try to get facts straight before posting attempting to spoil my good name.


    VLADIMIR IS NOT SOUNDING LIKE REAL NAME.
  • Boris Vladamir 2011-05-16 14:07
    Nagesh:
    Boris Vladamir:
    undefined:
    Boris Vladamir:

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.


    1. You can not to use on-line automatic translation to produce correct russian sentences.

    2. There are no middle names in Russian, we use http://en.wikipedia.org/wiki/Patronymic#Russian

    Key attribute of Russia: it is big country. All is not Moscow Russian. Please try to get facts straight before posting attempting to spoil my good name.


    VLADIMIR IS NOT SOUNDING LIKE REAL NAME.

    So sorry we cannot all be from 3rd-world country made up of the offspring of Englishmen and primates.
  • Nagesh 2011-05-16 14:13
    Boris Vladamir:
    Nagesh:
    Boris Vladamir:
    undefined:
    Boris Vladamir:

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.


    1. You can not to use on-line automatic translation to produce correct russian sentences.

    2. There are no middle names in Russian, we use http://en.wikipedia.org/wiki/Patronymic#Russian

    Key attribute of Russia: it is big country. All is not Moscow Russian. Please try to get facts straight before posting attempting to spoil my good name.


    VLADIMIR IS NOT SOUNDING LIKE REAL NAME.

    So sorry we cannot all be from 3rd-world country made up of the offspring of Englishmen and primates.



    Russia pepole are children born of much raping from mongol warlords. So don't talk about ancestory to me, madarchod.
  • Charles 2011-05-16 14:21
    This. Absolutely this.
    I'm working with a Labview program that I inherited from my predecessor. The block diagram only has a few blocks and is fairly clean...
    ...until you notice that each block is a sub VI with over 35 blocks in each (and some of those are sub-VI's as well).
    All told, there's just shy of 400 sub-VI's, all nested within each other. A few of the sub-VI's are on a network drive that's physically across the nation, so the program even manages to create quasi race condition failures, which is really a difficult way to mess up.
    I'd almost prefer the spaghetti because it looks messy, so it's easier to argue for a chance to switch. *sigh*
  • Meep 2011-05-16 14:30
    Yair:
    Anon:
    These are the examples that NI think are beautiful enough that they need special recognition.





    No, they aren't. That's a document listing some of the control types you can find in LabVIEW (the majority of which I personally don't like and don't use as-is).


    NI called it a "gallery," the whole point of a gallery is to show what you can do.

    I would expect to find these on some l33t winamp sk1nz, the fact that NI has them at all is embarrassing.

    But hey, while you're defending the indefensible, it's time for the classic UI game, "are these switches on or off?"





    I thought LabView was useful for some tasks, but this is garbage. I mean, I'll listen to reasoned support, but don't put your balls in my mouth and tell me it's tea-time.
  • Nagesh 2011-05-16 14:35
    Meep:
    Yair:
    Anon:
    These are the examples that NI think are beautiful enough that they need special recognition.





    No, they aren't. That's a document listing some of the control types you can find in LabVIEW (the majority of which I personally don't like and don't use as-is).


    NI called it a "gallery," the whole point of a gallery is to show what you can do.

    I would expect to find these on some l33t winamp sk1nz, the fact that NI has them at all is embarrassing.

    But hey, while you're defending the indefensible, it's time for the classic UI game, "are these switches on or off?"





    I thought LabView was useful for some tasks, but this is garbage. I mean, I'll listen to reasoned support, but don't put your balls in my mouth and tell me it's tea-time.

    I am very to be impresed with quality of these first-grade ui elements. Can you plz send me the codes to integrate into UI elements?
  • Nagesh 2011-05-16 14:38
    Nagesh (fake):
    Meep:
    Yair:
    Anon:
    These are the examples that NI think are beautiful enough that they need special recognition.





    No, they aren't. That's a document listing some of the control types you can find in LabVIEW (the majority of which I personally don't like and don't use as-is).


    NI called it a "gallery," the whole point of a gallery is to show what you can do.

    I would expect to find these on some l33t winamp sk1nz, the fact that NI has them at all is embarrassing.

    But hey, while you're defending the indefensible, it's time for the classic UI game, "are these switches on or off?"





    I thought LabView was useful for some tasks, but this is garbage. I mean, I'll listen to reasoned support, but don't put your balls in my mouth and tell me it's tea-time.

    I am very to be impresed with quality of these first-grade ui elements. Can you plz send me the codes to integrate into UI elements?


    Stop making annoy me, madarchod!
  • Grant 2011-05-16 14:51
    Nagesh:
    Nagesh (fake):
    Meep:
    Yair:
    Anon:
    These are the examples that NI think are beautiful enough that they need special recognition.





    No, they aren't. That's a document listing some of the control types you can find in LabVIEW (the majority of which I personally don't like and don't use as-is).


    NI called it a "gallery," the whole point of a gallery is to show what you can do.

    I would expect to find these on some l33t winamp sk1nz, the fact that NI has them at all is embarrassing.

    But hey, while you're defending the indefensible, it's time for the classic UI game, "are these switches on or off?"





    I thought LabView was useful for some tasks, but this is garbage. I mean, I'll listen to reasoned support, but don't put your balls in my mouth and tell me it's tea-time.

    I am very to be impresed with quality of these first-grade ui elements. Can you plz send me the codes to integrate into UI elements?


    Stop making annoy me, madarchod!

    Madarchod this, madarchod that. Don't you know any other Hindi swear words?
  • Yair 2011-05-16 15:11
    Charles:
    ...until you notice that each block is a sub VI with over 35 blocks in each (and some of those are sub-VI's as well).
    All told, there's just shy of 400 sub-VI's, all nested within each other


    You do realize that splitting your code into small, manageable and cohesive chunks is generally considered a good thing, right? That small functions that do specific things are better than a single big function that does everything? That splitting things into classes can make your code safer and easier to read?

    From your basic description, it sounds like the app you're working on at least doesn't have the problem described in the original post.

    Personally, most of my apps have considerably more than 400 VIs. What's the problem with that?
  • Yair 2011-05-16 15:14
    Meep:
    ...But hey, while you're defending the indefensible...I'll listen to reasoned support, but don't put your balls in my mouth and tell me it's tea-time.



    Congratulations, you've pushed me past of the point of "this is as much time as I'm willing to spend on this today". You seem to not have noticed how I said that I don't like these controls either and how my LabVIEW GUIs don't usually look like this.
  • Captain Oblivious 2011-05-16 15:17
    frink:
    About 15 years ago (during college) I worked for National instruments as a tech support telephone jockey.

    The real WTF is not LabVIEW it's academics who think because they have spent ages learning about something really obscure which no one else knows (or cares) about, that means they are really smart and have the right to patronise everyone else.

    Also because they are so smart the problem must be with whatever they are using because it couldn't possibly be their fault because they're so smart.

    filed under: The O/S is broken.


    Sounds like every "developer" I have ever met.
  • Anon 2011-05-16 15:18
    [quote user="Yair"][quote user="Anon"]
    Yes, it's proprietary. If NI disappears (which currently seems unlikely based on their financial reports), the LabVIEW source code is in escrow and will go to another body. Existing LabVIEW versions will continue to work. That's no different that using visual studio and .NET.
    [/quote]

    Except I can open my .cs files in Notepad. Try that with your .vi documents. Even if Microsoft exploded tomorrow and every copy of Visual Studio disappeared from the face of the earth, I'd still be able to look at my source code and see what it did. Even if it was impossible to compile it again, I could still look at it and piece together the functionality.

    Also, I'm sure people working at Enron thought it was highly unlikely that they'd go out-of-business. Stuff happens, companies collapse, sometimes very suddenly.
  • HellKarnassus 2011-05-16 15:19
    Grant:
    Nagesh:
    Nagesh (fake):
    Meep:
    Yair:
    Anon:
    These are the examples that NI think are beautiful enough that they need special recognition.





    No, they aren't. That's a document listing some of the control types you can find in LabVIEW (the majority of which I personally don't like and don't use as-is).


    NI called it a "gallery," the whole point of a gallery is to show what you can do.

    I would expect to find these on some l33t winamp sk1nz, the fact that NI has them at all is embarrassing.

    But hey, while you're defending the indefensible, it's time for the classic UI game, "are these switches on or off?"





    I thought LabView was useful for some tasks, but this is garbage. I mean, I'll listen to reasoned support, but don't put your balls in my mouth and tell me it's tea-time.

    I am very to be impresed with quality of these first-grade ui elements. Can you plz send me the codes to integrate into UI elements?


    Stop making annoy me, madarchod!

    Madarchod this, madarchod that. Don't you know any other Hindi swear words?

    Nageshchod!
  • Nagesh 2011-05-16 15:26
    Anon:
    Yair:

    Yes, it's proprietary. If NI disappears (which currently seems unlikely based on their financial reports), the LabVIEW source code is in escrow and will go to another body. Existing LabVIEW versions will continue to work. That's no different that using visual studio and .NET.


    Except I can open my .cs files in Notepad. Try that with your .vi documents. Even if Microsoft exploded tomorrow and every copy of Visual Studio disappeared from the face of the earth, I'd still be able to look at my source code and see what it did. Even if it was impossible to compile it again, I could still look at it and piece together the functionality.

    Also, I'm sure people working at Enron thought it was highly unlikely that they'd go out-of-business. Stuff happens, companies collapse, sometimes very suddenly.

    That is probably worst argument against LabVIEW that you could make.

    Also, what is "appelatio"? GINMF :(
  • FatBigot 2011-05-16 15:35
    No-one has yet touched on the reason idiots like me buy NI stuff: Single, direct seller.

    If I start off with a simple data acquisition task, I know that the acquisition hardware, drivers and development environment all came from NI, so it's just one ass to kick if there's a problem. The sales rep can access the actual engineers to sort problems.

    This is very different to many re-sellers, who have 2000 Chinese made boards to sell, and cannot access any in-depth engineering expertise.

    If I need to add 422 coms, or vision acquisition, boards from NI play nice with each other and the drivers. I do not want to go back 20 years when adding a new board would require a compiler version incompatible with an existing board from a different vendor.

    I agree 100% about the horribleness of Labview though.
  • NutDriverLefty 2011-05-16 15:48
    BentFranklin:
    In that Snopes article, they twice refer to 100% oxygen atmosphere. Really? 100%? That doesn't seem right. Anyone know this for sure?


    It was in at least some of the early tests. That was reportedly one of the reasons for the Appollo 1 capsule fire.
  • Yair 2011-05-16 15:53
    Anon:

    Except I can open my .cs files in Notepad. Try that with your .vi documents. Even if Microsoft exploded tomorrow and every copy of Visual Studio disappeared from the face of the earth, I'd still be able to look at my source code and see what it did. Even if it was impossible to compile it again, I could still look at it and piece together the functionality.


    Congratulations, your reply was ridiculous enough for me to rise back past the point I previously passed.

    So, to counter: Even if NI exploded tomorrow and all backup copies of the LabVIEW source code were stolen and eaten by alien zombies and whoever holds the LabVIEW source code in escrow would turn out to be a Bond villain, my existing copies of LabVIEW would still allow me to look at my source code and see what it does. And I would even be able to compile it. So yay, I'm basically prepared for that unlikely scenario.
  • Anon 2011-05-16 16:42
    Yair:
    Anon:

    Except I can open my .cs files in Notepad. Try that with your .vi documents. Even if Microsoft exploded tomorrow and every copy of Visual Studio disappeared from the face of the earth, I'd still be able to look at my source code and see what it did. Even if it was impossible to compile it again, I could still look at it and piece together the functionality.


    Congratulations, your reply was ridiculous enough for me to rise back past the point I previously passed.

    So, to counter: Even if NI exploded tomorrow and all backup copies of the LabVIEW source code were stolen and eaten by alien zombies and whoever holds the LabVIEW source code in escrow would turn out to be a Bond villain, my existing copies of LabVIEW would still allow me to look at my source code and see what it does. And I would even be able to compile it. So yay, I'm basically prepared for that unlikely scenario.


    Until your HD crashes, and you find you can't reinstall LabVIEW because it requires online activation and the servers aren't running post-apocalypse.

    Of course it isn't likely, but why even take the risk? You can write your programs in BASIC, C, C++, C#, Java,...just about any other language, and none of them have this problem. You can pick almost any other language in the world and not have your source code, the single most important thing a programmer produces, held hostage.

    Man, it's alarming how much the LabVIEW fan boys are in denial about this.
  • Matt Westwood 2011-05-16 16:44
    Boris Vladamir:
    undefined:
    Boris Vladamir:

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.


    1. You can not to use on-line automatic translation to produce correct russian sentences.

    2. There are no middle names in Russian, we use http://en.wikipedia.org/wiki/Patronymic#Russian

    Key attribute of Russia: it is big country. All is not Moscow Russian. Please try to get facts straight before posting attempting to spoil my good name.


    If you were really Russian you'd spell it Vladimir, before or after transliteration.
  • Wonk 2011-05-16 16:48
    You are in a maze of twisty little macros, all alike
  • C-Octothorpe 2011-05-16 16:48
    FatBigot:
    ...stuff...


    Am I the only one at first sight read his name as BigFaggot?

    Sorry, I'm done adding absoutely nothing to this thread...
  • moz 2011-05-16 16:48
    Boris Vladamir:
    Nagesh:
    VLADIMIR IS NOT SOUNDING LIKE REAL NAME.

    So sorry we cannot all be from 3rd-world country made up of the offspring of Englishmen and primates.

    Why be sorry? It's just a fact of life that not everyone is able to share your Carnivore ancestry.
  • Boris Vladamir 2011-05-16 16:49
    Matt Westwood:
    Boris Vladamir:
    undefined:
    Boris Vladamir:

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.


    1. You can not to use on-line automatic translation to produce correct russian sentences.

    2. There are no middle names in Russian, we use http://en.wikipedia.org/wiki/Patronymic#Russian

    Key attribute of Russia: it is big country. All is not Moscow Russian. Please try to get facts straight before posting attempting to spoil my good name.


    If you were really Russian you'd spell it Vladimir, before or after transliteration.

    If you were really Hebrew, you would spell it "Levi".
  • Yair 2011-05-16 17:12
    Anon:

    Of course it isn't likely, but why even take the risk?


    Because the risk is so negligent it's irrelevant and I prefer programming in LabVIEW. I like it better. It works better for me and I'm not going to not use it because it's proprietary and there's some far-fetched option in which everything goes to pieces and yet I really, really, REALLY need my source code and can't get at it. If the situation is that bad, I assure you that access to my code would be the least of my issues. So, yes, I am in denial about that. It's a "problem" I have no problem having.

    A much more likely danger (although, like I said, even that seems quite unlikely currently) is that for some reason NI stops producing LabVIEW and locks down the activation servers, etc. and no one else picks it up. So I won't have any future versions and at some point it won't run on current platforms. I'm willing to take that risk, because to me it seems irrelevant. Can it happen? Yes. Is it likely? Not currently. If it will happen, the code will have to be rewritten at some point in the future, but that applies to almost any language. Code rarely stays alive for a very long time.

    Oh, and since all my LabVIEW installations are on virtual machines and are already activated and backed up, I don't need to reactivate them. So there, solved that theoretical hurdle as well. Man, it's alarming how far these anonymous anti-LabVIEW boys would go to find excuses to diss it.
  • boog 2011-05-16 17:14
    Anon:
    Yair:
    Anon:

    Except I can open my .cs files in Notepad. Try that with your .vi documents. Even if Microsoft exploded tomorrow and every copy of Visual Studio disappeared from the face of the earth...
    ...Even if NI exploded tomorrow and all backup copies of the LabVIEW source code were stolen and eaten by alien zombies and whoever holds the LabVIEW source code in escrow would turn out to be a Bond villain... I'm basically prepared for that unlikely scenario.

    Until your HD crashes, and you find you can't reinstall LabVIEW because it... blah blah bullshit blah... why even take the risk?
    Why are you even bothering with this nonsense? There are so many reasons that plain-text source code wins over non-text; why don't you argue one of those viewpoints instead of entertaining such wacko bullshit scenarios?
  • boog 2011-05-16 17:26
    Yair:
    Because the risk is so negligent it's irrelevant and I prefer programming in LabVIEW. I like it better.

    Thank you.

    Finally somebody is just admitting the real reason they choose a particular language/environment, and not rambling off a bunch of arbitrary, subjectively-chosen metrics in order to "prove" that their way of doing things is the best.

    It's so rare to see this kind of honesty among programmers.
  • Someone from here 2011-05-16 17:42
    I don't really see the problem. Visual tools can often make us realise how complex code actually is.

    Granted 'Hello World' wouldn't look this complex (no matter how badly it were implemented), but we should keep in mind that 'Hello World' doesn't actually do anything....

    This apparently comes from a test suite (or rather test equipment) and given some of the labels that include words like Yaw, Mach, Pitch I'm guessing it's something that could be related to aircraft (or maybe a wind tunnel). Perhaps I'm weird, but it doesn't surprise me that something like that might appear very complex. Assuming the WTF here is the complexity (which I assume from 'Spaghetti' being in the title), I really don't see why complexity is a WTF.

    Granted, 'Labview' may claim to simplify things (as do many systems that use pictures instead of words), but the reality is that pictures don't simplify everything for everyone, they merely provide an alternate representation for different minds. I'm guessing engineers (other than Software Engineers) and the like are more comfortable using pictures and diagrams because they use such things all the time. Software Engineers and Computer Scientists, on the other hand, are often comfortable looking at the pretty patterns that well-formatted code makes. Presumably this software does actually manage to automate the testing (as it claims), and although it may be tedious, automation often is....

    Summary: I'm no expert (in Labview, or anything else significant, for that matter) Apparent Complexity != WTF. Could someone please be explaining to me?
  • Albinoni 2011-05-16 17:45
    Asiago Chow:
    I'm not sure if this is why you should, or shouldn't, teach would-be software people some basic electrical engineering.

    On the one hand, if whoever wrote that interface hadn't been an EE, they wouldn't have used the schematic metaphor and the screenshot never would've bubbled up here.

    On the other...if the person freaked out by that image had learned to deal with schematics for even mildly complicated circuit boards, they would shrug off that image as nothing special and it never would've bubbled up here.

    Not judging the quality of the software depicted...I don't know what problems they were trying to solve and I've never used labview.


    "Alex" was the author...

    I'm just sayin'....
  • Goosey Goo 2011-05-16 17:49
    Zylon:
    Mike Caron:
    What does it do? Without context, it may be justifiable.

    (That said, +1 for literal spaghetti code)

    And a -1 to you for misusing the word "literally".


    I say, English, I'm no great scholar of the language, but I really don't understand how he's misused the word literally. Perhaps you could explain, old chap?

    dictionary.com:

    it·er·al
       /ˈlɪtərəl/ Show Spelled[lit-er-uhl] Show IPA
    –adjective
    1.
    in accordance with, involving, or being the primary or strict meaning of the word or words; not figurative or metaphorical: the literal meaning of a word.
    2.
    following the words of the original very closely and exactly: a literal translation of Goethe.
    3.
    true to fact; not exaggerated; actual or factual: a literal description of conditions.


  • A cat that ain't laughing 2011-05-16 17:51
    A Gould:
    Herbert:
    Great. So some people write ugly code in LabVIEW code. Can you find a language that a dedicated programmer *couldn't* write ugly code in with sufficient determination?


    Lolcode. Fairly sure anything written in that language is funny by definition.


    Fuck Off!
  • Johnny 2011-05-16 17:53
    Meep:
    Steve:
    Would some of the LabView evangelists please post screenshots of LabView programs that aren't incomprehensible? I've never seen one before. (That last one by Yair is about the best I've ever encountered).


    Not an evangelist, but I've used it and thought that, while it takes some work to understand, it's not bad.

    Any complex machine is going to take some work to comprehend. Ever tried reading a patent?


    But isn't that the point? Anything complex will needs some work to understand. Where is the WTF? Are Complex programs the WTF? I assumed everyone in this industry is (or has at some stage) worked on complex programs. Sometimes it's just not possible to do things simply.
  • Alessandrs 2011-05-16 17:59
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!


    They say necessity is the mother of invention. The Reds needed to do this on the cheap, so they come up with a cheap solution. At the time, the yankees had loads of money funding space exploration, so simple solutions were invisible to them - they didn't have the need to save money.

    Project managers, take note: Always claim to have about 25% of the budget you have - not only does that allow a massive buffer for overruns, it will also help your Techos to see the simpler cheaper solutions, rather than reinventing the wheel (or more commonly, a date/time class). The more money you have available, the more money a project costs. The more money a project costs, the more effort there probably is reinventing existing functionality simply because one of your monkeys "...never new the standard libraries could do that...". A techo spending even 1/2 a day googling how to do it with standard libraries is far cheaper, both in the long and the short terms than having them recreate flawed equivalents.
  • Alessandrs 2011-05-16 18:01
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Not sure the yankees ever actually got their pen working (despite a lot of effort). Getting rid of shavings is trivial, and the savings in not doing the research a massive benefit.

    Do you know how much the research and design for the zero-gravity pen cost? Oh, wait on yanks have never been responsible with money - that's why the GFC happened...
  • Alessandrs 2011-05-16 18:05
    Meep:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Clearly the idiot is someone who thinks they're going to have graphite dust floating around sensitive electronics.


    <sarcasm>
    Oh yeah, we saw loads of Russian rockets falling out of the sky because they used pencils...
    </sarcasm>

    Hard to say the decision to use pencils is stupid (for whatever reason), if it actually worked...
    Yanks just didn't want to look stupid taking crayons up...
  • da Doctah 2011-05-16 18:12
    Mildred Bonk:
    I used to program LabVIEW for a living. While I was stuck doing that I made this demotivator:


    One day, the pharoah called in his best scribe and told him to take a letter: "To the king of Sumeria, our esteemed greetings! We are most gratified by your generous gift of one hundred oxen, ten thousand bushels of grain, and fifty virile young slaves."

    The scribe interrupted. "Excuse me, exalted one, but is 'virile' spelled with one testicle or two?"
  • Someone from here 2011-05-16 18:17
    Yair:
    Steve:
    Would some of the LabView evangelists please post screenshots of LabView programs that aren't incomprehensible? I've never seen one before. (That last one by Yair is about the best I've ever encountered).



    Actually, both of those are really bad examples, because they're very dense and messy.

    Here's an example of one of the functions in the project I currently have opened. It doesn't have any comments, but I can tell you that every time you call it like this it adds a line to a log with timing info and error details (if there was an error) and optionally saves the log to a pipe delimited text file.




    Like other languages, LabVIEW has advantages and disadvantages. Some of the advantages include:

    1. Easy to get started with.
    2. Automatic memory management (and it had that for almost 25 years). No need to assign variables, etc.
    3. Writing parallel code is extremely easy and is almost unavoidable.
    4. The function shown above, for instance, has two return parameters and could have several more if I wanted it to.


    Some of the disadvantages:

    1. Easy to get started with, so you get untrained users.
    2. Automatic memory management, so your options of controlling memory allocations are limited. Might be an issue under some circumstances.
    3. Writing parallel code is extremely easy. If you don't know what you're doing, you're going to have lots and lots of race conditions.
    4. Working with SCC is a big issue, although recent versions of LabVIEW have improved this somewhat. Basic work (check in, check out, commit, update) is not much of an issue, but diffing and merging are. Again, this is not necessarily an issue, depending on your needs.


    See to me, that looks quite complex for logging debug and errors. This is probably because I'm more familiar with text-based programming, but the point is that graphical representation (and drag and drop programming) weren't really designed to be simpler than other programming, but were targeted at an audience that were more comfortable with diagrams that text (eg Electronic or Electrical Engineers).

    The merits (or lack there of) of Labview are much the same as any other programming language or tool. You get people who know what they're doing who use it extremely well. You get (more than you want) people who don't know what they're doing and add topo much complexity. You get (the majority, I suspect) who think they know what they're doing, and you get WTFs.

    Not knowing Labview, the example in the article to me isn't a WTF, because it appears to actually be working in a complex environment (although it may well fit into the 'think we know what we're doing' category). Despite what advocates of other languages might say, launching the Space Shuttle isn't actually as easy as:

    SpaceShuttle Endeavour = old SpaceShuttle();
    if(weather.isClear()&&!weather.isWindy())
    Endeavour.Launch();
  • Jimmy 2011-05-16 18:30
    tragomaskhalos:
    just me:
    tragomaskhalos:
    I am working on a project that uses a somewhat similar "visual programming" tool for a lot of its functionality. In my experience these things:
    a) look great in demos to non-technical types (hence sales);
    b) can be good for cobbling something together quickly;
    c) become completely and horribly unmanageable if you try to do anything even remotely complex.
    And since in any non-trivial system (c) will predominate ...

    c) only if you don't know what you're doing, or if the platform does not provide adequate tools for managing the complexity. LabVIEW does provide these tools (most importantly sub-VIs), so does MaxMSP (sub-patchers).

    The above applies just as well for any text-based languages, so what was your point again?


    In the case of the product we are using, it does not provide adequate tools, no - in LabVIEW, which I've not used, YMMD. For example on our project I have reimplemented a big wodge of it in Ruby - goodbye to unwieldy tangled and deeply nested diagrams, hello to succinct DSL-style notation with all the gubbins hidden away. This is the proper way to manage complexity, and is what a properly utilised text-based language will give you.

    Nor does point (a) apply to text-based languages - a big score for visual programming tools in the sales and marketing area is that they are pretty and colourful and allow for an easy sell of the seductive myth that non-programmers can use the thing, but what looks good in demos can quickly unravel in real use.


    Indeed!! Simplify complex tasks is important, to keep code manageable. Simplifying Programming is not important, as the people who program should be a (fairly) highly skilled subset of society. Making truck transmissions automatic is a convenience for a truck driver, but doesn't necessarily help Jo Schmo drive a vehicle of that size (although it might encourage him to try).

    We seem to have an obsession (we as people not just in IT), to try to simplify things to encourage 'anyone can do it', but the reality is we should leave most things for the people who have trained in those areas. Would you take your car to a mechanic who has never had formal training but has "...read lots of internet and knows simplest way to fix issue..." (Perhpas Nagesh's neighbor)? Would you be happy for someone to fix your computer because "...I managed to get mine set up fine, and it's all been made easy in the last few years"?
    Most people (I suspect) will have a resounding "no" for both of these examples, so why do we insist that we have to simplify programming so that my cousin's third aunt's cat can program? Programming almost anything useful is no trivial task - even the best programmers will often have subtle bugs in even reasonably simple code. No matter how accessible we make the actual language, the logic required can not trivially be taught...

    Sometimes, keeping things a little difficult (or at least having them appear difficult) is an advantage because people don't fiddle. In my experience, one of the biggest failings of the Windows '95 (and 98) releases, was oversimplification. Users who had little idea of what they were doing could 'explore' and find all sorts of (administration) settings to play with. A balance needs to be found to ensure that trivial tasks (for the Technician) are not unnecessarily complicated, but that they are sufficiently obscure to keep people from playing "because we can"
  • Jonesy 2011-05-16 18:33
    boog:
    Nagesh:
    boog:
    frits:
    At what point does this kind of stuff get offensive to actual Indians?
    Kind of a tree falling in the woods question, don't you think? If someone insults India and no actual Indians are around to hear it, are they offended?

    I am Indian only.
    That's highly unlikely.


    Leave him alone and he'll go away...He thrives on the attention.

    For the record, I reckon he is an Indian (though not necessarily in India) pretending that he is pretending to be an Indian.

    I haven't noticed the hours he's actually online, though, which could give some indication as to which part of Australia he's in
  • daqq 2011-05-16 18:37
    Noooo! LabView... the horror! It's all coming back to me!!! Noooo....(goes to cry in the corner...)
  • Jonesy 2011-05-16 18:40
    alegr:
    Boris Vladamir:

    Дизайн то, что является надежной, и мир будет просто производить лучше дурак.
    Somebody has too much trust to Google translator...


    +1

    Notice the punctuation in both this and Nagesh's posts....?

  • heebd 2011-05-16 18:44
    Yazeran:
    iToad:
    Unfortunately, most LabVIEW code is written by end users, not programmers. I just inherited a pile of literal spahegetti code from the original author to see if I could clean it up, and eliminate a bunch of race conditions and a mysterious latch-up problem.

    One of the first things that I did was create a concurrent state machine description of the logic, and a text-based specification of what all of the sub VIs did. The original developer was astonished. He didn't realize that you could actually design the software before writing it. I also introduced him to comments.

    Moral of the story: Inheriting a large, badly written VBA application is bad. Inheriting a large, badly written LabVIEW application is very bad.


    Amen!

    I have also heard a lot of people saying LabView is soo good: 'you can just take your instrument and within a few minutes get a graph of what it is measuring'. All well and good, but add some 20 different devices (of some 5 to 10 different types) and all of a sudden you end up with some spahgetti like the one shown.
    My beef is that you still can't get a screen big enough that you can properly debug any LabView program doing anything remotely interesting. Add to that some interesting race conditions and you are set for disaster....

    I would prefer a program written in C anytime over Labview, as in C at least you know exactly in which order things get executed, and in my experience, in 99% of the time you never need to do things asynchronous anyways. If your application/problem requires that, then it gets more complicated, but then Labview may not be your choice regardless....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer.


    And if you do need asyncronous stuff you can either spawn children, multithread or make multiple concurrent applications.

    As you say, in a Labe environment I would think you normally need to do things in a predetermined order...
  • Charles 2011-05-16 19:09
    It's not the use of sub-VI's that kills me. It's that they're unnecessarily nested within each other. Perhaps I wasn't clear...

    For example, using a VI as an equivalent of a function

    #1 VI <-> doThings(a,b,c)
    ...
    #400 VI <-> doDifferentThings(d,e)

    That's fine. I'm okay with this. This is reasonably close to good LabView code.

    The issue is that they managed to create inter-dependencies in each spiraling hole of sub-VI's that is 400 VI's deep and manages to require data that may or may not be available yet.
    So...(oh god)...

    Start -> Main VI -> Stop

    Where the Main VI contains some code and 1 sub VI (let's call it VI 1). VI 1 contains some different code and another sub VI (VI 2)...

    MainVI(VI1(VI2(VI3(VI4(VI5(VI6(VI7(VI8(VI9VI10(...VI399(some code goes here)...))))))))))

    So rather than use sub-VI's for anything useful, the previous guy used them as buckets to throw his mess into. It's like a 400-deep nested if statement in C, is you weren't allowed to write any documentation and had to do it all in crayon.

    So I may have been unclear about that. It wasn't 400 functions, it was 35 unique, approximately 400-deep sub-VI clusters. Sadness.
  • Dirge 2011-05-16 19:18
    Wow! It's Rocky's Boots for grown-ups! Is there a boot object in Labview?

  • Not Nagesh or Vladamir 2011-05-16 19:30
    Yair:
    Anon:

    Of course it isn't likely, but why even take the risk?


    <cut this and that so that we lose all sight ogf context>
    .... but that applies to almost any language. Code rarely stays alive for a very long time.
    ....
    <snipped some things here too>


    WOW!! You must be fresh out of uni/college. Did you know, the world is not full of applications written in C# and Java? Nor Python, Ruby, Haskell, PHP, perl etc....

    COBOL is still rife (even without CoolGen and the like) and I'm guessing there's still development done in Pascal, Fortran, Ada, LISP (almost Certainly)...

    Yup. Code sure as hell don't stay alive for long....
  • Pervert 2011-05-16 19:40
    Touched by his noodly appendage.
  • Davo 2011-05-16 20:02
    The Labview code is very poorly written. Poor use of sub Vi's. Poor layout. Whoever wrote this code does not understand the importance of communicating the functionality to the poor bunny who has to inherit the code one day. I could write an essay on the problems in the Labview code example. It could be rewritten by someone competent so that it is easily understood and maintainable. Like with C or assembly language, there is nothing more demoralizing than inheriting someone else's substandard code.
  • TeaDrinker 2011-05-16 20:10
    I spent a few months doing work with LabView for an aircraft simulator (the user controls, and a hydraulic feedback system). If you have a large monitor and a fast CPU it's a lot of fun to work with.

    Debugging the program is fairly interesting too, as you get a visual indication of where the point of execution is as it goes.
  • alegr 2011-05-16 20:40
    Nagesh:

    VLADIMIR IS NOT SOUNDING LIKE REAL NAME.

    VLAD_I_MIR is a real russian name.
    VLAD_A_MIR is NOT.
  • Earp 2011-05-16 22:35
    They have had mechanical (extending lead) pencils since 1822.
    Your comment has more Russian than American in it.
  • reductio ad ridiculum 2011-05-16 22:56
    JakeyC:
    I'd like to think that after all that, the output is just "Hello World".
    +1
  • reductio ad ridiculum 2011-05-16 22:58
    Damn, did school let out early for summer?
  • Horse 2011-05-17 00:29
    And a -1 for you for pointing out flaws in the original, correct, grammar.
  • ref 2011-05-17 02:26
    I don't really see what the wtf is here, it's a circuit diagram... so what. If it seems to complex for you to understand, it probably is, so go back to your OOP rubbish and stay away from electron beams and multipliers.
  • J.D. 2011-05-17 02:50
    Anonymous:
    I'm not really seeing the WTF here, any sufficiently complex LabView system ends up looking like that. Unless the WTF is LabView itself, in which case I wholeheartedly agree.

    Not necessarily. If designed with readability in mind, you can make the "code" with Labview look like something readable an useful. It does take some time, though.
  • Yair 2011-05-17 03:17
    boog:

    Finally somebody is just admitting the real reason they choose a particular language/environment, and not rambling off a bunch of arbitrary, subjectively-chosen metrics in order to "prove" that their way of doing things is the best.


    Definitely. That's the main reason for me. I don't work in a lab. I don't usually build test equipment. I often write programs which are completely outside the realm of "natural" LabVIEW programs (which is meaningless, since it is a general purpose language, although I'll readily agree it's limited in many ways and completely unsuitable for some types of applications).

    I use it because I like it and it works for me (I'm not even talking about actual technical advantages it has), and I can perfectly understand someone who doesn't like it because they don't get it (it happens a lot, as it's a completely different programming paradigm and it probably uses different parts of your brain).

    I can also understand people who don't use it because of specific valid reasons (It costs too much, I'm building the next Call of Duty or Angry Birds and it won't work for that, I'm working with a large team and couldn't get it to work, the IDE crashes too much for my taste, I can't find good programmers, etc.). I work with it on a daily basis and am well aware of its shortcomings.


    But the majority of the people I see online who complain about like most of those who did here seem to simply be people who used it for a very short time, didn't get it at all and found some excuse for why it's terrible.


    And for those who actually care, it also offers interesting insights into language design and a programming paradigm completely different from most text based languages. If you want, you can actually download a fully functional time-limited evaluation version from NI's site (at least for Windows), but if I were you I'd install it on a VM, because it also comes with a lot of extra services and stuff you don't want.
  • Antman 2011-05-17 03:32
    Goosey Goo:
    Zylon:
    Mike Caron:
    What does it do? Without context, it may be justifiable.

    (That said, +1 for literal spaghetti code)

    And a -1 to you for misusing the word "literally".


    I say, English, I'm no great scholar of the language, but I really don't understand how he's misused the word literally. Perhaps you could explain, old chap?

    dictionary.com:

    it·er·al
       /ˈlɪtərəl/ Show Spelled[lit-er-uhl] Show IPA
    –adjective
    1.
    in accordance with, involving, or being the primary or strict meaning of the word or words; not figurative or metaphorical: the literal meaning of a word.
    2.
    following the words of the original very closely and exactly: a literal translation of Goethe.
    3.
    true to fact; not exaggerated; actual or factual: a literal description of conditions.




    From what I can tell, the code itself is -not- made of spaghetti. I may be wrong, though, and LabView may save its code using spaghetti noodles. The code may MAKE spaghetti, which would be awesome.
  • Yair 2011-05-17 03:46
    Someone from here:



    See to me, that looks quite complex for logging debug and errors. This is probably because I'm more familiar with text-based programming...


    Probably, and be aware that this code also holds an internal buffer with the log data. I'm fairly sure you couldn't get equivalent code to be much simpler in most text-based languages in terms of the amount code it takes.



    ...but the point is that graphical representation (and drag and drop programming) weren't really designed to be simpler than other programming, but were targeted at an audience that were more comfortable with diagrams that text (eg Electronic or Electrical Engineers).


    Actually, it was designed to be simpler in a number of very important ways (such as being more intuitive and dealing with all the icky stuff of programming such as memory allocations on its own), and it was targeted at scientists and lab users originally, but you are correct that it only works well for people who can read it more easily than text.



    The merits (or lack there of) of Labview are much the same as any other programming language or tool. You get people who know what they're doing who use it extremely well. You get (more than you want) people who don't know what they're doing and add topo much complexity. You get (the majority, I suspect) who think they know what they're doing, and you get WTFs.

    Not knowing Labview, the example in the article to me isn't a WTF, because it appears to actually be working in a complex environment (although it may well fit into the 'think we know what we're doing' category).


    All that you're saying is completely true, but the code in the original submission is still bad code. It probably works, which is an important point in its favor, but it puts everything in one big function instead of splitting it up into logical units and it is impossibly messy. It has no comments and things are overlapping, etc. It's bad.

    But, I can't say that this surprises me. A lot of people write bad code in LabVIEW. In a way, the IDE encourages it, because it allows you to more easily write code which actually works, thus not requiring training, etc.
  • Yair 2011-05-17 03:58
    Not Nagesh or Vladamir:

    WOW!! You must be fresh out of uni/college. Did you know, the world is not full of applications written in C# and Java? Nor Python, Ruby, Haskell, PHP, perl etc....

    COBOL is still rife (even without CoolGen and the like) and I'm guessing there's still development done in Pascal, Fortran, Ada, LISP (almost Certainly)...

    Yup. Code sure as hell don't stay alive for long....


    I didn't say code doesn't stay alive for long. I said RARELY. I'm fairly sure that the vast majority of Fortran and COBOL programs ever written are no longer in use.

    But you're basically making the same point I was - even if a language becomes extinct, you can still develop in it, for a while, anyway.

    And since you insist on irrelevant points, the last time I was in any kind of school was 12 years ago.
  • LISP Programmer 2011-05-17 04:33
    Wonk:
    You are in a maze of twisty little macros, all alike


    Exits are North, South and Dennis.
  • Ian C. 2011-05-17 04:54
    Hey, at least he took the screen shot during lunch time.
  • Don 2011-05-17 05:21
    Meep:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Clearly the idiot is someone who thinks they're going to have graphite dust floating around sensitive electronics.

    Erm.. first clutch (refillable) pencil was designed in the 1800's. If they weren't so advanced as to use clutch/propelling pencils, then they could have used normal pencils with an enclosed sharpener (also circa 1800's).
    Pencil shavings need not be an issue.
  • foo 2011-05-17 08:06
    Hoffmann:
    Lollipops? I found walter (twice)!

    That's all you can do?

    I found Bin Laden!
  • Nagesh 2011-05-17 08:25
    Don:
    Meep:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Clearly the idiot is someone who thinks they're going to have graphite dust floating around sensitive electronics.

    Erm.. first clutch (refillable) pencil was designed in the 1800's. If they weren't so advanced as to use clutch/propelling pencils, then they could have used normal pencils with an enclosed sharpener (also circa 1800's).
    Pencil shavings need not be an issue.

    Link, or not did hapen.
  • QJ 2011-05-17 08:32
    Yair:
    Not Nagesh or Vladamir:

    WOW!! You must be fresh out of uni/college. Did you know, the world is not full of applications written in C# and Java? Nor Python, Ruby, Haskell, PHP, perl etc....

    COBOL is still rife (even without CoolGen and the like) and I'm guessing there's still development done in Pascal, Fortran, Ada, LISP (almost Certainly)...

    Yup. Code sure as hell don't stay alive for long....


    I didn't say code doesn't stay alive for long. I said RARELY. I'm fairly sure that the vast majority of Fortran and COBOL programs ever written are no longer in use.

    But you're basically making the same point I was - even if a language becomes extinct, you can still develop in it, for a while, anyway.

    And since you insist on irrelevant points, the last time I was in any kind of school was 12 years ago.


    Possibly worth pointing out that if an application is of high quality (e.g. does what it's supposed to, designed so as to be versatile enough to handle a considerable range of changing requirements, runs quickly and efficiently) there will often be considerable resistance to it being replaced by something more modern. Frequently, the main reason for such a program being replaced is that the hardware it runs on is obsolete. If you encounter a program that's over a decade old, treat it with extreme respect because it probably (but not inevitably) means it's pretty damn good.
  • HellKarnassus 2011-05-17 08:39
    foo:
    Hoffmann:
    Lollipops? I found walter (twice)!

    That's all you can do?

    I found Bin Laden!

    I found the G-spot!

    (showing my maturity)
  • Current 2011-05-17 08:47
    I develop Labview programs for test equipment setups.

    The commenters who are critical of Labview are mostly right.

    Labview certainly has it's advantages, putting together simple GUIs in it is very quick, quicker than the IDEs and widget layout editors for other languages.

    It has many disadvantages though, especially for large programs. To begin with sequence of execution isn't defined by default, it has to be defined using data flow or sequence structures. In most circumstances this isn't what you want and it creates race conditions.

    Instead of subroutines there are "SubVIs" which are similar. A bunch of wires are wired into a SubVI and when all the input are ready it runs. The problem with this is that it tends to highlight irrelevant details. Suppose you're writing a program that calls a function to command a piece of test equipment. You need to put in information to specify the bus the the test boxes is on and the address on that bus. In a normal language that could just be a couple of variables that are used as arguments in a function call. But, in Labview parameters like this have to be wires and those wires clutter up the diagram. (The "bundles" feature can help with this a bit, but not much).

    Using SubVIs is also difficult. By default each SubVI is a new file, and it's name is global to a Labview session. That means that if I write a SubVI called "Foo" and there's another different SubVI called "Foo" that another Labview program uses then if both programs are loaded into the same session then one of them won't work or will have bugs. This means that the sequence in which programs are loaded into a Labview session can be significant. This can be avoided by using libraries which have their own namespaces, but changing sets of SubVIs to libraries is time-consuming and inflexible. A better solution is to go through all the SubVIs in the entire tree of programs you use and make sure there are no name duplicates.
  • fru 2011-05-17 08:52
    Just press CTRL+U.
    That should solve everything ... or crash Labview. So win/win.
  • Yair 2011-05-17 09:49
    Current:
    I develop Labview programs for test equipment setups.


    Finally, someone who's critical of LabVIEW and provides actual arguments.



    The commenters who are critical of Labview are mostly right.


    Uh, no they're not. At least not the ones who participated here and gave BS criticisms.



    It has many disadvantages though, especially for large programs.


    Correct, but it's nothing that's not manageable if you know what you're doing. My programs are large (ish, because how do you define large? Let's just say that they're not just displaying data on a graph) and they turn out just fine.


    To begin with sequence of execution isn't defined by default, it has to be defined using data flow or sequence structures. In most circumstances this isn't what you want and it creates race conditions.


    Again, you have to know what you're doing. Write it correctly and it will work correctly. Generally, in good code the elements of code which execute in parallel are either designed to run in parallel (such as completely separate processes) or are two unrelated pieces of code where the order of execution doesn't matter. If you have race conditions then YOU wrote buggy code. You can't blame the system because you don't understand its rules.



    But, in Labview parameters like this have to be wires and those wires clutter up the diagram. (The "bundles" feature can help with this a bit, but not much).


    That's like saying that the characters in your text editor are cluttering up the whitespace on your screen. The wires are an inherent part of the system. Write it in a clean fashion and your diagram will not be cluttered. That's not always easy, and it doesn't always work out, but it certainly is possible.


    By default each SubVI is a new file, and it's name is global to a Labview session.


    No, it isn't. It's global to an "application instance". Use a project and you won't have these problems. Of course, there are also technical and historic reasons for this design, some of which offer advantages to this design. And the IDE warns you if you have conflicts. If you ignore those warnings, then you can't be surprised that you have problems.


    But, like I said, at least you actually used it and you know what you're talking about much more than the others who have posted here.



    Again, this is the same with every language and every IDE - it has advantages and disadvantages. It has things it's good at and things it's not good at. And it requires you to know what you're doing if you expect to produce good code.
  • Nagesh 2011-05-17 09:59
    tl;dr
  • Danny 2011-05-17 10:08
    "I say, English, I'm no great scholar of the language, but I really don't understand how he's misused the word literally. Perhaps you could explain, old chap? "

    They believe 'spaghetti code' to be a figurative term as the code is not actually spaghetti. However the term has become a figure of speech in and of itself (not 'code that is spaghetti' but precisely 'spaghetti code') ergo blurring the line between a literal and figurative statement. It is literally the figure of speech but not literally code that is spaghetti (the meaning of the figure of speech). IMO the use is perfectly valid; however others might not agree.
  • anonymous_coder() 2011-05-17 10:08
    Richard:
    Thankfully you can interface to most of the NI devices from C, and you don't need labview at all.

    Incidentally, I have the interesting problem of an NI4462 card which was sold to me a few months ago as being "supported on Linux". This support uses a nasty binary blob kernel driver that is only available for distros about 4 years old (eg Mandrake 2008). Not impressed


    Ran into that with their USB drivers too - only 32-bit, no more than 4 GB of RAM, but at least we could use RHEL 5. But it was an utter pain to deal with. I was trying to write a shim between the NI data acquisition and some Matlab code. Let me tell you how much fun it is to try and run Labview and Matlab on the same machine with less than 4 GB of RAM...
  • Win Su 2011-05-17 10:19
    To letting you guys know...before he leave Japan, Win Su and Alex go out for night of heavy drinking. Win Su have massive headache and didn't see Alex stopping from whiskey. Maybe tomorrow, you guys, ok, bye.
  • The Gang of Four 2011-05-17 10:24
    "...the pretty patterns that well-formatted code makes."

    yeah cos that's we we were talking about
  • Current 2011-05-17 10:28

    Again, you have to know what you're doing. Write it correctly and it will work correctly. Generally, in good code the elements of code which execute in parallel are either designed to run in parallel (such as completely separate processes) or are two unrelated pieces of code where the order of execution doesn't matter. If you have race conditions then YOU wrote buggy code. You can't blame the system because you don't understand its rules.


    I agree. My point is though that in Labview the default is parallel execution based on dataflow. In my opinion for most problems that Labview is targeted at that's the wrong default. In languages like C and Java the default is sequential execution and the programmer must very explicitly request parallel behaviour. In Labview it's the other way around, sequential behaviour must be explicitly requested. But, parallel execution is only really useful if there are slow blocks of code that can be executed in parallel. I write Labview programs that drive test equipment (which is the normal use of Labview) I've never found an instance of where this parallelism can save execution time. In all of my programs the test equipment or devices under test are what determines performance.


    That's like saying that the characters in your text editor are cluttering up the whitespace on your screen. The wires are an inherent part of the system. Write it in a clean fashion and your diagram will not be cluttered. That's not always easy, and it doesn't always work out, but it certainly is possible.


    The wires are an intrinsic part of the program, but in many cases they are superficial detail. In text based languages the same problem occurs in some cases where Labview avoids it. For example, in C it's necessary to allocate memory and deallocate it. Code for doing this must exist alongside the code for working on data-structures. In Labview this isn't needed, the detail of memory allocation is dealt with by the runtime which makes programming easier.

    But, the issue of extraneous detail does occur in other circumstances. Suppose I have a C program that programs a test instrument with the variable Foo reads the variable Bar from it in a loop. In that C program I can have a function to operate the test box, say "TestX (Addr, Param1, Param2, Foo, Bar)". In this case "Addr", "Param1" & "Param2" are parameters setup by the user. In the C program these parameters are kept in the background, they are detail. They occur once where they're set and again where they're read in the call to "TestX", they don't affect the intervening program. In Labview though they do affect the rest of the program because the wires needed to carry the values from place to place must be laid out. Of course local variables and clusters/bundles can be used here, but I'd argue they don't really remove the problem.

    I agree that with care Labview programs can be laid out in a readable way. I've done that with ~70% of those VIs I've inherited from my predecessors and I have the remaining 30% left to do. But, this layout takes a lot of time (and the automated clean up doesn't really do the job).

    I didn't know about the "application instance" thing, thanks for telling me, I'll check it out.
  • boog 2011-05-17 10:47
    Danny:
    "I say, English, I'm no great scholar of the language, but I really don't understand how he's misused the word literally. Perhaps you could explain, old chap? "

    They believe 'spaghetti code' to be a figurative term as the code is not actually spaghetti. However the term has become a figure of speech in and of itself (not 'code that is spaghetti' but precisely 'spaghetti code') ergo blurring the line between a literal and figurative statement. It is literally the figure of speech but not literally code that is spaghetti (the meaning of the figure of speech). IMO the use is perfectly valid; however others might not agree.
    *raises hand*
    I disagree; if I had code made out of actual spaghetti, what word would I use to describe it? Aside from "delicious"?

    It's important that "figuratively" and "literally" retain separate (and opposite) meanings. "Literally" doesn't reinforce a figure of speech; if it did, figures of speech would take over the language, since we'd never be able to make a distinction.

    For example: If you've been walking all day and you say your feet are on fire, it is a figure of speech. But if you say your feet are literally on fire, it's no longer a figure of speech and you should seek a fire extinguisher and a doctor.
  • Yair 2011-05-17 10:58
    Current:

    I agree. My point is though that in Labview the default is parallel execution based on dataflow. In my opinion for most problems that Labview is targeted at that's the wrong default.


    I wouldn't call it "default". It's an intrinsic part of the data flow paradigm, so it's not there just to increase performance (although there are cases where it can) and you can't actually disable it. Like you (and most other users, I suspect), the majority of my code is sequential, and while writing long sequential code in LabVIEW isn't as easy or as elegant as it can be in text, I don't think it's difficult once you get the hang of it.


    In Labview though they do affect the rest of the program because the wires needed to carry the values from place to place must be laid out. Of course local variables and clusters/bundles can be used here, but I'd argue they don't really remove the problem.


    That's a perfectly valid point and you're right. There is no safe and easy way in LabVIEW to carry many unrelated pieces of data from one point in the code to another which are not a wire. Local and global variables are easy but not safe. Other methods, such as queues, are safe but not easy.

    That said, it should be noted that this only affects certain kinds of diagrams and there are ways of working around it (for instance, if your code is a state machine made up of a loop and a case structure, you can add a shift register which will hold a cluster of state data for the state machine. Then, writing and reading data into that cluster is relatively clean and easy).

    Also, if you use classes, a lot of the code which has the problem you describe goes away, because the object keeps the value internally.
  • coz 2011-05-17 11:13
    Now I know Why Intel f*cked up Sandy Bridge...they tested it with that !!!
  • QJ 2011-05-17 11:14
    boog:
    Danny:
    "I say, English, I'm no great scholar of the language, but I really don't understand how he's misused the word literally. Perhaps you could explain, old chap? "

    They believe 'spaghetti code' to be a figurative term as the code is not actually spaghetti. However the term has become a figure of speech in and of itself (not 'code that is spaghetti' but precisely 'spaghetti code') ergo blurring the line between a literal and figurative statement. It is literally the figure of speech but not literally code that is spaghetti (the meaning of the figure of speech). IMO the use is perfectly valid; however others might not agree.
    *raises hand*
    I disagree; if I had code made out of actual spaghetti, what word would I use to describe it? Aside from "delicious"?

    It's important that "figuratively" and "literally" retain separate (and opposite) meanings. "Literally" doesn't reinforce a figure of speech; if it did, figures of speech would take over the language, since we'd never be able to make a distinction.

    For example: If you've been walking all day and you say your feet are on fire, it is a figure of speech. But if you say your feet are literally on fire, it's no longer a figure of speech and you should seek a fire extinguisher and a doctor.


    LOL. In fact, I literally laughed my head off. Good job I can touch-type. I've set one of my staff the task of finding out which corner it must have rolled into (all I can see from the angle my eyes ended up are two walls and a bit of carpet).
  • Nagesh 2011-05-17 11:28
    QJ:
    boog:
    Danny:
    "I say, English, I'm no great scholar of the language, but I really don't understand how he's misused the word literally. Perhaps you could explain, old chap? "

    They believe 'spaghetti code' to be a figurative term as the code is not actually spaghetti. However the term has become a figure of speech in and of itself (not 'code that is spaghetti' but precisely 'spaghetti code') ergo blurring the line between a literal and figurative statement. It is literally the figure of speech but not literally code that is spaghetti (the meaning of the figure of speech). IMO the use is perfectly valid; however others might not agree.
    *raises hand*
    I disagree; if I had code made out of actual spaghetti, what word would I use to describe it? Aside from "delicious"?

    It's important that "figuratively" and "literally" retain separate (and opposite) meanings. "Literally" doesn't reinforce a figure of speech; if it did, figures of speech would take over the language, since we'd never be able to make a distinction.

    For example: If you've been walking all day and you say your feet are on fire, it is a figure of speech. But if you say your feet are literally on fire, it's no longer a figure of speech and you should seek a fire extinguisher and a doctor.


    LOL. In fact, I literally laughed my head off. Good job I can touch-type. I've set one of my staff the task of finding out which corner it must have rolled into (all I can see from the angle my eyes ended up are two walls and a bit of carpet).

    Before you atempt humour, it is helpful to be having some first.
  • wingcommander 2011-05-17 11:46
    Lots of this misses the point, or what I think the point is, anyway.

    Labview rules when it is NOT economically sensible to write a custom program in C, or whatever. Sometimes this is the experimenter in the lab (this is where Labview got its start). You can write stuff that automates an experiment, and change it tomorrow, or incorporate it in a more extensive project, all by yourself. And there is really excellent interface to instruments, boards, cameras, etc. which does not require inquiring into the details of the insides.

    The graphical interface IS a substantial advantage in this context. Text-based interfaces require that you keep lots of commands, syntax, etc. in your head- and you can only do that with something you use every day. (re Norman, the design of everyday things). The graphical interfaces give the user clues, so he doesn't need to remember everything.

    Not that Labview doesn't have flaws- but it's a tool, and like any tool it's not good for everything.

  • Boris Vladamir 2011-05-17 11:52
    How does one refer to parts of the diagram? There are no line numbers. Are there other types of reference points, or does one have to use Cartesian Coordinate System?
  • boog 2011-05-17 11:55
    QJ:
    LOL. In fact, I literally laughed my head off. Good job I can touch-type. I've set one of my staff the task of finding out which corner it must have rolled into (all I can see from the angle my eyes ended up are two walls and a bit of carpet).

    That's easy: call out to your staff. They'll hear your head and find it quickly.

    Then again, if your head is in a corner somewhere, you probably aren't reading this anyway.
  • Vlad Poutines 2011-05-17 11:58
    Boris Vladamir:
    How does one refer to parts of the diagram? There are no line numbers. Are there other types of reference points, or does one have to use Cartesian Coordinate System?

    It's more of a "mouse mandatory" type of development environment. Just point and click. So easy, Granny can do it!
  • Anon 2011-05-17 12:13
    LabVIEW is the only programming language that requires a steady hand and keen eyesight. Just clicking on the points that you need to hook up a wire to can be an exercise in frustration.
    Somebody else made a point about a large monitor. It's not just nice to have, it's practically a requirement for LabVIEW.
  • Yair 2011-05-17 12:13
    Boris Vladamir:
    How does one refer to parts of the diagram? There are no line numbers. Are there other types of reference points, or does one have to use Cartesian Coordinate System?


    While LabVIEW does actually have have Cartesian coords describing where everything goes on the diagram, I've never seen anyone use it to refer to the code. It's there because LabVIEW itself needs it to maintain the layout.

    When talking to other people about the code, you would generally either have subVIs (which have names you can use) or you use free labels which you position where you want or fixed labels which are attached to the objects in the diagram. I can't say I have a problem with this when talking about the code, but inline documentation is an area which could be improved, since it's not always immediately clear which piece of code the comment is referring to.
  • Neil 2011-05-17 12:36

    One of the big problems I have with LV is that code flow is hidden in the GUI.

    For instance "if-then-else" statements are defined as a window.

    Only the code for one of the conditions is displayed to the user at one time (You have flip back-and-forth between each state to see the corresponding code).

    This makes it hard to see the flow of the code in order to comprehend it.


  • wingcommander 2011-05-17 12:44
    > How does one refer to parts of the diagram?

    Have never needed this. And only rarely are text labels needed.

    > It's not just nice to have, it's practically a requirement for LabVIEW.

    With appropriate hierarchical design (sub-vis in Labview talk) diagrams are never very big. In fact, not fitting on one screen is a good sign you are not doing it right.

    >LabVIEW is the only programming language that requires a steady hand and keen eyesight.

    Hmm..now that I think about it...most programmers DO have thick glasses and poor coordination.
  • Nagesh 2011-05-17 12:51
    Harold III, Sr.:
    Nagesh:
    Meep:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Clearly the idiot is someone who thinks they're going to have graphite dust floating around sensitive electronics.

    If well-designed being electronics, they are not to be suffering with dust, graphite or otherwise. Outside condo window every day I see Internet Cafe witnessing smokers ash falling all over laptops. Have never seen these Windows 98 machines being replaced.

    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?


    One Nagesh is un registered. There are many Nagesh but only one true Nagesh.
  • ted 2011-05-17 13:05
    Yazeran:
    iToad:
    Unfortunately, most LabVIEW code is written by end users, not programmers. I just inherited a pile of literal spahegetti code from the original author to see if I could clean it up, and eliminate a bunch of race conditions and a mysterious latch-up problem.

    One of the first things that I did was create a concurrent state machine description of the logic, and a text-based specification of what all of the sub VIs did. The original developer was astonished. He didn't realize that you could actually design the software before writing it. I also introduced him to comments.

    Moral of the story: Inheriting a large, badly written VBA application is bad. Inheriting a large, badly written LabVIEW application is very bad.


    Amen!

    I have also heard a lot of people saying LabView is soo good: 'you can just take your instrument and within a few minutes get a graph of what it is measuring'. All well and good, but add some 20 different devices (of some 5 to 10 different types) and all of a sudden you end up with some spahgetti like the one shown.
    My beef is that you still can't get a screen big enough that you can properly debug any LabView program doing anything remotely interesting. Add to that some interesting race conditions and you are set for disaster....

    I would prefer a program written in C anytime over Labview, as in C at least you know exactly in which order things get executed, and in my experience, in 99% of the time you never need to do things asynchronous anyways. If your application/problem requires that, then it gets more complicated, but then Labview may not be your choice regardless....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer.


    99% of good software executes asynchronously and works perfectly fine. What do you write that isn't multi-threaded and works best that way? It must be so simple that a LabView diagram would be fine for representing it.
  • ted 2011-05-17 13:26
    Goosey Goo:
    Zylon:
    Mike Caron:
    What does it do? Without context, it may be justifiable.

    (That said, +1 for literal spaghetti code)

    And a -1 to you for misusing the word "literally".


    I say, English, I'm no great scholar of the language, but I really don't understand how he's misused the word literally. Perhaps you could explain, old chap?

    dictionary.com:

    it·er·al
       /ˈlɪtərəl/ Show Spelled[lit-er-uhl] Show IPA
    –adjective
    1.
    in accordance with, involving, or being the primary or strict meaning of the word or words; not figurative or metaphorical: the literal meaning of a word.
    2.
    following the words of the original very closely and exactly: a literal translation of Goethe.
    3.
    true to fact; not exaggerated; actual or factual: a literal description of conditions.




    Well, to answer your question you must simply read and understand the definition you posted. To put it another way, the use of "literally" in the example implies that the code is made of actual spaghetti noodles.
  • Coyne 2011-05-17 13:27
    HipHopAnonymous:
    I programmed a fair bit of LABView in college. The trick to writing clean code is utilization of modules, sequence frames, and loop structures, which is obviously not happening here. LABView isn't terrible for non-programmer types, and it has great libraries for connecting to various instruments, but I wouldn't go back to it unless I absolutely had to.


    Tricks to use it well (or not) I take this as disapproval...in the same vein as most programmers dispprove of COBOL.

    Any tool can be used well or badly, but some tools no sensible person wants to use.
  • Harold III, Sr. 2011-05-17 13:30
    Nagesh:
    Harold III, Sr.:
    Nagesh:
    Meep:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Clearly the idiot is someone who thinks they're going to have graphite dust floating around sensitive electronics.

    If well-designed being electronics, they are not to be suffering with dust, graphite or otherwise. Outside condo window every day I see Internet Cafe witnessing smokers ash falling all over laptops. Have never seen these Windows 98 machines being replaced.

    Windows 98? Thanks, that explains a lot, Nagesh. Why don't you come back when your people decrease by a couple of worlds?


    One Nagesh is un registered. There are many Nagesh but only one true Nagesh.

    In that case, I aim my comment at the 2 billion Nageshes clustered together, clinging for life on the other side of the world.
    Seriously, people? All this time and you can't tell I'm trolling using an anagram of Ganesh?
  • Master and Commander of the Troll Amry 2011-05-17 13:31
    YHBT. YHL. HAND.
  • ted 2011-05-17 13:31
    Alessandrs:
    Harold III, Sr.:
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!

    I've always found that story odd: people bragging about not being able to engineer something that works in zero gravity? What do you do with the pencil shavings? They didn't have digital pencils back in the '60s.

    Clearly, the Americans are the bright ones in this story, and the Russians are little brighter than the monkeys we sent up.


    Not sure the yankees ever actually got their pen working (despite a lot of effort). Getting rid of shavings is trivial, and the savings in not doing the research a massive benefit.

    Do you know how much the research and design for the zero-gravity pen cost? Oh, wait on yanks have never been responsible with money - that's why the GFC happened...


    Getting rid of pencil shavings and graphite dust in a zero-gravity, recirculated air environment is certainly non-trivial.

    And the entire thing is about a pen with a pressurized ink tube. That is a trivial thing to invent and the myths that untold amounts of money was spent on it are just that -- myths with untold numbers.
  • ted 2011-05-17 13:35
    Earp:
    They have had mechanical (extending lead) pencils since 1822.
    Your comment has more Russian than American in it.


    I used those throughout school. Good tech. Would not want to breathe the speck of graphite that breaks off inevitably.
  • Yazeran 2011-05-17 13:39
    ted:
    Yazeran:
    iToad:
    Unfortunately, most LabVIEW code is written by end users, not programmers. I just inherited a pile of literal spahegetti code from the original author to see if I could clean it up, and eliminate a bunch of race conditions and a mysterious latch-up problem.

    One of the first things that I did was create a concurrent state machine description of the logic, and a text-based specification of what all of the sub VIs did. The original developer was astonished. He didn't realize that you could actually design the software before writing it. I also introduced him to comments.

    Moral of the story: Inheriting a large, badly written VBA application is bad. Inheriting a large, badly written LabVIEW application is very bad.


    Amen!

    I have also heard a lot of people saying LabView is soo good: 'you can just take your instrument and within a few minutes get a graph of what it is measuring'. All well and good, but add some 20 different devices (of some 5 to 10 different types) and all of a sudden you end up with some spahgetti like the one shown.
    My beef is that you still can't get a screen big enough that you can properly debug any LabView program doing anything remotely interesting. Add to that some interesting race conditions and you are set for disaster....

    I would prefer a program written in C anytime over Labview, as in C at least you know exactly in which order things get executed, and in my experience, in 99% of the time you never need to do things asynchronous anyways. If your application/problem requires that, then it gets more complicated, but then Labview may not be your choice regardless....

    Yours Yazeran

    Plan: To go to Mars one day with a hammer.


    99% of good software executes asynchronously and works perfectly fine. What do you write that isn't multi-threaded and works best that way? It must be so simple that a LabView diagram would be fine for representing it.


    Well I write Linux-based control software for fuel cell test stations (some of the tests we do last for more than one year!), and yes we do use asynchronous execution for the user interface.

    But for the core data logging / system communication with the different hardware over NI-GPIB and RS232/RS485 serial interfaces the software needs to be synchronized.

    We have tried ot make a LabView system, and yes it was possible to make it work, but it was a pain to maintain for the reasons specified above (add to that system crashes due to windows upcdates going wrong etc), not to mention that some of the NI-supplied drivers for some of the devices (ICPdas 7024 DA modules as I recall) completely blocked the RS485 bus making it impossible to have any other devices on the same serial port!.
    The actual application demands for that device type was read/write once every few minutes, but the NI-dirver insisted reading continously!

    So no I'm not a fan of NI-Labview.

    Yours Yazeran

    Plan: To go to Mars one day with a hammer.
  • Captain Oblivious 2011-05-17 13:43
    Danny:
    "I say, English, I'm no great scholar of the language, but I really don't understand how he's misused the word literally. Perhaps you could explain, old chap? "

    They believe 'spaghetti code' to be a figurative term as the code is not actually spaghetti. However the term has become a figure of speech in and of itself (not 'code that is spaghetti' but precisely 'spaghetti code') ergo blurring the line between a literal and figurative statement. It is literally the figure of speech but not literally code that is spaghetti (the meaning of the figure of speech). IMO the use is perfectly valid; however others might not agree.


    The problem is that "figurative" and "literal" are not opposites. Too many people are stuck on the elementary school definition of "literal", and forget that there are two other senses for the word.

    This is a common problem for words that mean "in fact": "really", "truly", "literally", "actually", "very", etc. People complain that they are misused as intensifiers, when the intensification is merely a side-effect of an accepted meaning.

    It is not an exaggeration to describe that piece of code as "spaghetti", for the reasons you mention (spaghetti code has become a standard phrase describing a certain phenomenon, and this code even looks like spaghetti).
  • Nagesh 2011-05-17 13:44
    Yazeran:

    Well I write Linux-based control software for fuel cell test stations...blah blah. Made up credentials

    Yours Yazeran

    Plan: To go to Mars one day with a hammer.

    I am working for Indian Space Station program and am in person responsibal for overseen all soft development in environment system. I am thanking U.S. for excelent education for multipal Ph.D's from MIT, etc, etc...
    ...lying madarchod
  • UR Kewl 2011-05-17 13:52
    Harold III, Sr.:
    Seriously, people? All this time and you can't tell I'm trolling using an anagram of Ganesh?

    I am presenting this as proof positive that you're a [/i]way[/i] bigger moron than those whom you "troll".
  • C-Octothorpe 2011-05-17 14:08
    Nagesh:
    Yazeran:

    Well I write Linux-based control software for fuel cell test stations...blah blah. Made up credentials

    Yours Yazeran

    Plan: To go to Mars one day with a hammer.

    I am working for Indian Space Station program and am in person responsibal for overseen all soft development in environment system. I am thanking U.S. for excelent education for multipal Ph.D's from MIT, etc, etc...
    ...lying madarchod


    You don't have to feel emasculated that some people actually have cool jobs and skills beyond writing VB macros.
  • Yair 2011-05-17 14:10
    Coyne:

    Any tool can be used well or badly, but some tools no sensible person wants to use.


    Like C++? Alan Kay's famous "I made up the term object-oriented, and I can tell you I did not have C++ in mind" quote comes to mind.

    I'm sensible and I WANT to use LabVIEW. Why wouldn't I?
  • C-Octothorpe 2011-05-17 14:34
    Coyne:
    HipHopAnonymous:
    I programmed a fair bit of LABView in college. The trick to writing clean code is utilization of modules, sequence frames, and loop structures, which is obviously not happening here. LABView isn't terrible for non-programmer types, and it has great libraries for connecting to various instruments, but I wouldn't go back to it unless I absolutely had to.


    Tricks to use it well (or not) I take this as disapproval...in the same vein as most programmers dispprove of COBOL.

    Any tool can be used well or badly, but some tools no sensible person wants to use.


    Like all the LV fanbois on this thread have already stated (and is a constant across all programming languages), the right tool for the right job.

    I'm not going to use C# if I want to write sub 5-milisecond blazing fast trading software, nor would you use LV for an ecommerce site. The tool works well for what it was designed, and that's for people without the will or the know-how of in-depth programming and all it's intricacies. And from my understanding it also abstracts a lot of the "connecting to various instruments" work which would require a lot more knowledge and experience on the part of the programmer.
  • iToad 2011-05-17 15:18
    C-Octothorpe:
    Coyne:
    HipHopAnonymous:
    I programmed a fair bit of LABView in college. The trick to writing clean code is utilization of modules, sequence frames, and loop structures, which is obviously not happening here. LABView isn't terrible for non-programmer types, and it has great libraries for connecting to various instruments, but I wouldn't go back to it unless I absolutely had to.


    Tricks to use it well (or not) I take this as disapproval...in the same vein as most programmers dispprove of COBOL.

    Any tool can be used well or badly, but some tools no sensible person wants to use.


    Like all the LV fanbois on this thread have already stated (and is a constant across all programming languages), the right tool for the right job.

    I'm not going to use C# if I want to write sub 5-milisecond blazing fast trading software, nor would you use LV for an ecommerce site. The tool works well for what it was designed, and that's for people without the will or the know-how of in-depth programming and all it's intricacies. And from my understanding it also abstracts a lot of the "connecting to various instruments" work which would require a lot more knowledge and experience on the part of the programmer.


    You are, of course, absolutely correct. LabVIEW works very well for the environment that you described. However, like many tools, you begin to run into problems when you scale up to large or complex applications. For these types of problems, I develop fairly detailed specifications first (using UML or SysML), and then code them up. Having a good, accurate text-based specification in hand makes working on complex LabVIEW code a lot easier.
  • lolcat 2011-05-17 15:34
    i can haz new wtf?
  • doesnotreply 2011-05-17 15:44
    Snopes guys...

    http://www.snopes.com/business/genius/spacepen.asp
  • Niel Malan 2011-05-17 15:55
    I was anti-LABView since I inherited a spaghetti monster. With time I have learned that it is possible to write neat code, and the ease of writing parallel code is delectable.

    The thing that converted me, however, was the discovery that LabVIEW can handle units. I've not seen any other language that can handle physical units.

    This has two tremendous advantages:
    1.) It becomes dead simple to provide input and output in the units of your choice. The control or the indicator is simply given the units you prefer. Feet or inches or metres or centimetres can be input or displayed, with no coding needed to handle the display on the UI.

    2.) Coding automatically includes dimensional analysis. This means a reduced chance of making a wrong calculation. Accidentally adding the speed to the distance instead of multiplying immediately generates an error.
  • Harabai 2011-05-17 15:57
    Wow, looks like a picture taken of the stadium where 100 Tron Motorcycle racers all died in the same event.
  • Justice League 2011-05-17 17:01
    C-Octothorpe:
    Nagesh:
    Yazeran:

    Well I write Linux-based control software for fuel cell test stations...blah blah. Made up credentials

    Yours Yazeran

    Plan: To go to Mars one day with a hammer.

    I am working for Indian Space Station program and am in person responsibal for overseen all soft development in environment system. I am thanking U.S. for excelent education for multipal Ph.D's from MIT, etc, etc...
    ...lying madarchod


    You don't have to feel emasculated that some people actually have cool jobs and skills beyond writing VB macros.

    Nobody on this site, certainly.
  • Naresh 2011-05-17 17:20
    Today is Indian Holiday and no signs of registered Nagesh. Maybe he is a real Indian.
    http://en.wikipedia.org/wiki/Ves%C4%81kha
    Not really spam, madarchod.
  • Hamish 2011-05-17 17:56
    boog:
    Danny:
    "I say, English, I'm no great scholar of the language, but I really don't understand how he's misused the word literally. Perhaps you could explain, old chap? "

    They believe 'spaghetti code' to be a figurative term as the code is not actually spaghetti. However the term has become a figure of speech in and of itself (not 'code that is spaghetti' but precisely 'spaghetti code') ergo blurring the line between a literal and figurative statement. It is literally the figure of speech but not literally code that is spaghetti (the meaning of the figure of speech). IMO the use is perfectly valid; however others might not agree.
    *raises hand*
    I disagree; if I had code made out of actual spaghetti, what word would I use to describe it? Aside from "delicious"?

    It's important that "figuratively" and "literally" retain separate (and opposite) meanings. "Literally" doesn't reinforce a figure of speech; if it did, figures of speech would take over the language, since we'd never be able to make a distinction.

    For example: If you've been walking all day and you say your feet are on fire, it is a figure of speech. But if you say your feet are literally on fire, it's no longer a figure of speech and you should seek a fire extinguisher and a doctor.


    We tread a dangerous line, and it all comes down to what is a 'figure of speech'. Language largely evolves from 'figures of speech', and as this evolution takes place we get the blurring that Danny points out.
    This blurring is evident if you search for something like "slang vs idiom" on google, and you find that idioms and figures of speech have very similar meanings, and often become slang. According to most sources I could find (in the two minutes I felt I could afford to spend on it) 'Spaghetti Code' would be considered slang. In this context, I agree with Danny's thought's - that the term "literally" (originally used 10 pages ago) was used to emphasise the fact that having a visual of tangled code (as opposed to tangled code in a text editor) was a perfect example of the term "Spaghetti Code"...

    Anyway, I think the point was more that the original Grammar Nazi was a bit of a dick, as the meaning of the original post was quite clear. Unfortunately(?), English is a strnage and tedious language, not helped by it's wide reach throughout the world, and we often see here people using the language slightly differently to how we might in our corner of the world (many people here seem to have a totally different definition of 'irony' than I would use, for example). Someone having a shot at someone for poor grammar (especially in a situation like this where clearly opinion is divided) just highlights what f/wits Grammar Nazis are....
    The original post was clear and coherent for most people (irrespective of whetehr the grammar was correct).




  • boog 2011-05-17 18:45
    Hamish:
    We tread a dangerous line, and it all comes down to what is a 'figure of speech'.
    A "figure of speech" is simply speech that is figurative. Prepending the word "literally" (by definition) makes it not a figure of speech.

    Hamish:
    I agree with Danny's thought's - that the term "literally" (originally used 10 pages ago) was used to emphasise...
    I think most people would agree that's how it was used, just not that it was valid.

    "Literally" emphasizes only one thing about a phrase: literalness. It emphasizes the fact that the phrase is not meant figuratively or metaphorically; it means we are talking about the strict meanings of the words. I don't care if a "figure of speech" has become common in the language, even in formal contexts; it's still figurative because the words that comprise it have other strict meanings.

    Hamish:
    Anyway, I think the point was more that the original Grammar Nazi was a bit of a dick..., as the meaning of the original post was quite clear.
    I agree with you on that; Grammar Nazis are often just douchey trolls. The post was clear enough, and I honestly don't care if people want to use the word "literally" as an intensifier, even if it is wrong.

    But I can't just sit by while someone tells me "literally" doesn't mean "literally" anymore. If it doesn't, then I will need to know what word I can use to convey the former meaning of "literally" in future situations.

    I may need it if I am ever literally stuck between a rock and a hard place, and need to call for help.
  • AndyL 2011-05-17 19:14
    I don't understand why it's so complex.

    As far as I can see every Labview program ever written just pops up a little message telling you that your drivers aren't compatible with the plug-ins you're using.

    I could do that in about four lines of C code.
  • oheso 2011-05-17 19:19
    heebd:
    And if you do need asyncronous stuff you can either spawn children ...


    I spawned a child once, and everything I've done since then has been asynchronous ...
  • Captain Oblivious 2011-05-17 20:04
    boog:


    "Literally" emphasizes only one thing about a phrase: literalness. It emphasizes the fact that the phrase is not meant figuratively or metaphorically; it means we are talking about the strict meanings of the words. I don't care if a "figure of speech" has become common in the language, even in formal contexts; it's still figurative because the words that comprise it have other strict meanings.



    This is your mistake, right there. A word can have more than one meaning. And they can even conflict! "Literal" has at least three meanings, most of which have nothing to do with literal or figurative language. The most important to this discussion is sense 3:

    "true to fact; not exaggerated; actual or factual: a literal description of conditions."

    This sense is so important that all of the synonyms listed refer to it:

    truthful, exact, reliable.

    As a matter of fact, that code looked like spaghetti. It is not an exaggeration to say so. Therefore, the word applies. Get over it already.


    But I can't just sit by while someone tells me "literally" doesn't mean "literally" anymore. If it doesn't, then I will need to know what word I can use to convey the former meaning of "literally" in future situations.


    Continue to use it. Those unable to tell the difference between the "without exaggeration" meaning of the word and the "not figurative" meaning must have some kind of linguistic disability, such as Asperger's or childhood, and therefore do not count.


    I may need it if I am ever literally stuck between a rock and a hard place, and need to call for help.


    It would be wise to entirely avoid metaphor (especially if cliched) if you are in mortal danger. Just say "Help, I am stuck under a rock!".
  • Shinobu 2011-05-18 02:30
    frits:
    Repeat after me: "VI is TRWTF."
    Like Emacs is so much better. Oh wait...
    Also, корэо ёму хитога обакасан даё!
  • Arancaytar 2011-05-18 04:32
    Lorne Kates:
    Why would early 21st century humans make something this complex and convoluted. No no no-- HOW could they make something this complex and convoluted. Not on their own-- no, wait, why was a better question. Yes, and the answer..



    EXTERMINATE!!!!


    Wow, you're right. It's right there in plain sight!
  • uamd? 2011-05-18 05:12
    Reminds me of Bonita/JBPMN
  • tuomas 2011-05-18 06:54
    LabView is great for signal analysis research and many other things. I know, as I also program with Java, C, assembler , etc. depending on application.
  • Richard 2011-05-18 07:49
    from what I have seen that is what most LabView programs end up as.
  • Chewbacca 2011-05-18 09:16
    Boris Vladamir:
    Nagesh:
    This is naturel for most proceses. Once proces is imploding it will show less complex diagram. Once you explode proces, it will get huge, cumbersum and complex.

    Typical American stupidity. I heard story of United States Space Program's engineering of a pen to work in zero gravity whereas the Cosmonauts simply brought pencils!


    What happens when you sharpen your pencil in a space capsule and the graphite dust gets everywhere? That's an actual problem, and it was solved with a zero-gee pen.
  • Chris 2011-05-18 09:21
    Absolutely, Labview is easy to write in, taken that you do it the right way, and it's easy to follow and debug.
    No code should be bigger than one screen, or it should be broken down into submodules (subroutines).
    I have coded labview for years, and i got some really good praise for readability from NI as well as other companies such as Volvo.

    Labview, is a "different" language, and thinking and treating it like a text-based language just doesn't work. You will end up forcing it into an absolute utter unreadable mess.

    The logic and flow of the code is very clear once you begin to understand it, and always goes from left to right, unless you have a loop or sequence that returns the execution to the start of the same (on the left).

    I have seen very bad examples that even tries to force execution from right to left, but that is just bad bad coding..
  • Grant Heimbach 2011-05-18 10:12
    Bad code can be written in any language. It is easier to spot in LabVIEW because of the graphical nature of viewing your links. You could have a horribly large and complex text-based program but you wouldn't know it just by looking at it. That program could be just as bad as this one. I can already tell by your high use of local variables and stacked sequence structure that this code was built up as it went and there probably wasn't much thought on code architecture before you started. I'm positive that all of this could be scoped down to a clean looking State Machine or an Event Handler architecture. The bad thing about good code and bad code is that bad code works most of the time and people are content with it. That is until someone requests a new feature for the application and the whole thing breaks. Post your code up to ni.com/forums if you are looking for some pointers on how to clean this bad boy up and possibly get better performance out of it.
  • TechNeilogy 2011-05-18 10:44
    Hey! Is that the continuity checker code I wrote a few years ago?
  • Nagesh 2011-05-18 11:01
    Naresh:
    Today is Indian Holiday and no signs of registered Nagesh. Maybe he is a real Indian.
    http://en.wikipedia.org/wiki/Ves%C4%81kha
    Not really spam, madarchod.


    Of course I am really Indian, madarchod. Why you poeple doubt is beyond my comprending?
  • boog 2011-05-18 11:14
    Captain Oblivious:
    This is your mistake, right there. A word can have more than one meaning. And they can even conflict! "Literal" has at least three meanings, most of which have nothing to do with literal or figurative language. The most important to this discussion is sense 3:

    "true to fact; not exaggerated; actual or factual: a literal description of conditions."
    Isn't this the same meaning, just adapted for use in other contexts?

    Captain Oblivious:
    As a matter of fact, that code looked like spaghetti. It is not an exaggeration to say so. Therefore, the word applies. Get over it already.
    Yes, of course I know what spaghetti looks like: it's 1-2 pixels wide, rainbow-colored or black, arranged to bend at right angles and generally served in a stark white sauce. I'm not arguing that.

    But I am missing the definition for literal that means "looks like". Perhaps my online dictionary is an older edition than yours.

    Captain Oblivious:
    But I can't just sit by while someone tells me "literally" doesn't mean "literally" anymore. ...I will need to know what word I can use...in future situations.

    Continue to use it. Those unable to blah blah bullshit blah...
    Okay, thank you. This was obviously a very serious concern of mine, and I have, as you would expect, been losing sleep over it. How could anyone rest knowing that a word whose meaning is unquestionably sacred might soon be confounded by a language that evolves faster than a monkey launched into space? What's the point in living if I'm partially unable to express myself in a very rare number of circumstances? I was beginning to think there was no hope for written/spoken language until, fortunately, you came along with your brilliant idea to just keep using the word as is. What helpful advice - I assure you it will relieve me of much worry.

    Captain Oblivious:
    It would be wise to entirely avoid metaphor (especially if cliched) if you are in mortal danger. Just say "Help, I am stuck under a rock!".
    Bravo. I see now why they don't call you Captain Perceptive.
  • AnthonyC 2011-05-18 11:35
    Try going to any physics or engineering lab in the country, and you'll find Labview nearly this bad.

    Most incoming grad students don't have programming experience, and many later find themselves needing to run simulations, or control fancy equipment, in unusual ways. For better or worse, Labview is the language of choice for doing this kind of thing. Maybe it's easier to build in for the inexperienced, because it's visual. But it's completely impenetrable to anyone else. Like, say, the grad student that takes over when they leave. At that point it becomes a black box that (usually) answers come out of.

  • Nagesh 2011-05-18 13:53
    boog:
    Captain Oblivious:
    This is your mistake, right there. A word can have more than one meaning. And they can even conflict! "Literal" has at least three meanings, most of which have nothing to do with literal or figurative language. The most important to this discussion is sense 3:

    "true to fact; not exaggerated; actual or factual: a literal description of conditions."
    Isn't this the same meaning, just adapted for use in other contexts?

    Captain Oblivious:
    As a matter of fact, that code looked like spaghetti. It is not an exaggeration to say so. Therefore, the word applies. Get over it already.
    Yes, of course I know what spaghetti looks like: it's 1-2 pixels wide, rainbow-colored or black, arranged to bend at right angles and generally served in a stark white sauce. I'm not arguing that.

    But I am missing the definition for literal that means "looks like". Perhaps my online dictionary is an older edition than yours.

    Captain Oblivious:
    But I can't just sit by while someone tells me "literally" doesn't mean "literally" anymore. ...I will need to know what word I can use...in future situations.

    Continue to use it. Those unable to blah blah bullshit blah...
    Okay, thank you. This was obviously a very serious concern of mine, and I have, as you would expect, been losing sleep over it. How could anyone rest knowing that a word whose meaning is unquestionably sacred might soon be confounded by a language that evolves faster than a monkey launched into space? What's the point in living if I'm partially unable to express myself in a very rare number of circumstances? I was beginning to think there was no hope for written/spoken language until, fortunately, you came along with your brilliant idea to just keep using the word as is. What helpful advice - I assure you it will relieve me of much worry.

    Captain Oblivious:
    It would be wise to entirely avoid metaphor (especially if cliched) if you are in mortal danger. Just say "Help, I am stuck under a rock!".
    Bravo. I see now why they don't call you Captain Perceptive.



    Captain Oblivous,
    you are having my vote only.

  • boog 2011-05-18 14:12
    Nagesh:
    boog:
    Captain Oblivious:
    blah blah boog-is-wrong blah
    yada yada Captain-Oblivious-is-wrong yada

    Captain Oblivous,
    you are having my vote only.

    Way to commit, Nagesh!

    Not that your vote helps his case in any way at all, but I can appreciate your determination to have an opinion. Kudos!
  • Nagesh 2011-05-18 14:21
    boog:
    Nagesh:
    boog:
    Captain Oblivious:
    blah blah boog-is-wrong blah
    yada yada Captain-Oblivious-is-wrong yada

    Captain Oblivous,
    you are having my vote only.

    Way to commit, Nagesh!

    Not that your vote helps his case in any way at all, but I can appreciate your determination to have an opinion. Kudos!


    True fact booger boy is tht he is not requiring my vote at all.
  • Yair 2011-05-18 16:29
    boog:
    Yes, of course I know what spaghetti looks like: it's 1-2 pixels wide, rainbow-colored or black, arranged to bend at right angles and generally served in a stark white sauce. I'm not arguing that.
    ...

    And so on.




    Well, at least we got one clever and funny reply out of this side debate. Thanks for that.
  • boog 2011-05-18 16:31
    Nagesh:
    boog:
    Nagesh:
    boog:
    Captain Oblivious:
    blah blah boog-is-wrong blah
    yada yada Captain-Oblivious-is-wrong yada

    Captain Oblivous,
    you are having my vote only.

    Way to commit, Nagesh!

    Not that your vote helps his case in any way at all, but I can appreciate your determination to have an opinion. Kudos!

    True fact booger boy is tht he is not requiring my vote at all.
    You may be right there Nagarooni. After all, his comment actually had a clear argument with supporting ideas, and not just arbitrary nonsense about himself or India or Java or CMM or madarchods, decorated in bold or rainbow or encoded in hex or written in Hindi.
  • boog 2011-05-18 16:34
    Yair:
    boog:
    Yes, of course I know what spaghetti looks like: it's 1-2 pixels wide, rainbow-colored or black, arranged to bend at right angles and generally served in a stark white sauce. I'm not arguing that.
    ...

    And so on.


    Well, at least we got one clever and funny reply out of this side debate. Thanks for that.
    Hey, I surprise even myself every now and then.
    You're welcome.
  • Matt Westwood 2011-05-18 17:25
    Yair:
    boog:
    Yes, of course I know what spaghetti looks like: it's 1-2 pixels wide, rainbow-colored or black, arranged to bend at right angles and generally served in a stark white sauce. I'm not arguing that.
    ...

    And so on.




    Well, at least we got one clever and funny reply out of this side debate. Thanks for that.


    You know, we could literally make a Spaghetti Western out of this - cue the music: "daahn daahn daaaaaahn (wee-oo-wee)" ... out of the setting sun rides Captain Oblivious with his duster coat fashioned out of al-dente pasta, ...

    Oh good grief I can't believe I even bothered to write all that. I must be tireder than I thought.
  • Loving It 2011-05-19 00:45
    What resolution, how expensive is the monitor that renders one window like that? I might need only one if it was that size/resolution.
  • Nagesh 2011-05-19 09:00
    boog:
    Nagesh:
    boog:
    Nagesh:
    boog:
    Captain Oblivious:
    blah blah boog-is-wrong blah
    yada yada Captain-Oblivious-is-wrong yada

    Captain Oblivous,
    you are having my vote only.

    Way to commit, Nagesh!

    Not that your vote helps his case in any way at all, but I can appreciate your determination to have an opinion. Kudos!

    True fact booger boy is tht he is not requiring my vote at all.
    You may be right there Nagarooni. After all, his comment actually had a clear argument with supporting ideas, and not just arbitrary nonsense about himself or India or Java or CMM or madarchods, decorated in bold or rainbow or encoded in hex or written in Hindi.


    why you afraid of rainbow?
  • boog 2011-05-19 11:41
    Nagesh:
    boog:
    Nagesh:

    True fact booger boy is tht he is not requiring my vote at all.
    You may be right there Nagarooni. After all, his comment actually had a clear argument with supporting ideas, and not just arbitrary nonsense about himself or India or Java or CMM or madarchods, decorated in bold or rainbow or encoded in hex or written in Hindi.

    why you afraid of rainbow?
    Because a rainbow shot my pa. He's doing much better now, but still can't go outside when it's raining. As for me, I never did catch the rainbow; it was like he just vanished into thin air.
  • LabVIEW Sucks! 2011-05-20 11:19
    This is why LabVIEW Sucks!
  • Anon 2011-05-20 11:25
    LabVIEW Sucks!:
    This is why LabVIEW Sucks!


    FTFY
  • Anon 2011-05-20 11:27
    Every tried search and replace in LabVIEW?

    'nuff said.
  • Anon 2011-05-20 11:33
    Anon:
    Every tried search and replace in LabVIEW?

    'nuff said.

    Yes, and it worked great!
  • Known As Drew 2011-05-21 05:24
    my gripe with Labview is that it hides code.

    Sequences and True/False conditions (at very least) are only visible one at a time.

    Note: I'm working with an old inherited application written in an older version of Labview. It looks just like the code in the original article that spawned all this debate. But I can't see all the code at once. That annoys me.
  • Yair 2011-05-21 14:22
    Known As Drew:
    my gripe with Labview is that it hides code.


    That's a valid argument, but I personally don't find it to be a real issue, and I would like to point out that hiding code is actually also a good thing, as it allows you to focus only on what would happen when specific condition apply, since the rest of the code isn't visible when you're viewing that case. When you have nested decision making, this can be a real boon.
  • KnightRAF 2011-05-22 17:52
    I'm now envious of LabView. I get to work with SIMPL Windows a lot. They went with the schematic metaphor, but don't actually let you design or view it as a schematic. Instead you have to name all the signals coming in and out of each symbol in the program.

    Trying to trace problems through this stuff is a nightmare.
  • Tom 2011-05-23 07:13
    Richard:
    Thankfully you can interface to most of the NI devices from C, and you don't need labview at all.

    Incidentally, I have the interesting problem of an NI4462 card which was sold to me a few months ago as being "supported on Linux". This support uses a nasty binary blob kernel driver that is only available for distros about 4 years old (eg Mandrake 2008). Not impressed


    Oh yes, the glorious NI4462 linux driver ...
    Two years ago I was in a project where we tested whether this card would be a good fit. After two months of fiddeling with the driver and getting quite a bit of support from NI we found out that the card is unusable.
    Without enormous cooling it heats up to 90°C and the requirement was to function in an 50°C environment without any kind of active cooling.

    Good times.
  • Alex 2011-05-25 01:16
    Those guessing that this code controls a wind tunnel are indeed correct, approximately.

    It does work most of the time - occasionally crashes in the middle of important test for no apparent reason though.

    Fortunately, we're going to completely redo the test facility in the next few months, so I'll get to rewrite the program from scratch.
  • TazMania 2011-05-25 10:36
    Hey guys,

    LabVIEW code can be a lot cleaner than most people think. Just like how in C programs you wouldn't have all your code in the main() function, you shouldn't have all your code in main VI - you use sub VIs, which are like functions or modules in C.

    Here's an example of sychronised analogue and digital input in LabVIEW - very well written, very modular, easy to read, scalable - and therefore easy to maintain. Try writing this kind of powerful application in C in the same amount of time?

    https://decibel.ni.com/content/docs/DOC-12185

    If you want to see *well-written* LabVIEW code, the place to go for it is the community examples in LabVIEW - this is where all the good stuff is! Most of us can probably hunt a few different examples and put them together to do exactly what we need!
  • Miroslav 2011-05-25 13:40
    What happens when you pee in a space capsule while sharpening your pencil and the pee gets everywhere? That's an actual problem, and it was solved with a vacuum toilet.

    FTFY

    Idiocy is equally represented among the nations.
  • Schol-R-LEA 2011-06-01 08:25
    Herbert:
    Great. So some people write ugly code in LabVIEW code. Can you find a language that a dedicated programmer *couldn't* write ugly code in with sufficient determination?


    All of the INTERCAL code I've seen seemed elegant to me.

    Or at least it does after reading the Daily WTF for that morning...
  • Jorge B. 2011-06-01 10:55
    well then... can you tell me: Where's Wally?
  • Douglas J. De Clue 2011-06-05 19:53
    Yes this is LabVIEW spaghetti code but it doesn't have to be. You CAN write rather elegant LabVIEW code to solve even rather large scale problems provided you know how to apply some of the more modern features of LabVIEW like dynamic VI launching, queue based communications and state based design.

    The code you see in this example is typical of someone who learned the basics of LabVIEW but never bothered to move beyond an early 1990's understanding of it.

    If you want someone to straighten out this mess send an email to ddeclue2 at earthlink dot com
  • Douglas J. De Clue 2011-06-05 20:19
    r2k-in-the-vortex:
    ah the good ol labview, the very first software project i was tasked to finish looked pretty much like that, in fact first thing i suspected when i opened the artice that it actually was that project. labview has its strong points but they dont lie in making large and complicated applications. its for pretty much what the name says its for, quickly tying together a lab setup by someone who is not nessecarily a programmer. pretty much any measurement equipment comes with labview drivers so for lab technicians its very simple to coordinate many instruments with quick hack of a labview. unfortunately it sometimes also gets used for lot more complicated things and then it ends up like that. it can be a horrorshow


    Actually it is quite possible to write very elegant and readable large scale LabVIEW applications. The same rules apply in LabVIEW as they do in C++ or other languages.

    I write in a variety of languages including C, C++, C#, LabVIEW, LabWindows, FORTRAN, VB, Pascal, and others and LabVIEW was NOT my first language. I started long ago in 1978 with a PDP 8E, two teletypes, a BASIC interpreter and loading and saving to paper tape.

    I didn't start with LabVIEW until 1996 and had already coded commercially in C, C++, VB, and FORTRAN prior to learning LabVIEW.

    If you break apart the various functionality in your LabVIEW code into a series of VI's that each perform a coherent bit of functionality that can each be dynamically launched and which each communicate to other VI's via queue based or TCP based methods then you can write some very readable very elegant code.

    Essentially you normally would have either two or three loops in each of these VI's: 1) for handling any user I/O (if applicable), 2) for processing incoming commands received on the queue or TCP socket, 3) an outbound I/O loop for performing any instrument I/O and transmitting data or commands to other loops.

    The commands are processed via a state machine model using a case statement where the default case is normally to either do nothing or do background processing tasks.

    In any event it is false that LabVIEW code must inherently be messy or unreadable just as it is false that C or C++ code is inherently elegant and comprehensible. I've written quite a lot in both languages, sometimes in combination for a project and have seen plenty of unreadable text based code over the years.

    It is my experience that LabVIEW has the advantage when it comes to rapid application development over any tool I can think of including VB and C#, especially when physical hardware is involved.

    It is my approach in general to work in LabVIEW or LabWindows when hardware is involved because of the extent of support available in these languages for hardware I/O.

    Sometimes I am forced by circumstance to drop into C or C++ because of a lack of that support if working with specialized hardware with proprietary interfaces.

    If working on something oriented towards database, web or general data processing my tendency is to work with VB or C# because I tend to leverage ActiveX from Microsoft Office apps in these cases to minimize my work.

    What I generally have read on this thread is basically a bunch of C++ elitists who really don't know enough about LabVIEW to offer an informed opinion.
  • Cinnamon colbert 2011-07-13 23:02
    Is it on or off..
    this is my biggest complaint with our labview app, which does ok otherwise.
    However, I'm not sure if it is labview or the programmer
  • He Can't Read Law 2011-09-16 12:09
    No, this is bad coding period.

    Electrical diagrams don't have to be organized because they literally represent the parts, which are often reorganized for physical optimization (space, heating, etc).

    However, this is no excuse to have a programming language without visually optimized organization.

    They should have a way to create clear functions, which I would expect to be represented by boxes, with clear inputs and outputs. Within the boxes, complexity can resume.

    The benefit of this?

    The boxes would be abstract, such that when programming, one can program a box without any knowledge of the rest of the program. So there would be no reason to explode the code, ever.

    **THAT** is functional programming.

    What these demonstrate is procedural programming, which is always a mess to look at, which means the either the users have no practical experience in programming, or the language is deficit.
  • He Can't Read Law 2011-09-16 12:12
    He Can't Read Law:
    No, this is bad coding period.

    Electrical diagrams don't have to be organized because they literally represent the parts, which are often reorganized for physical optimization (space, heating, etc).


    I'm sorry, I have to correct myself a little.

    Even electrical engineering incorporates some functional programming in that it often subdivides a device by smaller devices designated by function.

    In a computer, there is a motherboard, there is RAM, there is a PCU, GPU, and so on. All the wiring for the devices is with the components, you don't see one big chip in a computer that has all the wiring such that you don't know if wire X manipulates the GPU or CPU!!!
  • Ambrose 2012-11-16 08:51
    Most/all software patents aren't worth the paper they are printed on in Europe. I would like to do a clean room implementation just to spite NI but why copy a gilded turd.
  • BASE10 2013-06-06 13:44
    Indeed, but Haskell code is cryptic because of the density whereas labview is cryptic due to noise.