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:

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:

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


CategoryProgrammingLanguage CategoryControlSystemsSoftware

EditText of this page (last edited April 13, 2012) or FindPage with title or text search