Quote:
|
to allow people to put together parts of the program while typing code
|
That sounds like a good idea. And as I mentioned near the top of the third page. algebraic statements have been a part of LV since version 1.0. They are mostly for compact logic and math statements. Trust me, we have nothing against text or math or traditional ways of doing things. When we finally get around to it, there may/will also be a way of doing your logic with truth tables or K-Maps. But for now, algebraic and graphical are both supported.
Quote:
|
what they have against if-statements. Every C based language has if-statements. Plenty of visual languages out there have if statements. (Scratch, which is where I started programming in middle school, is a great example) How hard could it be to add in another block for if statement.
|
And this is a good question. It is phrased in a somewhat confrontational way, but there is a question in there.
One of the values in seeing other languages is that not all languages are C-based, or Fortran or Algol either. If LV were a graphical version of Java or C, it would make perfect sense, and we might as well throw in break, continue, and goto statements as well. But, LV is a data flow language -- pretty different on purpose.
So here are the technical reasons why LV doesn't have an if/else.
1. If/else statements are the primary way to introduce uninitialized variables.
2. elif statemetnts often reevaluate expressions or bring in entirely new statements. This makes side-effects like leaving a motor running unclear and unpredictable.
3. The language is simpler to learn without it.
More detail:
#1. LV wires can be thought of as automatically named, tightly scoped variables. By making the if/else into a case, the else frame is required, and all values/wires/variable updates that happen in one frame must happen in all other frames. This forces the programmer to think about and deal with all conditional branches before they start running the program and forget. Most textual compilers go to great lengths to identify uninitialized variables, but they have to compromise between obnoxious warnings and runtime errors. By looking at the problem differently and not adopting the looser style of if/else, these issues are reduced by a huge amount.
#2. The evaluated logical expression inside the parenthesis of the if() and elif() can hide side-effects such as allocations, modifications to refcounts, and modifications to I/O. This is a common source of behavioral bugs. Case statements don't have this issue.
#3. Scratch is another popular graphical language. We work with the MIT Media Lab pretty regularly on LEGO stuff. We have plenty discussions about the tradeoffs and compromises in the languages. Note that they have two forms of if and no case. Neither has a goto. Hmm.
The point?
If you see a language that is missing a feature of C, or a feature of Scratch, or a feature of LV, it is good to notice it, good to question it. It may be that the authors of the language were lazy or sloppy, but that is pretty unlikely. More likely, the overall structure and goals of the language are trying to guide you to do something a specific and alternate way. Maybe their alternative way is better, maybe worse, maybe different. Ultimately, you decide, but learning the language and considering the alternative will at least stretch your brain a bit.
One last point: I sometimes find that people assume that computers understand the C language. They assume that the processor knows what an if() statement is and what a variable is. This simplified understanding is not correct, but it really doesn't affect anything while they learn the C language. But that clouds things with the learn the next language. They assume that Java is just some macros or some translation of C. And they make the same assumption about LV.
Just to be clear. The LV code you write does not get translated into C. It doesn't get translated into any textual language. It gets compiled into chunks of machine code that are scheduled based on runtime data flow and timing specifications in your diagram. Portions of it are close enough in concept to C that you can pretend they are the same. Other portions are different enough that you shouldn't.
By the way, the FPGA code is also written in LV. It actually does get translated into a textual language -- VHDL. The VHDL goes through sophisticated compilers and tools from Xilinx that produce the bit mask that defines the FPGA behavior. And there actually are other tools that translate LV diagrams into C, but they were built for embedded environments and they do not support all LV language features. The general LV that runs on cRIO and on Macs and linux and Windows computers directly generates machine code.
If you have other questions or comparisons I'll be happy to try and answer.
Greg McKaskle