total noob question :)

[Racer26]

I don't know Alan, I use LabVIEW at work, and I'm more used to traditional (C/C++/BASIC/etc) style programming, and I wouldn't even really consider G to be a "language" per se. I like to refer to LabVIEW/G as "Programming with flow-charts."

[GregT]

Originally Posted by 1075guy

I don't know Alan, I use LabVIEW at work, and I'm more used to traditional (C/C++/BASIC/etc) style programming, and I wouldn't even really consider G to be a "language" per se. I like to refer to LabVIEW/G as "Programming with flow-charts."

LabVIEW's "G" language is a Dataflow programming language. Dataflow programming started to gain popularity in the late 70's / early 80's with the emergence of supercomputers supporting large levels of concurrency.

Dataflow programs are referred to as "data driven" because the flow of execution is determined by the availability of data in the program, not a sequential order. When you write a program in a structural language like C or C++, execution of commands (lines) must occur in sequence (although this order can be somewhat controlled by the use of threads).

Dataflow programming languages, such as LabVIEW, don't impose this restriction. Any part of the program can be executed at any time, depending on when the individual components receive inputs (in LabVIEW, this happens along the wires).

A dataflow program consists of a set of actors (in LabVIEW they are called components) connected by relations (wires). When an actor has received all the information it needs to perform its assigned computation (ex. an addition actor needs two inputs, A and B, to perform A+B) it does so and passes the result along wires to connected actors. In this way, data propagates through the program to the other actors.

This is all really cool because, by default, Dataflow programs are highly concurrent. Any actor can perform its assigned work whenever it has data available- even at the same time as other actors! While this isn't terribly useful for our controller, as normal desktop CPU's keep getting more and more processing cores, this type of programming has the potential to become very important. Free concurrency!

My point is, don't feel like you need to learn C or C++ to program competitively in the competition this year. Many experienced programmers don't like LabVIEW because it is radically different from what they are comfortable with. While I haven't familiarized myself with the new control system, LabVIEW as a programming language can be just as powerful as C++. Any difference is due to a more optimized compiler / architecture.

LabVIEW is not necessarily less powerful than C++, it's just different.

See also:
http://en.wikipedia.org/wiki/Dataflow_programming
http://www.cs.ucf.edu/courses/cda415...rcomputers.pdf

[Red Mage]

Why do people insist on naming languages after letters?

[King Duke]

The free online stanford CS courses.

They really stress software engineering, not so much learning a language.
http://see.stanford.edu/SEE/Courses.aspx
The professor is pretty good though. At least for the one that i watched.

Also from the description of labview that we just received, it sounds as if it would work best with VxWorks, because VxWorks is an RTOS (Real Time Operating System) that is "hard-real time" RTOS....

basically it's an operating system that all events must be finished by their scheduled times, if they aren't done by then it's considered a failure of the system.

thus labview and the VxWorks seem to go hand in hand.

Does this make sense to everyone else?