Improved interface for OO programming

[Synaesthete]

As I continue to use LVOOP in my LabVIEW code, I'm beginning to question the value of the graphical programming concept as a whole.  I think that it's a very interesting concept for non-programmers and for educational or entertainment purposes.  When it comes to professional hardware integration and product development, I feel the graphical environment becomes a hindrance.  I understand that LabVIEW is a powerful programming tool and can cut down on the time to build a product.  What I question is whether this is due to the graphical programming environment, or due to the plethora of reusable functions NI has provided that are useful for hardware integration.

What I propose is to provide a text-based, object-oriented programming environment, perhaps a flavor of C++ or Java, such that applications could be optionally written and compiled in Eclipse or Visual Studio.  I understand CVI/LabWindows is similar, but I feel it's not as full-featured an environment as other text-based IDEs.

An even more clever environment might allow for both text-based and graphical programming to be used simultaneously wherever they are the most appropriate (e.g., Keep the "front panel" as it is and allow for a graphical representation of data flow and code parallelism)

I feel that providing such an environment will also invite more programmers to the National Instruments community.  Unfortunately, this might hurt the traditional LV developers who have benefitted from a scarcity of professionals who work with such an esoteric programming language.  In the long run, I think that it would be a good direction to go for the overall health of the community and the betterment of the craft.

[SteenSchmidt]

"An even more clever environment might allow for both text-based and graphical programming to be used simultaneously wherever they are the most appropriate (e.g., Keep the "front panel" as it is and allow for a graphical representation of data flow and code parallelism"

But the above is LabVIEW . You are free to include text-based pieces of code within your VI. Just use a C-in node or some of the other external nodes.

I have programmed in Basic, VB, C, C++, Java, several specialized embedded languages as well as numerous markup-type languages. And nowhere I've seen the same level of code overview as in LabVIEW. The graphical representation and data flow paradigm is a very convenient way to represent software. Much easier (for me) to comprehend the full picture of than thousands of lines of textual code - no matter the level of syntax highlighting. And I have no problem implementing the same algorithms in LabVIEW as I would in C++ for instance. There are weaknesses and strengths, as there will be in any comparison between two programming languages, but I don't see the graphical representation as a weakness.

Cheers,

Steen

[Synaesthete]

I certainly feel that there is value in using a graphical programming environment in some circumstances.  Two parallel loops, say a DAQ loop and File IO loop, would certainly be tough to visualize in a text-based programming language.

Also, I'm not really discussing the difference between using a series of text-based commands vs. a series of VI calls.  I'm talking about the difference between the entire LabVIEW IDE vs. a full-featured text-based IDE for full-fledged Object Oriented programming, not just algorithmic programming.  In other IDEs such as Visual Studio, there are graphical aids to programming--class hierarchy diagrams, etc.

The hindrance I feel comes in to play for large, professional applications delivered to customers.  These are situations where the customer is requesting a full-featured application.  They're interested in using NI Hardware, and have been sold on the use of LabVIEW to deliver the application.

Obviously there have been challenges to the use of LabVIEW to develop complex, fully-featured applications, and most developers would agree that LabVIEW should not be used to "rewrite Microsoft Word", for instance.  But what if this is what the customer wants?  What if they want something on the scale of Microsoft Word that also utilizes NI Hardware, and they've come to a LabVIEW developer.  The developer certainly isn't going to turn down a paying customer, so now they're faced with delivering.

The response to this common occurence has been to expand LabVIEW, adding Object Oriented concepts, etc. to provde a better environment for developing large-scale applications.  As the scope of the use of LabVIEW grows, there is constant effort to add new features to help improve the efficiency of graphical programming and help develop larger software architectures with LabVIEW.

This effort confuses me because already text-based IDEs have a proven track-record when it comes to large application development and OO programming.  Typing is pretty fast when it comes to writing code, and cuts out the overhead of wiring, creating custom icons, resizing structures, opening up dozens of windows, creating front panels for functions that don't require a GUI, etc.  These activities become excessively tedious when developing large applications, and I start to care less about the "coolness" of graphical programming when I'm trying to put bread on the table and satisfy a customer's needs.

[Intaris]

"for full-fledged Object Oriented programming"

Please outline what you think would be better accomplished with a text editor than the current LV tools for this.....

[Synaesthete]

^ pending...

[Synaesthete]

Here's a trimmed down version of how you might acquire some data in a text-based fashion using Java:

Note: myNumeric and btnStop are front panel controls/indicators that could be placed on a front panel just like LabVIEW at present

import ni.math.statistics.*;

public static void main() {
	NI_DAQ ni9205 = new NI_DAQ();
	
	ni9205.Initialize();

	do {
		myNumeric.value = mean(ni9205.Acquire());
	} while btnStop = False;
}

abstract class Hardware() {
	public abstract boolean Initialize() {}  // Override to set up hardware device
	public abstract	double[] Acquire() {}	// Override to get data from device
}

class NI_DAQ extends Hardware() {
	boolean Initialize() {
	...
	}

	boolean Acquire() {
	...
	}
}

class KeithleyDMM extends Hardware() {
	boolean Initialize() {
	...
	}

	boolean Acquire() {
	...
	}
}

Just to create this framework in LabVIEW would require creating several VI files, cleaning up front panels, opening and editing icons that have limited expressive abilities on the block diagram, messing with the connector pane, drawing and resizing several structures, wiring up VIs and performing various minor aesthetic tweaks, opening up the VI settings window and going to the Documentation section to write a comment, etc.

Additionally, if you had a requirement of setting a dozen or so properties for various classes and front panel objects, each of these could be a line of code as opposed to a sprawling series of Property nodes.

Writing the above code would be very quick, especially with the ability to import reusable classes and packages.  Most IDEs also provide autocomplete functionality on-the-fly (to get the same in LabVIEW for a class, you'd have to create a custom palette).

For myself and many other programmers, text-based object-oriented programming provides a very clean, efficient means of churning out code without the overhead of unnecessary graphical elements.  The graphical interface of LabVIEW certainly has advantages in some areas, but when the applications are large and include a multitude of classes, text-based programming seems more efficient.

I would love to have the option of working with a text-based OO IDE that works seemlessly with NI products.

[AristosQueue (NI)]

> and most developers would agree that LabVIEW should not be used to "rewrite Microsoft Word", for instance

Ah, I enjoy being in the minority. I certainly would use LV for large endevors like that one.

Having said that, I've actually been interested in the question of a "textual generator for graphical code" for a while now. In my experience, the graphical code is easier to read than the text code, but in some situations, text may be faster for writing code. Quick Drop renewed my interest in this approach, as it started using the keyboard more heavily to generate the block diagram. Some sort of declarative model in order to quickly generate VI panels/conpanes and class containers might be useful.

[Synaesthete]

I've found that reading text-based code is an acquired skill that is particularly enjoyable.  It's related to the way our minds process reading.  People who develop the ability to "speed read" use these mind tricks to help them get more data in to their heads.  They scan through the text for visual cues, and they take advantage of the imaging parts of their brain to generate a scene.  Speed readers can "see" the page.

In the same sense, experienced text-based programmers are constantly creating little images in their heads.  These images are often abstract and animated.  There are visions of loops, hierarchies, or maybe jack & jill passing buckets of data up-and-down-a-hill.

When text-based programming is object-oriented, these images start to become especially expressive.  It's one of the reasons object-oriented programming is so successful.  It's easy for a person to imagine some abstract thing that has a set of characteristics (properties) and does a certain set of actions (methods, events).

It is the job of the object-oriented programmer to create new sets of objects to solve problems.  With these new objects comes their respective mental representations.

Since using object-oriented programming in LabVIEW, I'm finding that the native graphical environment supercedes my mental graphical environment, and I have a more difficult time imagining the object as I see fit.  I'm constantly attempting to keep my code clean by following strict style guidelines in order to minimize the graphical distraction as much as possible.  It suddenly occurred to me that with text-based OO programming, none of that was necessary.  I don't need to use clever tools to help manage my graphical code, as my brain just naturally does it for me.  So, I thought about switching, but there's little alternative if I'm going to continue to be a member of the National Instruments community.  I would dearly prefer to have a nice tool that works more with the way my brain works, as well as a million+ others who are the same.

Sorry for the lengthy post!  Really more of a philosophical discussion at this point I suppose.

[Synaesthete]

Is there any chance of LabWindows moving this direction?  I guess it could be called "C++VI"

[Synaesthete]

OK I think I know what I want...

If I could use a traditional OO-based IDE and call VIs as functions, that would do it.  I feel that on an "object" level, I'm more comfortable with a text-based approach.  When it comes to some algorithms, loops, or state machines, I'm often happier with the LabVIEW graphical approach.  Imagine if I had a line of code, say:

Object.DoComplexIterativeArrayThing

And if I double-clicked on this method, it might open up a LabVIEW VI with a for loop, shift registers, etc.

And vice-versa, you could double-click on a LV-style property or method node and it takes you to the respective call in code.

In cases where a block diagram could be converted to code or code to a block diagram, these views could be interchangeable (but impossible or unnecessary in other cases).

I really believe that it's possible to combine advanced object-oriented text and graphical code seamlessly inside a single IDE, with much tighter integration than external code calling nodes, etc. so that the fluidity of programming isn't interrupted.  For those of us with strength in both styles of code, we'd be able to use the 'right' tool for the 'right' task with no sacrifices.

Many of the problems-and-solutions I see in this idea exchange could be solved with this one sweeping change.  Rather than try to continuously create new schemes and tools for managing increasingly complex graphical code, let much of this code shift in to the text-based language.  Focus more on reducing and crystallizing the graphical elements of LabVIEW that are of the most use for visualizing complex problems.  Make the art of LabVIEW more of a science.

[Darren]

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.