LabVIEW Pros vs. Cons?

[natasftw]

---

@richjoh wrote:

---

@Synaesthete wrote:

I have attained a CLA and CPI, and have taught the LabVIEW Basics course several times.  I've written dozens of applications in LabVIEW, and use the latest coding practices and follow strict style guidelines.  I've produced a hundred event-driven state machines, and in my architecture I utilize LVOOP and have a thorough understanding of the actor framework.

---

Let us see the CLA, CPI, teaching and LV and state machines and LVOOP and Actor Framework credentials please? If you need to say this well... no explanation needed.

---

If you don't believe his post, why would he expect you'd believe him posting the CLA gif they send you when you pass as it's easy to copy/paste?  It's possible to be experienced in something and not enjoy it.  Listing those certifications doesn't strengthen his points as they are primarily opinion based.  What purpose does it serve you to essentially throw a tantrum, stick your tongue out at him, and say "nuh uh!"?  Whether he has them or not, he's free to dislike a programming language independent of how you feel about it.

Honestly, I'm less concerned about his credentials than yours if you're asking for LVOOP and Actor Framework credentials.  If you're going to be snarky, shouldn't you at least know which credentials are available?  We clearly have a disagreement in this thread.  It was destined to happen when the topic asks for two conflicting ideas.  Let's try to be civil.

[JHaas]

you would not be annoymous anymore if you showed the certificates I guess? I still think it odd that someone would go all the way up the ladder to a CLA and then do a 180 and renounce it all. At least that was my original thought when I made the comment that re-fired this thread up a couple of days ago. He's obviously is an intellegent person, judging by the writing, so it wouldn't surprise me that he accomplished all that.

[billko]

I know this is a volatile subject, but please let's just poke holes in the opinions and not the egos.

[jcarmody]

---

@Hooovahh wrote:

---

jcarmody wrote:

Books are definitely better than film.  

---

Yeah I guess, if you like viewing in one dimension instead of two.  He's a text programmer guys GET HIM!

[...]

---

I'm a CLD, CPI, and have taught the LabVIEW basics course one time.  I've used the JKI state machine in dozens of applications and I have written several RCF and Quick Drop plugins (references available upon request).  The closest to text programming that I do is TestStand VBA for Access and Excel (no certifications).  Although I can't, for the life of me, understand the Actor Framework, I do understand what actors are and I maintain that I am a graphical programmer!

😄

[Hooovahh]

---

@jcarmody wrote:

Although I can't, for the life of me, understand the Actor Framework, I do understand what actors are and I maintain that I am a graphical programmer!

---

I agree, and the comments I try to reverberate from LabVIEW R&D, is if you have a working, actor type solution, that follows the SMoRES (Scalable, Modular, Reusable, Extensible, and Simple) design, then the Actor Framework isn't for you.  

[Ben]

---

@Hooovahh wrote:

---

@jcarmody wrote:

Although I can't, for the life of me, understand the Actor Framework, I do understand what actors are and I maintain that I am a graphical programmer!

---

I agree, and the comments I try to reverberate from LabVIEW R&D, is if you have a working, actor type solution, that follows the SMoRES (Scalable, Modular, Reusable, Extensible, and Simple) design, then the Actor Framework isn't for you.  

---

Speaking only for myself...

The Actor Framework was hard to understand until I point a LVOOP to UML tool I wrote at it. In UML it makes a lot of sense and the messaging patern used makes it slick. I have not used it yet since I wrote my own that is admitedly less elegant in that the messaging patern is a cluge but it worked in LV 8.2 just fine.

But the confusion when trying to get a handle on a OOP design is not limited to LV. A robust OOP design is often rather cumbersome in appearence since it suffers from the issue;

"With great flexiblity comes complexity"

Just my 2 cents,

Ben

[richjoh]

---

@natasftw wrote:

---

 

Honestly, I'm less concerned about his credentials than yours if you're asking for LVOOP and Actor Framework credentials.  If you're going to be snarky, shouldn't you at least know which credentials are available?  We clearly have a disagreement in this thread.  It was destined to happen when the topic asks for two conflicting ideas.  Let's try to be civil.

---

Well that my point, they're are none, your quoting a quote I quoted. I'm really not concerned with his certs, its not an issue. Getting certs doesn't make you expert or guru. He's titled this pros and cons but appears to be whining about how bad graphical is compared to text. If you meet a text programmer that doesn't like LV, it probably because its concepts don't fit standard textbook (no pun) programming paradigms. This is clear from initial post.

[AKA_TG]

Forgive me if I also add my 2c to the discussion

I know a lot of you guys are really good at programming and Computer science ( I been watching for a number of years) so my input is as a novice (sort of) I'm the typical guy who used C, VB6 in the old days and some C# with dotNET now and then, but is not a true professional programmer per say, just a basic problem solver in our Labs.  I fell for LabVIEW on the Macintosh in the early 90's and never looked back.

