Open Standard for Graphical Programming Language?

[LAVA 1.0 Content]

This year LabVIEW has been around for 20 years and still is practically the only graphical programming language on the market. LabVIEW is heavily patented, but the main first patents expire in 2007 which would leave a door open for open standard for graphical programming language. I myself especially would like to see a real object oriented graphical programming language that has been designed for object oriented use right from the beginning.

I think an open standard would benefit everybody, even NI. NI is a pioneer in software data aquistition. Open standard would attract more, maybe even much more, developers to graphical programming languages in general. This would defenitely benefit NI, as it has such a strong foot hold in the graphical programming. NI would propably not loose many of its current customers but would also gain new ones.

Is there a project developing an open standard for graphical programming language? If not, would anybody like to start up such a project.

[didierj]

... still is practically the only graphical programming language on the market...

that's not true, there are (to my knowledge) at least 2 products that use graphical programming:

- Simulink from Mathworks

- Softwire from Control Engineering, see this

...and yes, NI fought heavily on courts to let the two other die:

- where the status in the lawsuit against Mathworks is, I don't know, but Mathworks still sells Simulink and it has a strong community (especially in education and medicine.

- after lawsuits from NI and back from Control Engineering (Softwire), finally NI bought Control Engineering. But I never heard that Softwire is going to be shut down. Softwire is made for Visual C++.

[Guillaume Lessard]

I think an open standard would benefit everybody, even NI.

I do think that NI shot themselves in the foot by never allowing G to become separate from LabVIEW (i.e. a G compiler being standalone, with LabVIEW building on top of it). They effectively didn't allow G to be perceived as a general purpose language by tying it up to to DAQ in people's minds. They condemned it to being a specialty NIche item, and it's probably going to stay that way for a while.

With G as a general-purpose language and generating revenue by itself, we would have had GOOP as a language feature for years already. We would also probably have fast ways to handle data references, rather than the painfully-slow queue-dequeue method we have to use to imitate them.

I'd call that money left on the table. A lot of it.

[JasonKing]

With G as a general-purpose language and generating revenue by itself, we would have had GOOP as a language feature for years already. We would also probably have fast ways to handle data references, rather than the painfully-slow queue-dequeue method we have to use to imitate them.

I'd call that money left on the table. A lot of it.

I am not attempting to step in and represent NI here, as this topic comes up regularly and I'm not qualified to speak for NI anyhow, but how exactly would 'G' be generating revenue on it's own? As far as I understand, compiler makers don't buy a license for C or C++. Nor to the makers of text editors. So who would be paying the money to NI and why? NI makes its money by selling software and hardware. I don't see how having 'G' be independent from LabVIEW or NI would enable greater sales of either of these things.

Am I misunderstanding your comments?

This year LabVIEW has been around for 20 years and still is practically the only graphical programming language on the market.

Do a google search for "graphical programming language -LabVIEW" and you'll see that there are plenty of graphical programming languages out there. LabVIEW/G just happens to be one the most popular. I think that one would have a hard time coming up with a "standard" graphical programming language, just as one would with a standard text-based language. There is a reason so many languages exist - they excel in different situations. A programming language is just a tool and no one tool can be the perfect one for every situation (though the "spork" comes pretty close as far as food consumption is concerned). That's why people use scripting languages for text/file parsing and manipulation but not for large application development. I think it is unrealistic to think any kind of standard could be established.

J

[LAVA 1.0 Content]

A programming language is just a tool and no one tool can be the perfect one for every situation (though the "spork" comes pretty close as far as food consumption is concerned). That's why people use scripting languages for text/file parsing and manipulation but not for large application development. I think it is unrealistic to think any kind of standard could be established.

Exactly! LabVIEW is targeted for measurement and is not very good tool outside this field. However graphical programming is a general paradigm. You could create a high performance graphical language, a web programming graphical language and what ever. The reaseon graphical programming is not more popular is that most programmers are not aware of graphical programming. An why is that. The reason is that LabVIEW is that there is no good general purpose graphical programming language on the market.

