LabVIEW Pros vs. Cons?

[JÞB]

---

@Ben wrote:

Talk about a "bad fit". I don't drink the Kool-aid, and have been advised by my wife to never wear suspenders with a polo shirt (again).

Ben

---

OK, I admit that backfired.

My goal was to increase the technical content of this thead.  I failed hilariously.  Next try?

[Britoa]

---

@altenbach wrote:

We are all programmers, and the difference between a text based programmers and a graphical programmer is smaller than you might think. There is a much wider gap separating us from the class of non-programmers. 😄

There is no magical law of nature that says that text based projects do not get more complex as the size of the project increases. If anything, graphical code scales better. If you double the code, a text based program with be twice as long, but a graphical program will only grow by sqrt(2) in each dimension. O(N) vs. O(sqrtN) make a big difference as N gets larger.

All that said, I am more productive using LabVIEW, and since resources are limited, that also means the difference between feasible and impossible. 😄

---

a very OO approach to people, I'm just glad C++ people is a friend (class) to LabVIEW. 

As for the O(N) vs O(sqrtN), I thought we discouraged people from making the code take more than one screen 😛

[X.]

---

Britoa wrote:

As for the O(N) vs O(sqrtN), I thought we discouraged people from making the code take more than one screen 😛

---

Sure, but there is not official limit to the screen size. Or is there?

[Ben]

---

@JÞB wrote:

...
OK, I admit that backfired.

...

---

Sorry!

Lets see if I can recover the thought by Synaesthete.

I mentioned the SDE was dropped for support.

The SDE was the key that ws used to open up scripting in LV. It was shipped without a password and the next thing you know... Scripting is a reality.

The SDE was written in LV.

What would be a nice move by NI would be to release the code for the SDE and let the community have at it. I always thought it would be a grat place to start with givning LV a "higher level look and feel" if could add a copule of extra features to let us view the documentation that explains a state by floating over the bubble in the SDE and alos let us add the documentation with out having to go to the diagram for that state.

It also could benefit from being able to select multiple states in a diagram and let us do a "Create Sub-State Digram" so we could easily clean-up our State Diagrams.

The ancillary for the "Create" would be an option to right-click and SHow Sub-SD.

Other options would include viewing the cluster data used in the SD as well as defining the cluster type def while editing.

I think that could be an open source project that could be benificial.

Ben

[altenbach]

---

@X. wrote:
Sure, but there is not official limit to the screen size. Or is there?

---

