Quote:
Originally Posted by Greg McKaskle
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.
|
Interesting take, but I still don't understand why an if-statement would be functionally different from case statements at all. A proposed if-statement structure would basically be a case statement, except it only takes boolean values, right? There wouldn't be any more null variable problems than case statements. And then, have a way to right click and attach else ifs to the initial if. I'm actually not sure if I understood this point though. What's the concern with uninitialized variables?
One benefit of this would be that it's easier to visually identify and understand long chained if/elif/elif/elif/elif.../elif statements where you have different conditional in each elif.
Example:
if (a == 1)
else if (b == 2)
else if (c == 3)
else if (d == 4)
An if-elif structure would be 1 structure with 3 squares attached to the bottom. If you're using case statements, you'd stack 4, one in each other. I'd argue the former looks nicer and more intuitive.
Quote:
Originally Posted by Alan Anderson
The flip side is that for people who start out learning LabVIEW, it's confusing to find that the equivalent of a Case block is done in a procedural language like C using several completely different structures, each with utterly different syntax.
Why is the name such a big deal, anyway? It's a different language, and things do not map directly from one to the other. If you insist on calling things by the name of something similar in another language, I think you make it even more confusing. Someone looking for something that acts like a C "switch" certainly isn't going to expect to find it named "if".
|
I agree that C style languages goofed up with the switch/case and the if statements using completely different syntax, and the falling through behavior is kind of weird. Probably something to do with legacy and how code used to be written. However, adding support for a new syntax (in this case, an if statement) almost always has less impact than getting rid of something, which is why I wish LV had an if statement, instead of wishing C got rid of if statements.
Another analogy would be like if NI decided that they're going to start calling while loops "gobblygooks", booleans "dingdongs", and arrays "cheeese". While they're at it, also make trues red and falses green. It's their language and it'd be perfectly within their rights to do so, nothing is functionally changed and LV is just as powerful as it was before, but it's one of those things that at least warrant the question, why?