Open Standard for Graphical Programming Language?

[crelf]

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

You're welcome - that's what I'm here for :laugh:

[Guillaume Lessard]

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.

Exactly! I'm convinced that LabVIEW would be better and more accepted if the language had been developed for its own sake, but the money in that just wasn't obvious enough. Oh well.

Jimi, on the topic of functional programming:

I think that functional programming tends to be barely readable enough in the standard 1D-representation of text.

I can't quite imagine how that could be represented in 2D without making it an utter and complete mess... do you have something in mind?

[Mike Ashe]

... 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.

NI has always made most of their revenue and profit on the hardware. They started out making GPIB cards and the hardware sales funded the development of LabVIEW.

... 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. ...

Actually, Jeff was not asking a question, he was answering the question, which was being debated rather vigorously prior to his article. I agree with his summation that LabVIEW is more than most GP languages, the marriage of the dataflow paradigm with a graphical syntax makes it inherently better than most other languages and makes it's potential way better.

At the same time however, it has been kept below it's potential, with a consistency that cannot be an accident. I have asked various people at NI and several ex-NI people, "why?" over the years and have received a variety of answers, several of which were:

- no answer, they just would not answer

- lack of support resources, if they made it more GP they would have to support

some database investment banker on Wall Street. They didn't know banking, but

they did know DAQ. Stick to what you know.

- limit LabVIEW to limit hardware competition's ability to quickly drive their HW

- Staying under Microsoft's radar. If LabVIEW dropped in price, increased in GP

ability and seriously started to crimp into Visual C<> sales it might attract

unwelcome attention. NI has turned into the 800 lb gorilla in their field, but

MS is Godzilla

- Instead of trying to be all things to all people, great successes often find a niche

where the state of the art is open in the field. They pour all their resources into

being the best in their chosen field. NI did that, both technically and with their

business model/methods. I have never heard any of them express any regrets

on this aspect of NI & LabVIEW.

It will be interesting to see if anyone steps up to the plate and tries to create a LabVIEW clone (open "G") (or closed for that matter) next year and after. It will also be interesting to see what NI's response would be.

[didierj]

It will also be interesting to see what NI's response would be.

Most probably you'll first have some lawyer at your door, followed a few month later by a salesman with an offer to buy your company...

[zen]

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:

If functional G has lambda structure, we probably could solve 1, 5, 6 and 7. Lambda expression seems attractive to functional programmers. Although I am not into functional programming much, I sometimes wish LabVIEW had lambda.

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.

The compromise that functional G allows non-functional feature sounds great to me. Some popular language such as Python have both functional and non-functional features.

[Mike Ashe]

Most probably you'll first have some lawyer at your door, followed a few month later by a salesman with an offer to buy your company...

I would agree, as long as we change "you'll" to "they'll" since we are talking about someone else. I certainly am not going to try this, way way too much work. LabVIEW probably has several hundred person-years invested in it's development by now.

[bhavnesh]

There is one more graphical language that I know of that the previous posts by Falevoz and Citation did not include..

Agilent VEE link to VEE is another graphical programming language specifically made for test automation/measurement by Agilent who is a much bigger gorilla than NI in instrumentation. However even though its been around just as long as LabVIEW has been, its not anywhere near LabVIEW in terms of popularity ! coz most of what VEE can support is Agilent and old HP instrumentation, NI on the other hand took LabView and really try to expand its horizons with the multitude of toolkits as well as built in functions.

[Mike Ashe]

There is one more graphical language that I know of that the previous posts by Falevoz and Citation did not include..

Agilent VEE link to VEE is another graphical programming language specifically made for test automation/measurement by Agilent who is a much bigger gorilla than NI in instrumentation. However even though its been around just as long as LabVIEW has been, its not anywhere near LabVIEW in terms of popularity ! coz most of what VEE can support is Agilent and old HP instrumentation, NI on the other hand took LabView and really try to expand its horizons with the multitude of toolkits as well as built in functions.

