• wingcommander (unregistered)

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

    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?

  • (cs) in reply to QJ
    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 (unregistered) in reply to Boris Vladamir
    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 (unregistered)

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

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

    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 (unregistered) in reply to Harold III, Sr.
    Harold III:
    Nagesh:
    Meep:
    Harold III:
    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 (unregistered) in reply to Yazeran
    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 (unregistered) in reply to Goosey Goo
    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.

  • (cs) in reply to HipHopAnonymous
    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. (unregistered) in reply to Nagesh
    Nagesh:
    Harold III:
    Nagesh:
    Meep:
    Harold III:
    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 (unregistered) in reply to ted

    YHBT. YHL. HAND.

  • ted (unregistered) in reply to Alessandrs
    Alessandrs:
    Harold III:
    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 (unregistered) in reply to Earp
    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.

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

  • (cs) in reply to Danny
    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 (unregistered) in reply to Yazeran
    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 (unregistered) in reply to Harold III, Sr.
    Harold III:
    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 (unregistered) in reply to Nagesh
    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 (unregistered) in reply to Coyne
    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 (unregistered) in reply to Coyne
    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 (unregistered) in reply to C-Octothorpe
    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 (unregistered)

    i can haz new wtf?

  • doesnotreply (unregistered) in reply to Boris Vladamir

    Snopes guys...

    http://www.snopes.com/business/genius/spacepen.asp

  • Niel Malan (unregistered)

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

    Wow, looks like a picture taken of the stadium where 100 Tron Motorcycle racers all died in the same event.

  • Justice League (unregistered) in reply to C-Octothorpe
    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 (unregistered)

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

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

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

  • (cs) in reply to boog
    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 (unregistered) in reply to frits
    frits:
    Repeat after me: "VI is TRWTF."
    Like Emacs is so much better. Oh wait... Also, корэо ёму хитога обакасан даё!
  • (cs) in reply to Lorne Kates
    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.. [image]

    EXTERMINATE!!!!

    Wow, you're right. It's right there in plain sight!

  • uamd? (unregistered)

    Reminds me of Bonita/JBPMN

  • tuomas (unregistered)

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

    from what I have seen that is what most LabView programs end up as.

  • (cs) in reply to Boris Vladamir
    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 (unregistered) in reply to Kiss me I'm Polish

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

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

    Hey! Is that the continuity checker code I wrote a few years ago?

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

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

    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.

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

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

Leave a comment on “Labview Spaghetti”

Log In or post as a guest

Replying to comment #:

« Return to Article