Jump to content

Will G ever be considered a general purpose language?


Recommended Posts

At the risk of inciting controversy or being redundant to other threads in the past, I am wondering how many people feel that LabVIEW should change its image with regards to the programming language G?

I grow weary of constantly having to explain to people what 'LabVIEW' is. Most seem to think of it as an application, like Excel, that interfaces to other 'real' code. I have a hard time convincing them it is just the development environment for writing programs in the G language.

I also am tired of having all of the applications I create generically referred to as 'LabVIEW'. Often, co-workers will say "this is where our C code is called by LabVIEW" and I want to correct them and say, "no, this is where you C code is called by the test system, that just happens to be written in G. It could have been written in any language and LabVIEW has nothing to do with it." The reason this bugs me is they try to blame errors in their interface on LabVIEW. Lack of understanding breeds fear and contempt.

And NI is not helping matters. I really think it is time they stop calling it LabVIEW. Or, at the very least, make a separate version that is strictly for G programming and have all the HW specific stuff be an add-on called LabVIEW. I mean, how many of us do anything that has to do with a Lab anymore? LabVIEW has left the lab and is out in the world doing everything, everywhere. It needs to be rebranded if it wants to get wider acceptance.

So, here are my crazy ideas:

Call the dev environment something other than LabVIEW (G-View?, DataFlow Studio?)

Make a stronger effort to call the language G and not LabVIEW.

Change the name of VIs to something else. They are not virtual instruments, they are user interfaces, sub routines, functions, etc... And change the file extension to .g

Make the point that any application can be written in G. And if that is not true, then work to add features to make it true. I know more and more of the features of each release are written in G. Why not work towards going all the way and have the G compiler written in G! That is one definition of a true programming language that a lot of CS people use. NI should strive to reach that goal.

Well, that is enough ranting for now. I feel better already. I suppose if no one agrees, then this thread will die quickly and I will get back to work. But, I do hope there are others out there who long to be understood by their co-workers and employers as true software developers.

-John

Link to comment

I see your point, and I particularly like your idea about ending the file names in .g, but I'm not going to hold my breath waiting for changes. I was having a similar conversation with our local NI manager and ASTDan the other day after a user group meeting. I see the distinction between LabVIEW and G, but I think that it is a distinction with little meaning. As long as G is proprietary to NI, and as long as the only way to program in G is to use LabVIEW, then the two will be synonymous. Now, if G was an open source language and you had choices like LabVIEW G, ANSI G, Borland G etc. then it would be different. Or maybe if it wasn't open source, but you had different flavors of G like G, G++, G# then it would make sense. But right now G=LabVIEW for me, and distinguishing between the two isn't worth the effort.

Link to comment

QUOTE (jlokanis @ Aug 22 2008, 01:44 PM)

At the risk of inciting controversy or being redundant to other threads in the past, I am wondering how many people feel that LabVIEW should change its image with regards to the programming language G?

...

-John

Remember, NI has to worry about MS (think Netscape). It is a good strategic move to not make it appear like MS is threatened by LV.

Ben

Link to comment

QUOTE (jlokanis @ Aug 22 2008, 01:44 PM)

Make a stronger effort to call the language G and not LabVIEW.

I'm short on time at the moment, so I'll leave all my comments for others to make, but here's some history behind why that one whon't happen: the language is not called "G" - that's trademarked by another language that is actually truly called "G". Code written in LabVIEW is often referred to as "G" code, but that's because people are abbreviating "Graphical", not because "G" is the name of the language.

Link to comment