Lots of us here are familiar with or have used VEE. It is okay, but isn't a general purpose language. Although LabVIEW is mostly used in test & measurement, it is also a GP language. VEE was hampered in it's implementationa nd graphical syntax by the patents on the basic G language. It has never measured up to LabVIEW. (pun intended)

[RagingGoblin]

Got this from wikipedia

http://en.wikipedia.org/wiki/Category:Visu...mming_languages

piet looks fun

[didierj]

Got this from wikipedia

http://en.wikipedia.org/wiki/Category:Visu...mming_languages

piet looks fun

I like the Lava programming language...

[Yair]

I was browsing SourceForge and I happened to run into this current project.

Does anyone know any of the guys on that project?

I didn't recognize any of the names, and was wondering whether some people here would like to help them.

[Grampa_of_Oliva_n_Eden]

Lots of us here are familiar with or have used VEE. ...

Dennis Knutson (the 9000+ poster on the NI Exchange) used to develop LV for HP and his office was just around the corner from the HP VEE group.

I think Dennis being who he is says a lot for LV.

Ben

[Jim Kring]

I was browsing SourceForge and I happened to run into this current project.

Does anyone know any of the guys on that project?

I didn't recognize any of the names, and was wondering whether some people here would like to help them.

A little googling takes you to the Wikipedia entry for LabVIEW. Recently, this was added:

However, it is worth to mention the initiative of Felix Toran, an Spanish Engineer working for the European Space Agency (ESA), who has recently originated and it is leading a project called VILab. The goal of VILab is to develop, for the first time, an Open Source response to the LabVIEW environment. The project has started its activities in November 2006 and continues recruiting the necessary development team for such ambitious goal. The VILab Project webpage at SourceForge is http://sourceforge.net/projects/vilab

However, it seems that someone removed it, recently, too ;-)

