LabVIEW Pros vs. Cons?

[Synaesthete]

Sorry, I couldn't resist.

Trust me, I am being provocative but I truly have the kindest intentions at heart.  Contrary to how it may come across, I'm one of you.  I love LabVIEW engineers (I am one) and I completely support the tool and the community--I'm (perhaps not so well) trying to speak out about something that I feel should be taken to heart by the community.  Out there is a cold, voracious beast of an economy.  Software is big money and it's evolving pretty quickly outside the comfy world of NI integration.  I wish I had some more data or something to show what's happening out there, but it isn't totally unlike a shift to guerilla warfare.  Job security (prosperity) is certainly a partial driving force for me, but not at the expense of taking away LV jobs--rather I'd like to see things evolve towards continued prosperity.  I don't doubt NI is doing what they can and has great visibility in the market as well, so my discussion is more directed to encourage LabVIEW programmers and firms to be considerate of the greater market as well, and to appropriately demand changes from NI that will tend to support their livelihood.  Again, sorry I don't have many straight-forward examples and my explanations and justifications seem convoluted.

[Ben]

Listneing in on a conversation between me and a buddy who was laid-off by HP and was looking in December of 2011

[Set Fly on the wall mode = true]

Ben: What kind of jobs are you seeing on Monster?

Buddy: I'll show you... See here's one you can do... and here is another one... You can probably do this one too....

[set Fly on the wall mode = false]

Ben

[Synaesthete]

Yeah, that volatility of the software industry is indicative of the kinds of crazy rapid shifting that's going on.  I think it's wonderful that LV programmers have been (slightly) more exempt from that volatility.  It's definitely helped keep me afloat over the years whereas others have not been so fortunate.  One of the points I've been trying to make is that the relative calm of the LV world has been harbored not purely due to the tool, but due to great efforts by NI.  Anything we can do to keep step with and abreast of the greater market, and demanding an evolution of our tool that reflects such shifts, will help ensure continued prosperity due to inherent qualities of the tool rather than a continued trust that NI will save us all.

[SynergyMike]

I have coded a couple dozen programs in various text based languages over 20+ years, and perhaps a dozen in LabVIEW (since 2008, and only LV7.1 at that).  By far my biggest gripe with BOTH categories is working on someone else's programs, where that someone else did a sloppy coding job.  However, I will say that while fixing sloppy LV code can be VERY time consuming, fixing someone's text program can be _impossible_. 

Aside from that, I would rather code in LV - I just find it easier to follow pictures in a logic based control system (which a program is, but a book most certainly is not!).  Think about electronic schematics and machine assembly diagrams - would you want to wade through a verbal only description of either?

Michael Tracy

Synergy Microwave

[Synaesthete]

Before anyone else says it, I realize I've taken the tone of Henny Penny. 

[nonecure]

The biggest con I see of using LabVIEW is my mousing hand hurts from too much mousing!

[Doc937]

A persons choice of language to write in is just that... THEIR choice. There are pros and cons to all languages. If you want to be accurate, writing in assembly language is the only truly efficient code. Outside the incredible overhead needed to organize and/or write a project in assembly, it will always be the most efficient code. That aside, all higher languages offer comfort to some aspect of coding, but are less efficient for throughput. Some languages are closer to assembly than others. Some are limited by not being able to access some of strong features of computing. No language is as efficient as assembly. Straight C comes the closest, but all the factors involved in deciding how to reach the end of a project are going to be interpreted differently by each individual applying thought to the goal. Companies decide to use one language over all others because they have multiple employees working these projects and they have to have a common reference when developing the parts that make the whole. The choices they make about which language to make standard is determined by what they know about those languages they know. This will be different for every individual. Anyone can claim they know all there is to know about all the languages available at this time in history, but they are fooling themselves, no-one else… well maybe some – lol.

[Ben]

---

@Doc937 wrote:

.... If you want to be accurate, writing in assembly language is the only truly efficient code. ...

---

As an ex assembly coder (PDP-11 "012737 octal = move the data that follows this instruction to the adress that follows that" AND Vax Macro) I still "see" LV functions as a set of machine language operations and I am repeatedly awed by how efficient LV is.

Ben

[Mark_Yedinak]

---

@Doc937 wrote:

A persons choice of language to write in is just that... THEIR choice. There are pros and cons to all languages. If you want to be accurate, writing in assembly language is the only truly efficient code. Outside the incredible overhead needed to organize and/or write a project in assembly, it will always be the most efficient code. That aside, all higher languages offer comfort to some aspect of coding, but are less efficient for throughput. Some languages are closer to assembly than others. Some are limited by not being able to access some of strong features of computing. No language is as efficient as assembly. Straight C comes the closest, but all the factors involved in deciding how to reach the end of a project are going to be interpreted differently by each individual applying thought to the goal. Companies decide to use one language over all others because they have multiple employees working these projects and they have to have a common reference when developing the parts that make the whole. The choices they make about which language to make standard is determined by what they know about those languages they know. This will be different for every individual. Anyone can claim they know all there is to know about all the languages available at this time in history, but they are fooling themselves, no-one else… well maybe some – lol.

---

While I can understand what you are saying I don't think this answer applies to the overall question. Efficiency for program development is more than simply how few instructions are used or how quickly it executes. Productivity or efficiency in development is more concerned with the time it takes to actually create the application. I would argue that developing only in assembly would take much longer than any other language and require much more knowledge on the programmers part. Not to mention your skills are limited to a single family of processors. It is very difficult to port code for one processor family to another.

Modern optimizing compilers are very good at generated very efficient machine code. The vast majority of programmers could not even come close to this level of coding if working in assembly and to be honest they shouldn't care. Let the compiler handle it and allow the developers to work at higher levels of abstraction allowing them to be more productive programmers.

[Ben]

---

@Mark_Yedinak wrote:

.... Let the compiler handle it and allow the developers to work at higher levels of abstraction allowing them to be more productive programmers.

---

I agree 100%!

Technically speaking I could smelt my own iron for the nails used in my new deck but it is much more effiecient to just buy them.

Ben