[Guillaume Lessard]

I am not attempting to step in and represent NI here, as this topic comes up regularly and I'm not qualified to speak for NI anyhow, but how exactly would 'G' be generating revenue on it's own? As far as I understand, compiler makers don't buy a license for C or C++. Nor to the makers of text editors. So who would be paying the money to NI and why? NI makes its money by selling software and hardware. I don't see how having 'G' be independent from LabVIEW or NI would enable greater sales of either of these things.

Am I misunderstanding your comments?

I'm not talking about making money from a standardized language; there would be no reason to give away the IP for free. I'm talking about making money from selling compilers. In the 90s, compiler makers made money selling compilers... Borland did just that for many years, until they put all their eggs in the wrong place and forced many of their hobbyist customers to look elsewhere. MetroWerks did pretty well until they got snapped up by Motorola.

A more general-purpose graphical programming system (not tied to LabVIEW) might have been able to generate traction and make money. NI could have done that 10 years ago. If it had happened, the language could have evolved much faster! As it is, G is just one feature of LabVIEW, and it gets improved for the sake of LabVIEW -- not for G's own sake. LabVIEW had so much more stuff than just the compiler (and such a large profit margin) that it always was too expensive for "just" programmers, especially the hobbyist kind. Nowadays the business of selling compilers to hobbyists is pretty much extinct, so that boat has been missed.

Graphical programming could have changed the world already. Instead it has pretty much only changed data acquisition, and the rest of the programming world is still trying to figure out how to make their programs multithread.

[Bob Y.]

[snip]

LabVIEW had so much more stuff than just the compiler (and such a large profit margin) that it always was too expensive for "just" programmers, especially the hobbyist kind. Nowadays the business of selling compilers to hobbyists is pretty much extinct, so that boat has been missed.

[snip]

The student edition is still under $100. Anyone who is interested in using LabVIEW for general hobbyist use can use the student edition and have most of the capability of the full package. This is what I recommend to anyone who expresses a non-business interest in LabVIEW. The LabVIEW 8.0 Student Edition is due out any day now. You can order it at Amazon or from NI itself. There is also the Lego NXT system do out late summer. All are great ways for someone to be introduced to Graphical Programming.

Just a thought.

Bob Young

[Guillaume Lessard]

The student edition is still under $100.

<snip>

There is also the Lego NXT system do out late summer.

<snip>

All are great ways for someone to be introduced to Graphical Programming.

"introduced" being the key word here. The next must-have app will not be written in G.

How many programs on shareware.com (or any number of similar sites) were done in a graphical language? Probably not zero, but the proportion is awfully close to that. Any large websites powered by a back-end written in a graphical language? That's zero.

Why is there no truly general-purpose graphical programming tool out there?

Is it really only suitable for niche applications? Really I wonder.

[JasonKing]

Exactly! LabVIEW is targeted for measurement and is not very good tool outside this field. However graphical programming is a general paradigm. You could create a high performance graphical language, a web programming graphical language and what ever. The reaseon graphical programming is not more popular is that most programmers are not aware of graphical programming. An why is that. The reason is that LabVIEW is that there is no good general purpose graphical programming language on the market.

I do agree that "graphical programming" is a general paradigm, just as text-based programming is one. However, what is meant by a high-performance language? What would you consider a high-performance textual language? Does it depend on the power of the exposed APIs? On speed? Memory usage? Efficiency of the compiler and the optimizations it makes? I think we're still talking in unqualified generalizations here. I certainly agree that many programmers are not aware of graphical programming, and many who are quickly write it off as not being "powerful" enough. Very few can articulate what they think is missing, though.

