- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Well, at least we got one clever and funny reply out of this side debate. Thanks for that.
Admin
Admin
Admin
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.
Admin
What resolution, how expensive is the monitor that renders one window like that? I might need only one if it was that size/resolution.
Admin
why you afraid of rainbow?
Admin
Admin
This is why LabVIEW Sucks!
Admin
FTFY
Admin
Every tried search and replace in LabVIEW?
'nuff said.
Admin
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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!
Admin
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.
Admin
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...
Admin
well then... can you tell me: Where's Wally?
Admin
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
Admin
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.
Admin
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
Admin
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.
Admin
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!!!
Admin
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.
Admin
Indeed, but Haskell code is cryptic because of the density whereas labview is cryptic due to noise.