Re: Java vs Labview
 

None of us do yet we come back for more punishment.

Re: Java vs Labview
 

+1

Re: Java vs Labview
 

Look at Parkway from Virginia. Most of the issues after in the initial inspection issues were related either wiring or Java issues. Most of those Java issues were traced back to wiring or mechanical/hardware related.

I will say LabVIEW will get you up and running quick once you are coding. But While LabVIEW is installing, I can be testing and coding in JAVA provided I have an internet connection to do the updates.

Re: Java vs Labview
 

Was this because of bugs with the library causing it to not work, or just that you didn't know how to use it?

I have had the opposite experience: I can code a robot in Java significantly faster and better than in LabVIEW. Despite having more experience with LabVIEW.

As for which is easier to pick up if you are already into the build season: I think it depends on your robot. If you are going to need to make some complex code with PID and sensor feedback and a lengthy autonomous, Java is the way to go. 1-2 hours watching Brad Miller's youtube playlist on using robotbuilder, and your ready to dive in. But for more simple code, LabVIEW is probably easier to learn the basics due to its more self-explanatory structure.

Re: Java vs Labview
 

1- Not sure, didn't want to waste more time trying to root the problem. Thought the library was self-explanatory so it might be the former.
2- I probably would be able to do the same in C++ if we could get it to actually work
3- I learned about Mr. Miller's playlist just last week, would've really helped but whatever

Re: Java vs Labview
 

2 ANDs, an OR, a multiply, an add, a comparison. Now, if we include the inverting blocks, which will be another 2, that's a lot of blocks to be dragging around.

Point is, even if you do it in 3 (I can't think of a way now, but I'm sure someone better at LV than me can do it), that's still quite a bit slower than typing it out. Now, if you wanted to change the sequence or change the order of blocks... that's even more labor in LV.

A way that LV could (and IMO should) speed up this process would be to allow people to put together parts of the program while typing code. That way you wouldn't have to sacrifice any of the features and still be able to get things done faster. Maybe there is some way of doing this and I'm just completely ignorant.

Also, I don't know 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. They already have case structures. Someone out there's probably made a SubVI for if statements. If LV followed more traditional terminology and added in some basic stuff, they could totally convince a lot more people to switch without confusing their existing user base. Just a minor rant from a text programmer's perspective.

Re: Java vs Labview
 

I think a case structure can function as an if-statement; just wire a boolean value to the condition terminal. Am I misunderstanding?

Re: Java vs Labview
 

You're absolutely right and they do the exact same things (forget cases, I can use a while or for loop for the exact same functionality too), so this is going to seem like a petty request for some people, but the question I'm proposing is: if it ain't broke, why change its name? In every C like syntax language, there's an if-statement. I'd have to think hard to come up with a language without an if statement. Smalltalk, maybe?

It's extremely confusing for people who knew Java/C++ or most other programming language and switch to LV and find that something that is functionally the exact same exists but under a completely different name. It's things like this that turn people off from using LV, and first impressions matter. It took me a few weeks to be convinced that LV wasn't the language of the devil, and some other programmers I know still hate it with passion. (There were other LV interface quirks that had impatient high school me pretty annoyed: autoformat was too compact, copying and pasting over a while loop brings out a new dimension, broken wires everywhere, tiny connector nodes, unintuitive true/false in code, auto connecting with new blocks in proximity...etc.)

Then again, these are issues that most new programmers won't be having issues about and other languages definitely have their own problems, so what do I know? :)

Re: Java vs Labview
 

Fair points all around. I find that LabVIEW is easier to teach to people with zero programming background and are interested in control systems. The fact that it's proprietary is a bit of a turn-off, but I haven't had any bad experiences with it so far (and I had two summer jobs which forced me to use NI products exclusively!). That said, I'm still torn on whether I would use Java or LabVIEW to program a FIRST robot. Probably Java, now that I'm finishing up my CS degree and am very comfortable with OO paradigms. But if I'm working with students who still have much to learn, I like the intuitive nature of LabVIEW programs.

Re: Java vs Labview
 

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.

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

Re: Java vs Labview
 

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

Re: Java vs Labview
 

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.

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?

Re: Java vs Labview
 

An if statement without an else has no way to specify values for the !if cases.

If(x==3) y=4;

When x isn't three, what value will y have? Perhaps y is already initialized, perhaps not, and that is an opportunity for an uninitialized variable. Sure, one x and one y and it is trivial to see, but as things scale, the structure and the usage pattern lead to a very large number of potential problems.

If/else is equivalent, and the documentation and instructors will typically say something to the tune of "If you are familiar with if/else statements in C/Basic, the Boolean switch is the equivalent". Then they should explain that the other case may seem unnecessary, but lets you ensure that the wire-equivalent of y gets a value that you explicitly specify and think through.

Right-clicking and arbitrarily adding else ifs to an if is prone to building an incomplete or tangled set of logic. For example, if you have four integer variables, a, b, c, d, and that is the complete logic statement, I'd schedule a code review immediately. That is almost guaranteed to have holes in what it handles and how it handles it. Similarly, a series of nested Boolean cases also raises my eyebrows, but it has a higher chance of being written correctly because of the else's. In all likelihood, the variables need to be transformed first into a more explicit state variable, and the action switch is driven that new value.

The other issues with cascading vertical boxes is that the either cannot have wires that leave their border, or the wire coordination is very unclear. This occurred in Mindstorms NXT. LEGO asked if we could draw the case statement flat, with a simultaneous view of all diagrams. The tradeoff is that wires may not cross the structure boundary. The 3D structure of the case, becomes nasty and difficult to edit and visualize when disassembled and placed into 2D.


For an example of the consideration that goes into extending any language and comparing it to existing de facto standards, here is a paper that describes why object oriented LV was done the way it was done. I don't have a paper for the equivalent thoughts on if/elses and cases, but I'm pretty sure the conversations did take place.
http://www.ni.com/white-paper/3574/en/

Greg McKaskle

Re: Java vs Labview
 

Ahh I see now. The way to solve this problem would be to enforce having an else (like the default case in the case structure), right? And if you initialize something in one place and not another, you'd have a broken wire much like a case statement would give you one.

I'm beginning to see how it might turn into a bigger problem than it solves though.

Re: Java vs Labview
 

I believe Java (and C++) are more general purpose. While you can use LabView outside of FRC, you can't write a regular computer application with it. Sorry, LV programmers, but you can't write games. Java and C++ are much more portable and don't require that you use a National Instruments product. You can easily find a microcontroller or some development board that runs either Java or C++, and It'll be in the affordable range, good devel boards from $10 to $500. With Java or C++, you will be able to have a bit more of fun, because there are many APIs to allow you to do hardcore game programming. C++ and Java are also going to be more relevant in school because it can be used within classes to improve the course. I am working on an OpenCV application for my old Physics teacher because he is using those expensive DataQuest modules. Instead, I can set up a single computer and the other students can upload a video of their experiment to the computer. That'll quickly analyze their lab and give them the information that they need/want!