While I agree that LabVIEW is targeted for measurement/automation/data-acquisition, I would argue that it is a very good tool outside of this realm. The language itself isn't necessarily geared towards these applications, but certainly the libraries of functions that ship with LabVIEW target these kinds of applications (analagous to a string-parsing library or the STL libraries that ship with most C++ compilers). This discussion has also been had several times, but I would also argue that LabVIEW/G serves quite well as a general-purpose graphical programming language. Sure, it doesn't currently allow for recursion, but I don't think that undermines my assertion. Some may point out the lack of Objects ala C++ and Java, but C doesn't have such things yet it's considered a general-purpose programming language.

An important fact to note is that not only is LabVIEW/G graphical, but it's also data-flow based. I don't know that this is a necessary characteristic of graphical programming languages. This may be a factor influencing the general adoption of LabVIEW/G.

The next must-have app will not be written in G.

The software environment shipping with LEGO Mindstorms NXT was written in G. Is that a "must-have" app? If you go to "the Good, Bad, and Ugly" presentation given by Greg McKaskle and Christina Rogers at NI Week this year you'll even be able to see the source code.

Graphical programming could have changed the world already. Instead it has pretty much only changed data acquisition, and the rest of the programming world is still trying to figure out how to make their programs multithread.

I have no basis to make or dispute claims about the profitability of the compiler business now or back in the 80s and 90s. I think you raise an important point, though - for NI, the margins and profitability were there for what they were selling. This is pure speculation, but I doubt it made business sense to them to break the language apart from the application - the editing environment, compiler, and all the libraries geared towards test & measurement. If NI had invested the energy and money into that, perhaps LabVIEW wouldn't be the tool that it is today, and wouldn't be as compelling a software tool. Of course we can speculate to no end on this topic.

While I am not a professional LabVIEW user, I personally don't think the value of LabVIEW/G really lies in its graphical nature. I think it is a combination of the built-in libraries, the real-time syntax checking, the performance afforded due to data-flow programming, and the fact that its users can focus on the functionality they are trying to accomplish rather than get bogged down in syntax details. Most of these are not related to the graphical nature of LabVIEW, aside from the benefits gleaned from it being a data-flow language (I haven't thought about it long, but I doubt such a paradigm is possible in a textual language). Another reason users are successful with LabVIEW is the built-in/automatic multithreading. Data-flow makes it relatively easy to detect data dependencies and thus schedule parallel execution in multiple threads, but this would also be possible in a textual programming environment. It just so happens that the LabVIEW compiler does this. It wouldn't naturally be part of any standard specification of a graphical language.

At a very basic level, what is it you all see that makes graphical programming superior to a textual language?

Jason

[Michael Aivaliotis]

The next must-have app will not be written in G.

It just has.

[bsvingen]

I think the data flow paradigm is a main issue. For data logging, control and somewhat also for data analysis, data flow in a graphical language is a good choice because it will simplify the programming by making the language very intuitive and straight forward in relation to what you are trying to do. As a general purpose language i don't see any benefit of the data flow paradigm at all, it only complicates and bog things down since everything is passed by value and there is no way to effectively store data without breaking the data flow.

If G was to become an open standard, i think the first thing that would be scrapped was the data flow paradigm, while leaving only the graphics where execution order is mainly determined by passing of error clusters and references/messages and with a much more effective pointer/reference system. But i dont think this would be beneficial (in intuitive terms) compared with the data flow paradigm for most control and logging applications for which LabVIEW is made and used. For instance, GOOP as implemented in all the different versions i have seen uses passing of references, which is a huge step away from the data flow paradigm in which the G language is built. These GOOP implementation (along with ordinary LV2 style globals) simplify the program structure, but they do so because they step out of the data flow paradigm, and consequently will confuse more than help in cases where data flow will do just fine (although they pinpoint the weakness of the data flow paradigm for general purpose programs).

If G was to be opened, i think it very soon would evolve to a state where it no longer would be intuitive and straight forward to use in most data logging and control application, but would be much better suited for general purpose programming that the case is today.

[Falevoz Y.]

that's not true, there are (to my knowledge) at least 2 products that use graphical programming:

- Simulink from Mathworks

- Softwire from Control Engineering, see this

I know another one... A Labview like : http://www.dasylab.com/