LabVIEW has always been (to me) capable to operate hardware seamlessly and quickly. I still believe there is no equal to its  integration and ability to encapsulate the hardware interface away. LabVIEW is exceptional at displaying data quickly as well as tolerant of trying new things out and seeing result right away.  The ability to see result of trying something out (right NOW) is a dream come true for people like me who want to write a simple but powerful app, test it quickly, be happy enough with it, then move on to solving another problem.

My own string based state machine designs are powerful, accepting changes gracefully with reasonable scale up capability as well as UI responsiveness, (perhaps at the expense of readability, but thats Ok with me, I don't think I will be exporting my work to others anytime soon.)

I moved forward from Procedural based programming to OOP concepts right around version 8.2 though. WIthout a good book I was unable to learn

LVOOP just by looking at examples in LabVIEW. I have always felt that the first 'unveiling' of LVOOP was IMHO done too quickly even before labVIEW itself was stabilized. (version 8.2.1 left a bad taste for long time but I am over it now. LV is much better today.)

The LabVIEW implementation of OOP is absolutely solid for a limited number of important objects in my "in-house" applications.

I re-use classes I have made years ago and continue to enjoy using. The other parts of LabVIEW are quite valuable to me and I will always use them as long as I am able to.

The LVOOP part of LabVIEW is (to me) kind of a strange animal with a big appetite for overhead. I have tried for years to go full steam into it since version 8.2.1 and have never been able to get where I wanted to be with it. I still use and enjoy LVOOP, but making major class hierarchies and utilizing dynamic dispatch extensively is way over my ability unless I sat and became full time LV programmer.

It just seems like there is a whole lot of overhead to implementing a class in LabVIEW, even now with 2012 and 2013 versions.

For a main class carriying important responsibility this is fine. I may be wrong but I think even NI would admit that most apps benefit from classes but not from having too many of them. That seems fair as even an app written in C# should not have too many classes either.

[natasftw]

---

@richjoh wrote:

Well that my point, they're are none, your quoting a quote I quoted. I'm really not concerned with his certs, its not an issue. Getting certs doesn't make you expert or guru. He's titled this pros and cons but appears to be whining about how bad graphical is compared to text. If you meet a text programmer that doesn't like LV, it probably because its concepts don't fit standard textbook (no pun) programming paradigms. This is clear from initial post.

---

Why would you feel the need to make the point there?  He never brought up those "certifications."  He brought up having knowledge of the topics and you asked for the certifications, not in a quote of a quote. 

Your entire post was asking for his certs.  It's a bit strange to not be concerned, not see that as an issue, and only post to ask for them don't you think?

Being an expert doesn't really add to the conversation.  Trying to bring someone's qualifications down doesn't negate their opinion, whether it relies on emotion or rational thought.  There's no benefit to trying to show they're not as versed as they think they are.  Even if you're right, it doesn't change the opinion and doesn't offer any actual insight.

There are certainly applications I'd prefer use a text-based approach.  If he's working with those styles of applications, it wouldn't shock me that he'd prefer use text-based languages over LabVIEW.  There's also applications where I'd dread using text-based code.  There's a good chance the people excited about LabVIEW work in those domains. 

[Synaesthete]

Really my recent arguments have less to do with a direct feature comparison between LabVIEW and text-based languages. Yeah, LabVIEW can do what C++ can do. My arguments fall in to the following:

1.) Programmer ergonomics and efficiency

2.) Short-term vs. long-term learning curves

3.) Size of the ecosystem and the quality of its participants

4.) Pace of evolution of the language, tooling, and increasing applicability to new fields

5.) LabVIEW as a software engineering profession

6.) Cross-compatibility with other platforms

Based on my experience with both (trust me, I was a LabVIEW fanatic for years, how would I have achieved certifications and gleefully taught students otherwise?) LabVIEW doesn't hold a candle to text-based, open platforms in these categories. I think there's an inherent hindrance that makes LabVIEW more sluggish, less adaptable, and less evolvable. It's one part the restrictions of a graphical environment, but also in the NI strategy.

I'm envisioning a scenario in which the NI hardware solution is way more accessible through a more open approach and embracing the other 95% of the software industry that is modern text-based languages. Additionally, this motion seems so beneficial that it would surprise me if NI isn't seriously considering it or working towards it. If the NI hardware platform opened up, and you didn't have to use LabVIEW any more, what kind of impact might that have on a professional LabVIEW programmer who hasn't touched text-based languages in years (or ever)? What if suddenly there were ten times more programmers who could integrate NI hardware?

And which approach would industry prefer? An expensive proprietary language that doesn't fit with the rest of their tooling and with a relatively small ecosystem, or a more widely adopted open language with lots of qualified people and better interoperability with their existing systems?

PS - All my certs expired long ago so you're right, I'm completely uncertified to be talking about this.