NI: Get to grips with Fundamental LV Shortcomings.

Question

I am not new to software. Having done my fair share of traditional, and, for the last 15 years, OO development I have used quite a few tools and
programming languages: C, C++, Smalltalk, Java, Eiffel, C# and also written my own programming langauge. The most professional Programming
Environment I have ever seen is Eclipse (Java Programming Environment) (www.eclipse.org) which again has inherited it's  powerful ideas and tools from
Smalltalk envrioments.
I have used LabView for shorter periods in several of its incarnations.  I recently finished a fairly large Realtime Control Project  using version 8.2 and the
State Diagram Toolkit. (see this thread: http://forums.ni.com/ni/board/message?board.id=170&message.id=234831).
LabView is a very powerful environment, but like most environments it has its shortcomings. And now we are getting closer to what this thread is all about:
** Navigating Source Code ** (Search & Replace  / Find References to objects / Instances)
Fundamental Search
The problem is: Many of these issues are ** fundamental ** and easy to fix, but nothing seems to be done about them! I recently upgraded to version 8.5,
and expected the ** fundamental ** lack of the ability to search for references to my Shared Variables to be fixed. But I was terribly dissapointed, and to be
honest:
If a developer cannot Navigate his / hers code, she / he is not in controll of the developed software!
I have never before seen a programming enviroment that has no feature whatsoever to find References to Variables used in a Program! Unnecssary to say,
this is an absolutley fundamental tool for any programmer: In text based languages you of course have text bases searches, which are crude, but it does the
job. In Eclipse you can even search for where variables are Assigned to, or Read from! (The search is actually searching the Parse Tree).
However, there is not even a Text Based search for Shared Variables in LabView 8.0 to 8.5 and all its intermediate upgrades!
I have spent countless hours using the extremely crude, cumbersome and time waisting method of deleting the Shared Variable and thereby getting a
compliler error showing me where the variable is used: Then I have to close my project withouts saving,  reopen the project again and get back to where I
was working. None of this time can be billed to my clients.
Yes, I know LabView in the meantime has received a host of powerful features. But this is fundamental feature would take any of NI's highly qualified
developers a few hours or a day or two to fix.
So why isn't it implemented? I bet NI's developers miss it as much as the next guy.
I guess this fundamental feature does not look so good on the Marketing Peoples brochures, so they figure NI's developers should spend their time on new
features that they can promote and use to get us to upgrade: Guess what: I will wait a very long time until I ugprade again.
The LabView Search Dialog
The Search Dialog miss one important feature: The ability to Point at any VI / object in a Block Diagra, to say "this is the type I want to search for".
Often I cannot find the type I want to search for in the lists the Search Dialog is presenting.
Other times I simply do not know what the type is, and where to find it, but I am looking at it in an open Block Diagram!
Enter the StateChart Module
As I said, we used the StateDiagram Toolkit to develop our Control System: 9 Processes each running their separate State Diagram on a cFP 2120 system.
The StateDiagram Toolkit is very basic: Not able to resize any state circles or even move more than one at a time: It has been like this for  more than two
years. However, we are in control of the generated code, and could find references to my VIs in the generated code.
The StateChart Module is an implementation of the UML StateChart Implementation. Going through the Tutorial I was quite impressed.
However, yet again the lack of the ability to search for References to important Resources lets the product down:
a) Not possible to Find references to where in the Diagram any Trigger is used.
b) Not possible to Search for any used instance / object within a Diagram: Objects / Instances used within the Diagram does not even show up under the
"VIs by Name list"
c) Text Searches possible, but matches are found in generated code and ** not ** in the Diagram.
    The generated code has no link whatsoever back to the Diagram.
I will post another thread with the shortcomings I have found in the StateChart Module and some ways to circumvent these shortcomings.
Upgrades: What about Tools Developers used in previous versions?
It is very important for developers to know what happens to the tools they are already using when upgrading to a new version.
We used the State Diagram Toolkit for thje project we just finished. However, I could not find any words about what happened to this Toolkit in version
8.5! Developers cannot upgrade without knowing that tools they are using are still working.
We did not upgrade to version 8.5 during our project, but stayed with version 8.2. And I am glad we did: After the project ended, I moved the source code
to version 8.5. Everything worked and the cFP 2120 code was also running: However, the performance had deteriorated with > 33%. See this link:
http://forums.ni.com/ni/board/message?board.id=170&message.id=275320
Question: What about the Next LabView Release?
It has taken Natioanl two decades to produce a very capable development system. However, it only takes the introduction of a few more features where the
Programmers do not have Navigation Control (ability to search & find / replace) to bring the productivity of this product down to its knees.
I certainly hope that NI in the next LabView Release concentrates on fixing these and other Naviagion shortcomings (rather than introducing features) to bring
LabView up to the Speed an Productivity that it is capable of: NI got the engineers to do it: Give just give them the time to fix the problems!
Can we please have NI's dedication to fix these easy to fix issues and thereby give back Navigational Control to us, the Developers ?
Please, I do want to continue to impress my clients with what LabView can do, in a short amount of time !
Geir Ove

Answer 1

Most of the "shortcomings" that LV exhibits arise from NI trying to placate people such as yourself who have no idea about how to go about creating a good LV-based application. In terms of specific responses I truly don't know where to begin with your points. To begin with, its clear that despite your years of experience working in other languages you don't know squat about developing in LV. For example, you start with the assumption that using dozens of named variables is a good thing! Did it ever occur to you that if you are having this hard a time with maintaining an application that there might be something fundamentally flawed in your design - no of course not - it's easier to blame the tool.
LV is an ideal environment to develop very large applications - as has been shown time and again. However, you must keep it straight that there is no correlation between complex code and complex functionality. Unfortunately, most people thing there is. They believe that to have complex functionality they need really complex code. As a result they write an incredibly bad implementation of something that is essentially a simple process. Starting from this faulty example they then try to extrapolate what it would take to create a large application and immediately assume that LV is only for "small" projects.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps