Gee Language

"G" is the GraphicalProgrammingLanguage used in LabView. It is based on DataflowProgramming (or FlowBasedProgramming, although invented independently).

Really? The 2003 Labview User Manual http://www.ni.com/pdf/manuals/320999e.pdf says, in Chapter 1,

: LabVIEW is a graphical programming language that uses icons instead of lines of text to create applications. In contrast to text-based programming languages, where instructions determine program execution, LabVIEW uses dataflow programming, where the flow of data determines execution.

There is no mention of a "G" language anywhere in the Glossary or Index.

Yes, really. See <http://zone.ni.com/devzone/nidzgloss.nsf/webmain/1097CE3D8B53FBA98625686A00794011> and <http://www.openg.org>. Also, it's useful to distinguish the LabView environment and the G language.

Moved from PrographLanguage:

I've been a fan of GraphicalProgrammingLanguages since the 1970s. On the other hand, none of them so far has been a SilverBullet. GeeLanguage/LabView is one of the most famous successful ones, but it is a DomainSpecificLanguage.

Actually there's nothing about the G language itself that is domain-specific. The LabView components are domain-specific (mainly data acquisition and control), of course, but the programming model isn't.

Hmm. But that's the only domain where it's been successfully and nontrivially used, I believe. I've never heard of a single person raving about how great it is for general use. Correct me if I'm wrong.

GeeLanguage has been my primary programming language for eight years. I began using it in grad school as a physics lab teaching assistant, and for the past seven years, I have been employed as an engineer using LabView in industry. I have recently used LabView to create a program that builds icon files from bitmap images, a program that creates and verifies MD5 hashes, a program that creates images for a web page, and a program that translates the InternationalPhoneticAlphabet? into other phonetic code forms. The G language isnt domain specific, but LabView is limited by the narrow mindedness (maybe stupidity) of National Instruments. A few examples of this should suffice:

GeeLanguage has native support for global variables, but not for user defined global constants. (Bad programming style)
LabView doesn't have native object support. The virtual instrument encapsulates data structures into a front panel, but each front panel can only have a single block diagram associated with it. Therefore, the virtual instrument is analogous to an object with multiple properties and a single method. (Unthinkable by todays standards)
LabView executables require the LabView run-time engine to function. The runtime engine is analogous to the JavaVirtualMachine, but unlike the virtual machine, the LabView runtime engine isn't cross platform. Therefore, a LabView executable must be recompiled for each OperatingSystem. (Inferior to Java.)
The LabView runtime engine only supports the most recent versions of MicrosoftWindows, MacOs, MacOsx, and LinuxOs. There is no support for the vast multitude of other operating systems, including OpenSource and RealTimeOperatingSystem options available today. (Inferior to JavaVirtualMachine.)

In my opinion, LabView was developed by engineers to mimic the schematic diagrams that engineers are most comfortable with. Unfortunately, the developers at National Instruments never got beyond the engineer mind set to create a true programming language. The G language isn't domain specific, but National Instruments is.

I agree with the above points. 'G' is quick and easy for general programming. But it is geared towards instrument IO and control. If it didn't require a gigantic runtime, was cross-platform, and was free, I would use it for everything. As you know, after using labview, programming in C++, or Java, is like taking a step backwards, It's like using punch cards to write a GUI.

I'm currently recovering from having programmed in LabView for about half a year. Though the concepts behind LabView are fairly interesting (DataflowProgramming, ConcurrentProgramming), its execution is so mediocre it makes CobolLanguage blush. For example, there is no support for recursion (unless you count reopening the current VI for re-entrant excution, but that's not exactly clear is it?).

For the people interested in how it "looks", here is a small program that calculates a Fibonacci-sequence:

http://web.archive.org/web/20070222082851/web.irdc.nl/wouter/2005/labview_fibonacci%2epng

[ Translation of the Dutch labels: "Iteraties" = iterations, "Resultaat" = result ]

-- WouterCoene DeleteWhenCooked

I used Labview to implement a massive suffix array indexer and various other things. It's not unusable for general programming, but I had some complaints about it:

Clicking through menus to get a block for "add" is slower than typing +.
The block icons are often less clear than a short string.
Labview works really badly with other programming languages.
SubVIs (the equivalent of function calls) are really cumbersome, each requiring a new file among other things.
Being 2 dimensional means you end up spending time moving things around and adjusting connections. If you don't (and some don't!) you can take "spaghetti code" to a new level - actually looking like spaghetti!
Sometimes, icons just don't work the way everything you can see says they should, and you have to rebuild something another way.
The interface, while convenient for quick things, is very fixed.

Think that's harsh? Better keep me away from the Java and C++ pages...

CategoryProgrammingLanguage CategoryControlSystemsSoftware