I just got a Samsung SA850 (27", 2560x1440 native) , and that means I can finally inflate my VIs. 😄

[Yamaeda]

---

@altenbach wrote:

---

@X. wrote:
Sure, but there is not official limit to the screen size. Or is there?

---

I just got a Samsung SA850 (27", 2560x1440 native) , and that means I can finally inflate my VIs. 😄

---

6 of those in a eyefinity setup and you'll have 7680*2880 to fill. Combine with some stacked sequences and sub-vi's are a thing of the past! ;D

/Y

[Synaesthete]

In the past several years, the concept of the "Model-View-Controller" architectural style (http://en.wikipedia.org/wiki/Model_view_controller) has become a dominant pattern used by software engineers.  Separation of concerns is important not just for purely technical reasons, but also for project management purposes.  Following this design pattern tends to allow a cleaner separation of tasks amongst employees, and is extremely scalable and less prone to scope change issues due to loose coupling.  The benefits of following this design pattern can not be overstated.  If you are a professional software engineer, you should be using the MVC architecture--it will save you time, money, and headaches (I will make an exception for very small projects or well-defined medium size projects... you could probably get by fine without it).  If you have an architecture that works better, the world would love to know.

The best way to achieve this design pattern in LabVIEW is to use the actor framework.  The actor framework is the most exciting thing to happen to LabVIEW software architecture since the producer-consumer, and I highly commend its developers--this is the 'right' way to architect software, and bringing it to the world of LabVIEW helps tremendously.

However, using this framework requires a healthy knowledge of LVOOP.  LVOOP in itself is 'not' a design pattern.  There are probably ways of implementing separation of concerns without OOP, but I don't know of any such standard architecture that is not object-oriented.  LVOOP unfortunately is far from seeing widespread adoption, probably because most LabVIEW engineers are not software engineers.  For medium to large-scale projects, a lack of LVOOP and MVC is costing companies time and money and creating major headaches when it comes to scalability, transfer to other engineers, and scope creep.  The actor framework is also built using LabVIEW graphical structures whose true value to the actor framework is questionable--that is, if you could design a perfect graphical programming environment for implementing the actor framework and MVC, would it or should it include LabVIEW graphical constructs?  As it stands, if you are programming using straight OOP and MVC, text-based languages are very mature in this area whereas the LabVIEW environment is and will continue to be in an experimental state.

My conclusion is that with LabVIEW, you are allowing non-software engineers to build large-scale applications such that they are not following best practices, which represents a significant inefficiency.  The methods for actually following modern best practices in LabVIEW are still very experimental, and going forward, it is questionable whether the LabVIEW graphical constructs actually provide any significant advantage when implementing MVC architecture--if you are already a skilled software engineer, you should already be familiar with text-based alternatives for MVC and would likely be better off using those outside of experimental uses.  Beyond this, if you are working with other LabVIEW engineers and expect your actor framework project to be worked on by anyone other than you, good luck!

The best solution as I see things in the future would be to forget about implementing the MVC architecture altogether in LabVIEW (perhaps the actor framework will eventually prove itself--but that will also require significant support within the native environment).  Minimize LabVIEW to a platform for developing very small modules for hardware interaction in a way that electrical and mechanical engineers can make sense of easily without trying to tackle large software engineering concepts (unless they want to, but then you may call them software engineers).  Outside of that, all large-scale applications should follow MVC guidelines and be implemented in other languages altogether--just pass data over TCP/IP or expose access to queues (hello NI!), etc. in a publicly documented way to get better hooks in to LabVIEW from other languages.  I believe that abandoning LabVIEW as a general-purpose programming langauge altogether would do a world of good for our industry.

[smercurio_fc]

It hasn't been six months yet. You have to wait before dredging this up again.

[Mark_Yedinak]

Fine, we all know that you are against LabVIEW regardless of how much you try to say you aren't. You are nearly as good as my ex wife at throwing thinly veiled insults. Unless you truly want to have a productive conversation about improving things instead of trying to bend everyone accept your narrow view of things then why don't you just drop your endless attempt to rid the world of LabVIEW and go away.

[Ben]

---

@Synaesthete wrote:

In the past several years, the concept of the "Model-View-Controller" architectural style (http://en.wikipedia.org/wiki/Model_view_controller) has become a dominant pattern used by software engineers.  ...

 I believe that abandoning LabVIEW as a general-purpose programming langauge altogether would do a world of good for our industry.

---

I used a MVC type design when I worked with Robert J Schmalstieg (now with HP Network Support) to write what may have been the firt Ethernet Sniffer (like Wire Shark) back in about 1988. We were developing in VAX-Macro at the time.

My applications typically are structure along thos lines and have been as long as I have been developing in LV.

We don't have to wait for someone in achadaemia to bless a good idea before we can use it. WE also don't have to wait for them to tell us something is a good idea when see it.

Post # 22 in this thread has some design documents or some very old projects of mine. They should illustrate that LV can use design patterns like other languages can. I admit those may stray from the narrowly defined definitions of a MVC but I was not trying to adhere to what the "experts" said and just utilized a good idea.

On a similar note, I shared my designs with the head of a big impresive global company and he commented "A little Mealey a little Moore.".

Analogy time!

A champion stock car racer does not have to first attend an official drivers school to become a good driver.

Similarly a good developer (any software language) does not have to pas through a school and follow their guidelines to be a good developer.

Yes NI did not include Active Objects are part of LVOOP, but that did not stop me from inventing my own version.

And yes it was Pure-G.

Ben