• Yair (unregistered) in reply to boog
    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.

  • (cs) in reply to Nagesh
    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.

  • (cs) in reply to Yair
    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.
  • (cs) in reply to Yair
    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 (unregistered)

    What resolution, how expensive is the monitor that renders one window like that? I might need only one if it was that size/resolution.

  • (cs) in reply to boog
    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?

  • (cs) in reply to Nagesh
    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! (unregistered)

    This is why LabVIEW Sucks!

  • Anon (unregistered) in reply to LabVIEW Sucks!
    LabVIEW Sucks!:
    This is why LabVIEW Sucks!

    FTFY

  • Anon (unregistered)

    Every tried search and replace in LabVIEW?

    'nuff said.

  • Anon (unregistered) in reply to Anon
    Anon:
    Every tried search and replace in LabVIEW?

    'nuff said.

    Yes, and it worked great!

  • Known As Drew (unregistered)

    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 (unregistered) in reply to Known As Drew
    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 (unregistered)

    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 (unregistered) in reply to Richard
    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 (unregistered)

    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 (unregistered)

    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 (unregistered) in reply to Chewbacca

    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 (unregistered) in reply to Herbert
    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. (unregistered)

    well then... can you tell me: Where's Wally?

  • Douglas J. De Clue (unregistered)

    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 (unregistered) in reply to r2k-in-the-vortex
    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 (unregistered) in reply to Meep

    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 (unregistered)

    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 (unregistered) in reply to He Can't Read Law
    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 (unregistered) in reply to Kuba

    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 (unregistered) in reply to Axel

    Indeed, but Haskell code is cryptic because of the density whereas labview is cryptic due to noise.

Leave a comment on “Labview Spaghetti”

Log In or post as a guest

Replying to comment #:

« Return to Article