I had a similar argument recently. I supply many scientists with LV applications and the thing they keep asking is: Why does it take an 800MB installer file for a 120KB executable? (I usually install the latest MAX, DAQmx, etc. drivers whenever there's a new LV release)

Well, the difference really with C/VB is that the runtime engine is not included with Windows, Mac O/S nor Linux. I stopped the protests when I compared LabVIEW programs installation with OpenOffice which requires the latest Java Runtime or with C/VB programs requiring the latest .NET package not previously installed.

As for a "real" programming language... If we consider ourselves real software developers and are recognized as such by our peers, than isn't it enough?

Link to comment

There's an interesting article on the NI Developers Zone about this - http://zone.ni.com/devzone/cda/tut/p/id/5313

"If tool A and tool B can be used for a certain set of tasks, but tool B has more functionality that makes it useful for additional tasks, which tool is really the more general one? This is precisely where we are with LabVIEW. LabVIEW¹s suitability for measurement and automation applications comes about not because its fundamental programming abilities are restricted in some way, but because they are enhanced and extended."

Link to comment

QUOTE (jcarmody @ Aug 23 2008, 02:43 AM)

There's an interesting article on the NI Developers Zone about this - http://zone.ni.com/devzone/cda/tut/p/id/5313

"If tool A and tool B can be used for a certain set of tasks, but tool B has more functionality that makes it useful for additional tasks, which tool is really the more general one? This is precisely where we are with LabVIEW. LabVIEW¹s suitability for measurement and automation applications comes about not because its fundamental programming abilities are restricted in some way, but because they are enhanced and extended."

Yes, that's clear. And at the risk of further inflaming the discussion, these kinds of issues are really "religious identity" issues. They are never decided based on rational inquiry but on the basis of the lived commitments of those who engage in the discussions/arguments. Those who grew up in the "house of holy text-based" programming will continue to see that kind of programming environment as what's "real and true" and will validate the rest of their experience based on that history. Seen from that perspective it is almost inevitable that LV will be seen as being a "toy", only good for "tests and measurements", only good for "laboratories" or whatever other rationalization can be "hung on" the LV IDE. The ability to integrate virtually any other text-based language, the ability to code in a consistent manner across deployed environments, the ability to not HAVE TO acquire numerous third party libraries to "link in", etc, etc will all be dismissed, if they are even acknowledged. Add in the fact of how easy it is for someone to actually program in LV -- esp those who have NO background in CS -- and you've got all the ingredients for a "religious war" over who is the "real" programmer" and what is a "real" programming language.

Yes, I agree that from a pure CS perspective, LV is not a complete language. G is not entirely written in G, etc. Yes, of course, those are valid points and perhaps at some point in the future that will change. NI will choose to devote the considerable resources it would take to implement ALL of G/LV in G itself. But, even if that were to happen, it would make NO difference to the religious identity issue. If anything, it would only serve to intensify it because it would take away one of the seemingly "rational" reasons to say that LV isn't "complete".

Yes, NI could potentially make a difference by renaming the language but that's just another version of the same identity issue. BASIC never was "basic" -- it never way "All Purpose". It had limitations and, when it become "Visual" it was still not "All Purpose". Now people refer to it as VB and don't even consider those nuances -- esp those who "grew up" in that environment and are now committed to it simply by virtue of their lived history of use of it. LabVIEW could simply become known as "LV" (perhaps for "Less Verbiage"??) but those renaming issues STILL won't address the core issue.

It's all about what programmers "grew up" with and what they were educated to believe that "real" programmers do, and what a "real" programming language is. LV subverts most of that and does it in a way that allows non-CSers to literally "compete" with the end products produced by CSers. That's the final and fundamental aspect of the "religious identity" issue. LV by its very nature, ease of use, and general abilities, seems to "take away" and/or "diminish" the uniqueness of having a CS background. It isn't arcane but intuitive -- unless you've been taught to believe that malloc() etc is "intuitive". It's easy to use -- I taught my 8 year old to program in it and she could produce -- back then -- running programs after very simple instruction. And all of that makes LV appear to be a serious threat to those who have lived commitments to their hard earned identities as "real text-based programmers".

OK, end of rant and now it's time for me to step of that soapbox... :rolleyes:

Link to comment

QUOTE (crelf @ Aug 22 2008, 09:02 PM)

I won't go into this discussion either, but just to comment on this point: http://forums.lavag.org/A-Blast-From-The-Past-t729.html' target="_blank">This article from 1986 makes repeated reference to the language behind LV as "G". I have the "G programming reference manual" (for LV and BridgeVIEW) from 1999, which also refers to the language as G, so at least NI thought about it that way. It's possible that this was stopped due to copyright issues.

Link to comment

I've been thinking about that "real programmers" thing. One of the great things about LabVIEW, IMO, is that it doesn't have that "programmers culture". Most LabVIEW programmers are engineers and scientists who use LabVIEW to do things, not CS types who argue about the purity of the language.

But this also has its drawbacks. Because most of us are not CS types, we also don't have a background in things like programming style and programming best practices. That's why I think certification is important. Taking the certification training fills in the gaps. It teaches you about good style and good practices (documentation, source control, etc.) without creating a "computer-snob" culture to go with it.

Link to comment

QUOTE (Yair @ Aug 25 2008, 10:41 AM)

I won't go into this discussion either, but just to comment on this point: http://forums.lavag.org/A-Blast-From-The-Past-t729.html' target="_blank">This article from 1986 makes repeated reference to the language behind LV as "G". I have the "G programming reference manual" (for LV and BridgeVIEW) from 1999, which also refers to the language as G, so at least NI thought about it that way. It's possible that this was stopped due to copyright issues.

It is my understanding as well FWIW that NI stopped the reference to "G" because of copyright infringement concerns, however those were generated/recognized within NI.

Link to comment

QUOTE (Norm Kirchner @ Aug 25 2008, 12:50 PM)

I can tell you this.... Jeff Kodosky refers to the language as G.

I'm sticking with him.

Yes, I understand that, however, he's also a Mac user and wants to have all of the same functionality in the Mac version as in the Windows version (and yes the other platforms as well). At this point, I'm not holding my breath. :headbang:

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.