[Rolf Kalbermatter]

I'm not talking about making money from a standardized language; there would be no reason to give away the IP for free. I'm talking about making money from selling compilers. In the 90s, compiler makers made money selling compilers... Borland did just that for many years, until they put all their eggs in the wrong place and forced many of their hobbyist customers to look elsewhere. MetroWerks did pretty well until they got snapped up by Motorola.

I don't think compiler building is the way to make money in the future.

I'm focusing here on C/C++ since that is what I know most and is also by far the most widly used development system to develop applications:

The biggest compiler system (GNU) nowadays is open source and is not something to make money with from itself.

MetroWorks didn't fail because it was bought by Motorola, I rather think they might have failed earlier without. They got quite some business out of supporting just about every Motorola CPU, and their main business supporting Macintosh development would have been probably dwarted by now quite a lot as Apple decided to use GNU C instead of anything else for OS X and considering they used an Open Source kernel that would seem like a smart move to me.

Borland has a track record of making bad decisions at the wrong moment about great products.

Symantec has aside from the starting years never been a company doing products for the user but was only about making money.

Watcom was quite successful but were in a specialized business niche, enabling technologies that got easier to do with the year on just plain MS Windows and now most of what Watcom was is Open Source too.

Leaves only really MS Visual C and Intel C as currently still active commercial compilers. MS Visual C because it is from the makers of MS Windows and Intel C because they know how to tweak the latest ns out of their CPUs.

Basically I think GNU C has over the years made the idea to sell C compilers rather unattractive.

I do not see how it could be in the financial interest by NI to promote a GNU Graphics

If G was to become an open standard, i think the first thing that would be scrapped was the data flow paradigm, while leaving only the graphics where execution order is mainly determined by passing of error clusters and references/messages and with a much more effective pointer/reference system.

Note: G is already taken as a programming language name and not for LabVIEW so I will refrain from using it here.

Dataflow IS LabVIEW. Taking it out of it creates something that is anything but LabVIEW. So I think this settles this.

The biggest power of LabVIEW is dataflow but that creates limitations at the same time such as difficulties or almost impossibilities to create a really object oriented system with inheritence and all this, or generic references to speed up large data access. On the other hand dataflow does allow seemless parallelisation of code execution for users that do not understand anything about multi-threading. This same advantage makes implementation of references in a thread safe manner almost impossible without dwarting the perfomance improvements these references are supposed to bring.

If G was to be opened, i think it very soon would evolve to a state where it no longer would be intuitive and straight forward to use in most data logging and control application, but would be much better suited for general purpose programming that the case is today.

Exactly and in doing so it would be mostly getting useless for what we are doing with it.

I think there is not much of a problem to try to get your own graphical programming environment started then and put it out as Open Source project ;-) if you abtain from using dataflow and a few specific graphical contructs.

I know NI has patented many things but some of them are so general that there is certainly proof of prior art or it is so logical to do that alternatives are not even imaginable. A system to configure hardware resources in a certain graphical representation borrowed from MS Explorer is not something I would consider patentable ;-) Others could be interpreted to patent the idea of an API.

Rolf Kalbermatter

[LAVA 1.0 Content]

I don't think LabVIEW "G" should be made an open standard. Why? Because we already have a good implementation of a development environment. The thing is that no single development environment or programming language never can cover all the programming problems. The general purpose programming languages like C, C++ and Java are quite close to how wide an audience a single programming language can reach.

What would be needed instead of open G is another open graphical language which would bring forward the graphical programming itself. I don't even mean graphical dataflow programming but graphical programming. It may be dataflow or it may not. It would depend on the desing targets that would be set to this general purpose language. Objects oriented programming language must include references to objects, which is not dataflow, but this doesn't mean that dataflow couldn't also exist for problems where it suits better. The best way to achieve this goal would be to standardize a general purpose graphical programming language. Then perhaps try to build an open source reference implementation of the core features of the language. As an open language, the language could be marketed to software companies building software development environments.