Funny thing is that I haven't heard of anyone on the team, and I've been doing LabVIEW and open source since forever. I wonder about whether the current VILab team understands the needs of graphical dataflow programmers well enough to create something that will satesfy our needs (I didn't see any well-known LabVIEW experts on the team). However, I also feel that there are a lot of things that LabVIEW's implementation of graphical programming is lacking and maybe some fresh outside perspective would be useful.

It's certainly interesting...

[Edit] I guess that they have an NI forum member, Bill Choy, on the team.

[Edit] Here's some pure speculation... I wonder if Mathworks is somehow supporting the VILab project. The project team doesn't seem to be a bunch of open source loving computer scientists who are interested in graphical programming. The team doesn't seem to be a bunch of die-hard LabVIEW users. The team states that they are trying to provide a direct alternative to LabVIEW. FFelix Toran Marti (the project lead) has developed in Matlab. The team seems to be very organized which is not typical of an open source project that has no financial backing.

[crelf]

The VILab Project webpage at SourceForge is http://sourceforge.net/projects/vilab

...and now their page hit count has hit a record today

[i2dx]

whatever ...

it's nice to see that NI has a "competitor". It's like linux it will never become more popular than windows until *we* change our way how and why we use software, but it had a nice impact on the development of windows and the guys from MS$ had to be a little bit more carefull with what they do.

It's overconfident to think that a 3 man team can measure up with the NI R&D, just due to the sheer manpower they have and not to talk about 20 or more years experience in developing LabVIEW. So if there is a *product* in measurable time, it will predictably not compete with LabVIEW (V 12.x ??) nor will any LV professional consider seriously to use it in one of his/hers projects.

[Val Brown]

You've hit the nail on the head.

[LAVA 1.0 Content]

I was browsing SourceForge and I happened to run into this current project.

Does anyone know any of the guys on that project?

I didn't recognize any of the names, and was wondering whether some people here would like to help them.

I contacted the project leader and expressed my interest in the project and a possible interest in also participating the project. I was initially welcomed. Then I sent a reply email to the project leader with multiple questions tyrying to determine what is the mission of the project and how they are trying to accomblish the mission. I wanted to know where they stand before I'd be ready to commit to the project in any way and there was absolutely no information about the project in the sourceforge.net project web page. I was answered that I should not ask about the feasibility of the project and I was asked not to contact them anymore. They told me they are a group of friends and the project is their free-time hobby. Apparently I won't be part of the project.

However, if anybody is interested in setting up an academic or commercial research project on modern general purpose visual programming languages with me, send me a personal message

jimi

[crelf]

I was answered that I should not ask about the feasibility of the project and I was asked not to contact them anymore.

That's not a project I'd like to work on. That's the complete opposite to being open - sounds to me like the Wikipedia entry is wrong.

[Rolf Kalbermatter]

That's not a project I'd like to work on. That's the complete opposite to being open - sounds to me like the Wikipedia entry is wrong.

Well, that or it is indeed a group of hobby freaks wanting to do that in their closed group. Whatever, with such an attitude it is quite likely doomed to fail even if some commercial interests and agenda is involved.

I would estimate some 10 man years of development before one can present a system with an architecture that is stable enough for future enhancements and that does some more than what LabVIEW 1.0 could do.

If I would setup such a project I would go for a common UI widget Toolkit like QT with an architecture to add special plugin widgets for new types of controls such as waveforms etc. That would require C++ (I don't think any other programming language except C is up to the task) but since my C++ is bad I would not be able to participate to much. One difficult part is the compiler in LabVIEW but it might be interesting to go for a JIT implementation instead, although that technology in itself is not really easier than a normal one pass compiler.

All in all LabVIEW itself has probably some 1000 man years of engineering invested into it and doing it all over from scratch you might get away with 100 to get to a level that can remotely do what LabVIEW can do nowadays. But that would not include LabVIEW realtime or FPGA or embedded.

Rolf Kalbermatter

[LAVA 1.0 Content]

All in all LabVIEW itself has probably some 1000 man years of engineering invested into it and doing it all over from scratch you might get away with 100 to get to a level that can remotely do what LabVIEW can do nowadays. But that would not include LabVIEW realtime or FPGA or embedded.

I don't think there is space on the market for an open source copy of LabVIEW with all the same functionality. However there could be space for a graphical general purpose programming language that would be designed from a different perspective.

• If I would design a graphical programming language now, I would design it so that it compiles to one of existing virtual machine formats such as Java Virtual Machine (Java) or Common Language Runtime (Microsoft .NET) or multiple of them. This means that one doesn't need to provide multi platform support as such support is provided by the virtual machine runtime environment. These virtual machines also exist for many embedded environments so the hardware compatibility for the execution environment would be decent from the beginning.
  
• I would also make the graphical programming language compatible with major languages compiling to the same virtual machine environment so that one can call existing library functions from the graphical programming language and vice versa. Such a design means that one can concentrate on the design of core language features as existing library functions and widget libraries can be directly utilized.
  
• I would take advantage of the research results on programming language design, so the core language would be much more expressive and more flexible than LabVIEW. This means that once the core language functionality is ready, one can develope new features and new libraries for the language in a more powerful way that what NI needs to do with LabVIEW features.
  
• I would propably write the required interactive graphical development environment (IDE) with Eclipse Rich Client Platform. There are plenty of widgets and libraries for Eclipse RCP application development which makes the development of the IDE much faster and easier as one doesn't have to start from beginning.
  

From the above perspective building a new graphical programming language would be much less laborous than designing a new graphical programming language from same stand points from where NI has developed LabVIEW. I think from these perspectives a group of around ten people can build something that would be a powerful graphical programming language and a development environment in a few years. The level of hardware integration that LabVIEW provides is inaccessible unless there is a real-time virtual machine that would run on a large number of different devices and to which the graphical language could be compiled.