LabVIEW Pros vs. Cons?

[PhillipBrooks]

It appears that Synaesthete has been thinking about this for a while: 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improved-interface-for-OO-programming/idc-p/1594312

Maybe the screen name Synaesthete (wikipedia) has some significance in this discussion?

I smell a programming language war

[Synaesthete]

Sorry to cause irritation, if you don't like it, vote with your feet and don't click on this topic!

I think that the frustration I have is that I've encountered a lot of engineers who only use LabVIEW for whatever reason, not because it's a better tool, but because it's all they've really had experience with in their careers.  I'd like to see LabVIEW marketed in a different way and redesigned not to accomodate this tendency.  I'd like a lot of existing LabVIEW engineers to revisit text-based languages (really learn them).  I'd like to see better engineering and better design by virtue of using all the right tools.  I'd like to work with more diversified engineers and less monolithic LabVIEW coders.  I'd like to never inherit awful, unusable LabVIEW code from customers.  I'd like a graphical programming language to do awesome things without the sacrifices.  I'd like the industry to evolve.

I've been partially inspired by the Occupy Flash movement, which was probably a marketing stunt by Adobe to be honest.  Basically, the web industry just decided to stop using Flash because it sucks, and the new canvas technology is much better.  Of course, it's easier for that industry to move on from that because Flash is just one tool in their toolbelt and not the only thing they work with.  That's not the case with LabVIEW, and I think that's a problem.

[SteveChandler]

Now who is getting defensive? 😉

[Synaesthete]

Phillip--thanks for posting, I forgot about that.  I know I'm ruffling a few feathers but I think it's necessary to present alternatives.  We're all in this industry together and I want to say things that I'm thinking in case there are others who are thinking it, or others who might think it given the opportunity to consider those alternatives.  I'm still earlier on in my career (but have a lot under my belt), and have at least another decade or two (not assuming the worst!) of my career ahead of me, so I have some ideas for how I'd like that to shape up.  If I see LabVIEW heading in one direction and I see through my experience that another direction might be better, why not mention it?

[Mark_Yedinak]

---

@Ben wrote:

For myself...

Provided the forums stay active in helping and NI does not load on too much "Expert help" (NO Spoolies) I see LV replacing C and other languages in the future.

I say that becuase the younguns coming into the work-force are growing up in a graphic world and I suspect they will choose to "Draw picture" rather than "check spelling" when they are given a chance.

It may not happen until after I am gone but my money is on LV.

Ben

---

I share your opinion Ben. I too think LabVIEW, or some other graphical language, will be the dominant programming language in the not too distant future. I had this same discussion with some folks at the CLA Summit. They did raise some valid issues regarding how a text based language can be more suited for some people with physical challenges (poor eyesight, severely color blind, bad fine motor control). I do think these issues would be addressed as the language is more widely used.

One comment for the original poster. You do realize that LabVIEW has been out and successful for over 20 years. Over that time it has been extended, improved and adapted to new technologies. It usage and acceptance has also increased over the years. There is nothing to suggest that NI will not continue to be as supportive of continued improvement to LabVIEW in the future. Therefore ringing the death bell for it may be very premature.

[Synaesthete]

I definitely think there is need for more graphical syntax in programming languages.  I don't doubt that LabVIEW could evolve in to something that does replace something like C, but that all depends on the evolution, and that's why I'm posting.  I don't think you'll ever get by with an exclusively graphical language for the same reason that we don't use hieroglyphics; there is an extensibility to text that can't be matched by graphics alone, and it's easy to come up with all kinds of neologisms on your own.  The dictionary, for example, reflects the popular evolution of the language--we are constantly adopting new words on our own, we don't need Merriam-Webster to include it before we can use it.

I understand that LabVIEW has been around for 20 years, but certainly there's nothing about being well established that prevents your demise.  I also understand that it has been adapted over time, and obviously it will continue to do so, but I'm wondering when those changes will be less incremental and more of a total overhaul.  Text based languages are evolving, multiplying, diversifying, specializing, and becoming increasingly interoperable.  LabVIEW must do the same, and so should its users.

[SteveChandler]

Well... Text is graphics.

LabVIEW is to C as written Chinese is to written English. It is much more colorful and rich. People today can read 500 year old Chinese text like yesterday's paper *. Try making any sense out of 500 year old English text!

* or so I am told. I don't know any Chinese.

[Norbert_B]

NOW we are getting somewhere.

So there are features in LV you like, some you don't like. I think that's fine with everyone here.

You seem to have some kind of dislike regarding LV because you encountered too much bad code:

---

@Synaesthete wrote:

[...] I'd like to never inherit awful, unusable LabVIEW code from customers. [...]

---

Nobody does. Nobody wants to inherit unreadable code. But it happens. It happens every day, lot's of times all around the world.

And it is not limited to LV. Not at all. Heck, it is even not limited to computer science! How often do you receive e.g. an email with unstructured sentences, where the meaning is just guessable if at all?

Even here in this forum, you will find enough of those instances as LV Code, CVI Code and the postings themselfes. Man, even my own posts seems obscure at best some times......

And be assured that your points are in discussion... in most companies, in most projects, for most tools.

But to be honest: You are not going to change it. Not for the big picture. Not for LV, not for C#, not for JAVA and whatever programming language you stand up for.

Developers try their best, do what they can in limited time. Giving in for trade-offs because of time constraints or missing knowledge is "normal". And you are correct, that LV seems to be more exposed to this than other programming languages.

But you can turn around the discussion as well:

People tend to create short-term solutions. They search for tools, which do fit into this best. LV does. So it is no surprise that people try to get results fast, even without enough training and planning of the whole architecture.

We do concur that this does not meet any requirements for mid- or long-term solutions. And we concur that most often this leads to bad style and unreadable application code.

But is it the fault of the tool? Of the marketing machinery? The developer? The manager of the developer not planning enough development time nor granting proper training? The fault of the customer wanting a solution NOW and not in half years time frame?

You see, we cannot clearly point fingers somewhere. So it is our job, the developers with LOTS of experience, to share it, to give guide lines to improve code and development processes all around the world. This is what this forum is all about!

And just to give you something to think about:

You dislike some of the very basics of LV, but you like the general idea. You ponder the doom of LV because you think that NI is not reacting fast (if at all) regarding your wishes.You want to push LV into a certain direction. This is, in general, not bad.

But you try to push it towards something, what is already there. You state that LV has to evolve to something you are used to.

If this would happen, it could incline other, better, cooler, more intuitive and *add any other appropriate positive word here* features to emerge. Because you compare it with something present. I am missing the "vision" in your postings; but it seems that you decline to observe the vision of NI regarding the future of LV. Have you ever been to NI Week?

And i dare to state:

Many applications do improve if designed by OOD and implemented in OOP (may it be LVOOP or C# or ....), but there are still tons of applications which do not gain anything positive of OOP.

just my 5 cents,

Norbert

[WayneS1324]

I use LabVIEW. I like LabVIEW. I've written several large applications in LabVIEW. I'm also working on a programming project using Java.

My point is, I'm not a LabVIEW hater.

However... LabVIEW (itself) will never replace C, C++, Java, etc. as long as its as closed as it is. Thats not to say that a more open implementation of G wont eventually replace older languages. I dont mean like Open G. I mean open source compilers and such (pretty good bet though that these compilers wont be written in G).

[Mark_Yedinak]

---

@WayneS1324 wrote:

I dont mean like Open G. I mean open source compilers and such (pretty good bet though that these compilers wont be written in G).

---

I'm not so sure I would bet my life on this. I was talking with Jeff Kodosky (you know, the father of LabVIEW) earlier this week and he is experimenting with writing the G compiler in G now.