If this language would succeed we would see more graphical programming languages to appear.

[zen]

As a general purpose language i don't see any benefit of the data flow paradigm at all, it only complicates and bog things down since everything is passed by value and there is no way to effectively store data without breaking the data flow.

I think functional programming languages have similar approach.

I remember a homework assignment in school; implement tick-tack-toe in Prolog. My (and probably my classmates') implementation was "passing current matrix to a function that returns next matrix". You do not declare variables in such implementation.

LabVIEW is not Prolog. LabVIEW is not Scheme, LISP, Haskell. But passing values or references to a function and get the results without explicitly specifying procedure seems functional programming to me.

Also, I like how LabVIEW RTE implements multithreading. It actually hides threads from users.

We probably should talk at Lightweight Language conference to get feedback from functinal programmers .

http://ll4.csail.mit.edu/

[LAVA 1.0 Content]

I think functional programming languages have similar approach.

Good idea Zen! I would very much like to see a graphical functional programming language. There are a few things that make LabVIEW a bit like functional languages. First is that the value of wires is not changed (in most of the cases). Second is that the language is automatically concurrent.

I think there are however much more differences in LabVIEW and functional programming languages and LabVIEW is not (even close to) a functional language. Let's imagine a functional programming language called "Functional G". This hypothetical language would differ from LabVIEW at least in the following properties:

1. In functional G wires would pass expressions (the history of the wire), not only values
   
2. In functional G, the VIs would always be re-entrant and stateless
   
3. In functional G, shift registers would not maintain their valus (at least VIs with shift registers would not)
   
4. In functional G, there would not be globals or other joint variables of if there were, these would be constant after referenced the first time
   
5. In functional G, VIs could be passed to and returned from other VIs as parameters with and without parameters
   
6. In functional G, sequences of code could be passed to and returned from other VIs
   
7. In functional G there could be a way to do currying i.e. to define new functions based on old ones like cos(x)=sin(pi/2-x)
   
8. Functional G would possibly allow lazy evaluation, i.e. a wire and it's history could be evaluated as late as possible.
   
9. Functional G would allow storing "continuation" i.e. the state of the execution i.e. a VI to be called next with all of arguments to be passed to it
   
10. Functional G would have a feature called "pattern matching" similar to polymorphic VIs except that a different VI would be called not based on type but value passed to the "pattern matching polymorphic VI".
    

I think a best compromise of a new language would be a programming language that would allow pure functional programming, but would also allow many non-pure properties. This kind of language would allow building very stable and highly concurrent functional programs but also would allow accessing non-functional resources such as files and measurement devices which defenitely have a state.

If you are not familiar with functional programming, see Functional Programming And The Rest of Us.

[Guillaume Lessard]

I don't think compiler building is the way to make money in the future.

"Nowadays the business of selling compilers [...] is pretty much extinct, so that boat has been missed."

10 years ago, however, there might have been a chance!

Dataflow IS LabVIEW. Taking it out of it creates something that is anything but LabVIEW.

I agree. There are a few non-dataflow "graphical programming" tools out there, and I think the reason they don't have much of a following is that graphical programming without dataflow is not a good marriage. I speculate that the same may explain the low acceptance of dataflow text languages. Dataflow and graphs? Obviously good.

However, it's proprietary and will be for years to come.

The proprietor has a somewhat limited view of the usefulness of its product, resulting in a comparatively tiny user base: compare and contrast LabVIEW with Java in terms of number of deployed apps. Hmmm. Java is proprietary too, but they made a huge effort to push it everywhere. It wasn't different enough to really change the world, so it didn't. It's still everywhere, though!

I guess that's the source of my disappointment: NI did not try to change the whole world. They just successfully changed DAQ. Has this lack of ambition doomed graphical programming to remain a fringe phenomenon?

[crelf]

I guess that's the source of my disappointment: NI did not try to change the whole world. They just successfully changed DAQ. Has this lack of ambition doomed graphical programming to remain a fringe phenomenon?

I agree that NI changed DAQ, but just look at the huuuuge advancedments in LabVIEW in the last 3 versions! Sure, I was a big fan of 5.1.1 back in the day, but now I can't live without my project explorer. I think that this arguement is more about whether LabVIEW is a general purpose programming language, not whether NI is trying to change the world.

Also, just because NI "successfully changed DAQ" doesn't mean that they have a lack of ambition - I find it offensive to call the fantastic strides NI has made as a "lack of ambition". Sure, they may not have a world domination attitude, but they're certainly not unambitious - you've got to give them that...

[JasonKing]

I guess that's the source of my disappointment: NI did not try to change the whole world. They just successfully changed DAQ. Has this lack of ambition doomed graphical programming to remain a fringe phenomenon?

Guillaume, how is it you see that LabVIEW has(or had) the potential to change the world in a way that JAVA doesn't? I think this is a core element of your position that I do not understand.

J

[LAVA 1.0 Content]

How is it you see that LabVIEW has(or had) the potential to change the world in a way that JAVA doesn't? I think this is a core element of your position that I do not understand.

Should we open another topic for possible alternative pasts and futures of National Instruments and LabVIEW in the case some other decissions were made. I suggest that we try to discuss if there is need and space for a new general purpose graphical programming language, and if there is what should it be like.

[Guillaume Lessard]

Guillaume, how is it you see that LabVIEW has(or had) the potential to change the world in a way that JAVA doesn't? I think this is a core element of your position that I do not understand.

J

Do I know that LabVIEW's approach could actually change the world (of programming)? No.

I do think that it has the most potential of any language I know...

The language and the engine of LabVIEW have always been part of a high-priced, targeted application, it has never been appealing for non-DAQ people to try it. As a consequence, its graph-dataflow system has effectively been shielded from widespread use.

Java didn't change the world because in the end it wasn't much more than what it sought to replace. The VM did a whole lot more world changing than java itself did. However, Java got an extremely ambitious treatment from Sun and, as a result, gained a big foothold without being particularly revolutionary.

Some ideas deserve enormous ambition. I happen to think that, in the past, NI has not had enough ambition for LV's language. I'm not necessarily right, but is any of this not clearly opinion and speculation?

Sure, they may not have a world domination attitude, but they're certainly not unambitious - you've got to give them that...

I certainly do not mean "unambitious". I would agree they've been "very ambitious", which is less ambitious than "insanely ambitious". It's all a matter of degrees! I'm sure my argument would go over much better around a table and beverages...

[Chris Davis]

After reading these posts, I was thinking that NI did a post that tried to answer some of the questions. I can't seem to find it right now, but I remember that they had the paper when they started the LabView Zone. Anyway, it basically stated that you could use LabView as a general purpose language, and that NI always kept that in mind when it wrote LabView, but they also recognize that they make money on the hardware that they sell and integrate into LabView.

[crelf]

After reading these posts, I was thinking that NI did a post that tried to answer some of the questions.

:arrow: The article you're looking for was written by Jeff Kodosky, and is archived here.

[LAVA 1.0 Content]

:arrow: The article you're looking for was written by Jeff Kodosky, and is archived here.

Thanks for the link crelf! A nice article. I think Kodosky made some good points. However, from our point of view and from this discussion point of view he asks the wrong question. The question is not if LabVIEW can be used to solve general purpose programming problems. It certainly can. The more important question is if LabVIEW is by desing the best possible graphical programming environment to solve general purpose programming problems. I think the answer to this question is no, it is not. LabVIEW is very good indeed. However it's not that good in many tasks and I have been forced to use other programming languages to solve some of my task just because it would be much too complicated to solve these issues using LabVIEW. I think there is still room for a graphical programming language better than LabVIEW.

What I'll do today, I'll read more about functional programming to see if functional programming could be implemented in a graphical dataflow kind of way.

[Chris Davis]

:arrow: The article you're looking for was written by Jeff Kodosky, and is archived here.

Thanks, that was the post I was looking for... :worship: