LabVIEW
reference vs local variable
Vasilich2004 wrote:normal language - Java, C++, C#
easy - because easy to use
why - because LabVIEW system would be simpler.
Why would text based programming be "normal"? Just because that's what you learned first?
None of the early computers were programmed using text based code. For example ENIAC was programmed using patch cables and switches. Later was the time of the punchcards, teletype and much later terminals such as the VT100. Back then, communicating with computers was hard, because anything (input and output) needed to be reduced to a linear sequence of monochrome printable characters (the second dimension was controlled by the linefeed character!). You could do the Mona Lisa in ASCII art, but why bother. There was no other way!!!
To make things bearable, programming languages (Such as FORTRAN) were invented but the situation was clearly not optimal.
Shortly after the Macintosh came out, interaction with a computer became graphical and two dimensional and Jeff Kodosky at NI invented LabVIEW, leveraging the technological advances in computing.
Modern computers have multiple processor cores and the OS is multithreaded. In modern programs many things happen concurrently. Your word processor formats and spell checks as you type. A computer can solve a chess problem while you are watching a video in a different window all the while your AV software is scanning your drive.
Writing a program that does many things concurrently and safely while avoiding race conditions is very hard using text based code. Remember, to write a text based program you need to serialize the entire idea into a linear sequence of printable monochrome characters! Text based code is an incredibly clumsy detour that should not be necessary at all. It is difficult to imagine why a large part of the programming community is still clinging to it, wasting their time.
Computers are no longer "text only". Everything is graphical, allowing a much richer experience. A typical smart phone is orders of magnitude more powerful than a Cray-1. The keyboard is mostly replaced by a mouse or even multitouch screens. It is very difficult to communicate using text alone, because there often need to be additional clues to indicate how it was meant. That's why we need emoticons in text messages and forum posts! 😄
For the same reason, trying to communicate your programming idea to the compiler should be done graphically! Suddenly all the restrictions of text based code are no longer present. With LabVIEW, you can instantly create programs that do many things at once. Dataflow determines the execution order and the compiler has a much better grasp on what should happen, but it also has much more freedom to arrange things in a way that all CPU cores can be kept busy if needed, or gracefully leave them idle if nothing needs to be done.
Remember, the LabVIEW compiler directly processes the diagram into machine code. It does not generate intermediary text based code, for example.
Trying to emulate text based code with LabVIEW is silly, because it nullifies all the fantastic advantages of dataflow. Stick to text based programming if you want go that route. Disconnecting terminals as you suggest breaks dataflow based execution order, that would need to be re-established in other ways, for example with a liberal sprinkling of sequence structures. Two wrongs don't make a right!!
As I said, it is all about communication. Over the millennia, technology has provided great advances, from smoke signals, clay tablets, morse code, radio, telegrams, b&w TV, color TV HDTV, internet, etc. and the advances will continue at the accelerating pace we've seen so far.
Programming is basically about communicating to the compiler what you want the program to do. Why stick to techology that nearly a century old to tell the compiler your thoughts and ideas?? Seems ridiculous if you think about it!
Graphical programming is the future, and LabVIEW will continue to evolve to adapt to our needs as technology improves. Even today, we can write LabVIEW code that can run basically unchanged on a desktop computer, on an embedded sytem, or even directly on an FPGA chip.
The ease of graphical programming let's us be more productive. A given program can be done in less time, or a program can be more feature-rich for the same effort. This gives us more time to push the boundaries of programming and advance it to the benefit of mankind.
Why would you elect to remain in the stone ages of programming? Sometimes better tools are developed that can make the old tools obsolete. Would you still want to do linear algebra using roman numerals?
ALTERBACH!
I like your answer!!! Thanks!!!
In my life I can remember analog computers 
I met 2 or 3! Do you?
I used normal because I think most people use text-based languages. And I wouldn't fight against that conputer world is changing very fast. I also agree that NI is making huge progress.
At the same time, my current position is next - LabVIEW is better for small and simple programs.
If the program becomes bigger then it is harder to control variables (OOP and project introduction helped but still in text-based language I, personally, feel much better). Probably, if LabVIEW would have similar Visual Studio, like Microsoft or Eclipse, with one program window and defined parts inside of the window I will fell better.
If the program becomes more complex then again it is hard to control behaviour. Espesially, debugging vi which is called dynamically. Again I suppose if LabVIEW will have few copies of dynamical vi but programmer have access only to one copy then it would be easy to debug.
Actually, we are too far from "reference vs local variable"
@Vasilich2004 wrote:
ALTERBACH!
I like your answer!!! Thanks!!!
In my life I can remember analog computers
I used normal because I think most people use text-based languages. And I wouldn't fight against that conputer world is changing very fast. I also agree that NI is making huge progress.
At the same time, my current position is next - LabVIEW is better for small and simple programs.
If the program becomes bigger then it is harder to control variables (OOP and project introduction helped but still in text-based language I, personally, feel much better). Probably, if LabVIEW would have similar Visual Studio, like Microsoft or Eclipse, with one program window and defined parts inside of the window I will fell better.
If the program becomes more complex then again it is hard to control behaviour. Espesially, debugging vi which is called dynamically. Again I suppose if LabVIEW will have few copies of dynamical vi but programmer have access only to one copy then it would be easy to debug.
Actually, we are too far from "reference vs local variable"
While it may be true that you are more comfortable using text based languages your reasons for saying LabVIEW is only suited to small or simple applications is a product of your lack of experience in dataflow programming and I would also say in application design and architecture as well. LabVIEW is perfectly suited for large applications (I work on some with several 1000s of VIs). It comes down to good designs and good architectures. Also, a very easy tip is try to separate the user interface from the processing as much as possible. This makes the application more robust and easier to maintain in the long run. Low level processing tasks should have no idea or care about the user interface. At most, it should send messages to the UI to update things. HOwever, it should not care or be concerned with how those things are represented on the user interface.
@Vasilich2004 wrote:
ALTERBACH!
I like your answer!!! Thanks!!!
In my life I can remember analog computers
I used normal because I think most people use text-based languages. And I wouldn't fight against that conputer world is changing very fast. I also agree that NI is making huge progress.
At the same time, my current position is next - LabVIEW is better for small and simple programs.
If the program becomes bigger then it is harder to control variables (OOP and project introduction helped but still in text-based language I, personally, feel much better). Probably, if LabVIEW would have similar Visual Studio, like Microsoft or Eclipse, with one program window and defined parts inside of the window I will fell better.
If the program becomes more complex then again it is hard to control behaviour. Espesially, debugging vi which is called dynamically. Again I suppose if LabVIEW will have few copies of dynamical vi but programmer have access only to one copy then it would be easy to debug.
Actually, we are too far from "reference vs local variable"
You are aware of that what you know as variables in text based programming, is a wire in LabVIEW.
Follow the wire and you can see where your data is flowing -> dataflow programming.
The only thing you should use local "variables" for is to get access to user input/output, NOT to hold temporary values for use in the program at a later stage.
@Steve Chandler wrote:
However most modern text code editors have syntax highlighting - no more monochrome.
Yes, but what you enter is monochrome. You can save any program as a plain text file and there will be no loss of information. The syntax checker of the development environment will color the program parts based on the structure and validity of what you have entered. It is the development environment asking you "Did I get that right?", basically a grammar checker on steroids. It is a good troubleshooting tool!
You typically have no way of changing colors randomly, for example you cannot color a statement green to turn it into a comment, but it will turn green if you make it a comment by prepending a special symbol. ;).
IMHO, most Visual Studio user don't like Labview, they will say, quote, "it goes against all text programming philosophy". But, when further questioned, they never learned how to control labview's behavior. Debugging dynamically called code is just as hard (or easy if that's your view) in Visual Studio and Labview. They (IDEs) have identical debug tools, step in, step out, step over, breakpoint, probes etc, etc
===================
please, read my previous message.
Specially for you.
I am not sure how you familiar with Visual Studio. In C++ and C# I can see all variables values. Eclipse plays worse on Windows and more headache on Linux.
Moreover, I can change code on fly 
Can you do that in LabVIEW?
