Calling Out All Programmers

[davidthefat]

Which route are you guys taking to code the robot? C++, Java or the LabView?

I seem to have to use Java... I wanted to use C++ but my mentor is like "The C++ Libraries Are Too Messy" or something like that... And that the Java code wont be any slower than the C++ because of FPGAs or something

[apalrd]

LabVIEW. We like the real-time front panel.

[keehun]

That's kind of funny actually -- since you can literally take C++ code, change the syntax to Java (like capitalization, accessors, etc) and compile it. Likewise, you can take Java code and change the syntax and compile it with WindRiver. I actually found C++ file a lot more elegant than LabView files we tried last year. The biggest difference is real-time execution (C++ is fast -- but is it "live" like LabView? -- I don't know). LabView by nature is slower, but it is able to process multiple things at once -- a tradeoff?

Anyway, We're using C++. We have a opensource Github, but latest code's not pushed yet. Perhaps I'm wrong about it, but I think your mentor's off the mark when he says "messy libraries". And also, are you the only programmer? How many others are there? What's your guy's consensus on a language preference? A mentor shouldn't force the students in to anything. (Except maybe administrative functions?)

That's just how my team rolls...

Thanks,
Keehun
Team 2502

[davidthefat]

That's kind of funny actually -- since you can literally take C++ code, change the syntax to Java (like capitalization, accessors, etc) and compile it. Likewise, you can take Java code and change the syntax and compile it with WindRiver. I actually found C++ file a lot more elegant than LabView files we tried last year. The biggest difference is real-time execution (C++ is fast -- but is it "live" like LabView? -- I don't know). LabView by nature is slower, but it is able to process multiple things at once -- a tradeoff?

Anyway, We're using C++. We have a opensource Github, but latest code's not pushed yet. Perhaps I'm wrong about it, but I think your mentor's off the mark when he says "messy libraries". And also, are you the only programmer? How many others are there? What's your guy's consensus on a language preference? A mentor shouldn't force the students in to anything. (Except maybe administrative functions?)

That's just how my team rolls...

Thanks,
Keehun
Team 2502

Yea I code in Java and C++, I been using C++ longer and I like it way better than Java, well the mentor said I CAN use C++ but he highly recommends Java for the sake of the cleanness of the libraries and easier setup

edit: Im the only guy going for C++ LOL All the other programmers want Java since they don't know C++

Edit of Edit: Amen to your sig

[basicxman]

I'm taking the C++ route for a few reasons

Myself and programming partner already knowing C++
It's in it's second year with FRC, Java is in it's beta year for FRC
More documentation then Java
The library is in fact quite straight-forward


C++ has always been my favourite programming language. And I do believe the Java code is going to be slower than C++ code as you're running a virtual runtime on the cRio, this is an extra process whereas WindRiver compiles C++ directly the PowerPC Architecture assembly.

I do not agree with your mentor depicting the C++ libraries (especially the WPI library) as too messy. It is in fact quite easy to pick up an extra class of the library and integrate it in your code. For example I hadn't programmed a Spike relay in C++ before and I ended up accomplishing the feet in five minutes just by taking a quick look at the C++ reference found here, http://www.virtualroadside.com/WPILib/index.html.

LabVIEW is a good choice for a lot of teams, it has more advanced and easy to use debugging tools that supposedly "just work." It has a large community over at the Texas Instruments website with tons of sample code and even video documentation. The problem I have with LabVIEW for one is that it's a graphical language. For some this great, for others (like me) I prefer manipulating a robot or computer with syntactical text. LabVIEW also requires lots of screen real estate which some of the ancient computers at our school don't have, and there's not as many books out there on LabVIEW that I can reference to new programmers.

Just putting in my two cents :)

[basicxman]

That's kind of funny actually -- since you can literally take C++ code, change the syntax to Java (like capitalization, accessors, etc) and compile it. Likewise, you can take Java code and change the syntax and compile it with WindRiver.

I had a programmer from another team mistake my C++ code for Java.

[keehun]

edit: Im the only guy going for C++ LOL All the other programmers want Java since they don't know C++

Edit of Edit: Amen to your sig

Ok, well, if all the other guys want Java, then I say just stick with Java. One of coolest things about FIRST is that it teaches you the benefits of working as a team. For my programming team, majority of the guys know Java, but we chose C++ as a preference for two reasons:


We didn't want to try a "new" language for the cRio platform
C++ was proven to work and was fast
We all kinda-sorta knew C++
Being a captain, I pushed for C++ after having a bad experience with LabView last year
Our mentor is like a 30 yr veteran in the field of C++ and Systems Networking


After working with it for a couple weeks, I feel C++ was the right choice, but I know that Java or LabView would've equally been fine. Maybe not LabView, but that's only because trying to wrap all the programmer's mindset around the real-time execution paradigm is difficult. Even the 30-yr C++ veteran mentor (he's also a huge expert in Java) didn't know why LabView behaved the way it did -- that was the real downer last year. Also, we wanted to diff and git with C++. :)

[davidthefat]

I had a programmer from another team mistake my C++ code for Java.


int Java = 10;

void Print(const char[] Text)
{
//Not Putting This In...
}

for(int C = 0; C < Java; C ++)
{
if(Java < 100 && > 10)
{
Print("Is this Java Or C Or C++??? Who Knows?");
}
}

[Bigcheese]

We're using C++ again this year for the following reasons.


Most of the student programmers know it (the ones that don't know Java).
I (the programming mentor) know it and work with it professionally.
It offers more control over the execution environment and full access to VxWorks.


The biggest difference is real-time execution (C++ is fast -- but is it "live" like LabView? -- I don't know). LabView by nature is slower, but it is able to process multiple things at once -- a tradeoff?

Huh? What do you mean by "real-time execution"? You can't get any more real-time than interrupt driven C/C++.

It is not possible to do multiple things at once on the cRIO in any language without using the FPGA. You can get rather close by using multiple tasks or interrupts, but there is only one core which means only one hardware thread running at a time.

BTW, Java and C++ may be similar on a small part of the syntax level (just like every other curly brace language), but they are far apart semantically or when using any of their features.

[DjMaddius]

Our team is going with C++.

[TheDominis]

I use C++ because I don't know how to drag and drop LabView code :P. Also I dislike Java.

[TPNigl]

Our team is going with Java because we like the overall structure of the program. We didn't have such a strong foundation in java last year, plus the main programmers this year, myself and my friend, are stronger in Java than C++, so we figured we should try Java, which is working very well for us so far.

[RKElectricalman]

I wanted the team to use C++ last year, but due to the lack of time, experience with C++, and impression that labview's GUI would be much easier, we ended up going with the latter.

It actually took less time to program in C++ then it did in Labview. It took us up until 2 days before the ship date to figure out where all of our issues stemmed from in the GUI. Not to mention it was slow on our set up. For C++ it's been much more smooth of a ride.

On the first day of the season I got all of my programmers together, taught them the basics, and by end of week one they each had programmed a small portion on the code. By end of week two, they had dived right into the use of sensors, and more intricate styles of programming... end of Week three and now they're creating their own classes for certain objectives they've set for their programming. WPILib, is AMAZING!!!! It makes everything so much easier, and with my basic understanding of C and C++ I can explain why things work the way they do, and they can learn more intricate things with delay of coding and confusion.

I. LOVE. C++. <3


-Meezy

[Radical Pi]

C++ for me. I tried Java for a bit on the cRIO from the classmate while our new development computer was being set up. I ran into about 10 errors that were really not errors but the dev environment being jumpy. Haven't opened netbeans since

[Brent Strysko]

Team 1672 will be using C++ as we had hacked up the c++ library last year, and feel that we do not want to have put all that time to waste.

[Igor1201]

We'll use LabVIEW but, particullary, I would prefer Java.
However, LabVIEW have all the "visual" things, like the graphs and real-time changings.
P.S.: I hate that blocks.

[Tanner]

The only reason I use LabVIEW is because of it's debugging capabilities. As far as I know, C++/Java still use a terminal window (then again I haven't been reading up on those). Being able to see anything I want to from my program, in real time, with no extra work is just amazing.

'Course the downer is that it doesn't work very well with VCS and if you're a perfectionist (like me) all the little wires must be organized and straight.

-Tanner

[Alan Anderson]

'Course the downer is that [LabVIEW] doesn't work very well with VCS and if you're a perfectionist (like me) all the little wires must be organized and straight.

LabVIEW can work well with version control systems. You just have to find an adequate set of instructions.

There's a "broom" tool that straightens up block diagrams. It does a remarkably good job of organizing things.

[Greg McKaskle]

Spoiler Alert: LV editing tips follow

For the perfectionists out there, I learned to use LV before the auto-routing and the auto tool. I still prefer it that way.

If the little wire bends bother you, try turning off the auto-routing. In that mode wiring will only produce a simple L for each click. There are two orientations to the L depending on whether you first moved horizontal or vertical. If you want to swap for the other, hit the space bar while wiring. Also, you can tack a wire wherever you like to cause it to go through that point. It takes a bit more thought, but but leaves you in control, and I guess I like it that way -- though I do like the cleanup tool as well.

A similar tradeoff exists for the auto tool. Using the auto tool, LV will swap out the wiring, movement, and text editing tool depending on mouse position, clicks, and whether the object is selected. If you turn the auto tool off using the preferences, or using shift-right click, you can hit the space bar (provided you aren't typing text), or tap the tab key to cycle through the common tools. You can also shift-right click to select the uncommon tools. Again, this takes a bit more thought, but leaves you in control.

There are also plenty of key hints you can give LV even if you leave the auto stuff turned on. I believe that holding Ctl and/or Shift key swaps to the alternate auto tool, and hitting the A key while wiring turns auto routing on/off. You may want to check the quick reference card or manual for others.

Greg McKaskle

[Chath Maral]

We were going to use C++ this year, but switched to LabView because it is easier to explain to the freshmen who have no experience and we need to pass along our knowledge in order to keep the team alive.
So far we have not had many problems *knock on wood* and it's running smoothly.

[Sauce]

We used labview last year so we're using it again this year.

[StevenB]

I seem to have to use Java... I wanted to use C++ but my mentor is like "The C++ Libraries Are Too Messy" or something like that... And that the Java code wont be any slower than the C++ because of FPGAs or something
From talking with several of the people who wrote the C++ and Java libraries (WPILib and WPILibJ), the Java libraries are basically wrappers around the C++ code. If you look through the documentation, you'll see that most things are exactly identical, with the exception of capitalization changes to match the Java naming convention.

Java does run slower than C++ on the CRIO. It's running the Squawk JVM, which is optimized for small devices, and doesn't include all the speed improvements that normal desktop Java provides. That said, the speed difference is not going to matter, unless you're doing something really complex and esoteric. The FPGA and C/C++ libraries do nearly all of the serious computational work, from handling encoder pulses to doing image processing.

Personally, I'm a longtime C/C++ programmer and I'm comfortable with LabVIEW, but I've been converted to Java. The whole software stack is open-source, and installing NetBeans with the FRC extensions on my Linux machine was a breeze. Downloading was simple and straightforward; we spent hours last year just trying to get the CRIO to connect to WRW.

[dag0620]

1071 is going on Labview. The descion to this was mainly based on that out of all the programming students we have, only one is a veteran. He is only in his 2nd year and used LabView. So it was decided, we would use labview. I am pretty happy with it so far as a rookie, quickly picking up stuff. We are thinking about switching to Java next year, but that is pretty far up in the air.

[TheWhiteReaper]

1723 is using LabView again because our head programer Josh has been using it for 4 years and has been teaching every one on the programing staff all it's ins and outs. Also I find lab view easier to debug than C++ or Jave because of the "highlight data flow" and "show/highlight location of error" functions.:yikes:

[Al3+]

840 used LabView last year, and switched to C++ this year.

The one veteran programmer on our team last year opted for LabView because it seemed easier for newbies to pick up and use. As it turns out, most of the bot was coded by myself and another newbie. We went from no one having any experience with it, to working code by ship date (although nothing advanced), so I guess it worked out.

This year, I pushed for C++ after seeing how simple and beautiful WPILib is (in my opinion) and because I have worked with C++ before. I do foresee some problems passing it on to new members without any coding experience, but at least there's another year for that.

[TheWhiteReaper]

The one veteran programmer on our team last year opted for LabView because it seemed easier for newbies to pick up and use. As it turns out, most of the bot was coded by myself and another newbie. We went from no one having any experience with it, to working code by ship date (although nothing advanced), so I guess it worked out.

This is why we're using LabView. I've been working with it for less than a week and I'm starting to code our robot already.

[daltore]

We're using LabView mainly because our teacher sponsor has buddied up to LabView people. Most of our programmers wanted to use C++, but the LabView is working, and I'm kind of getting used to it.

[hyperdude]

At this point I'm not 100% sure which route we're taking. The team consensus is that we're going to program in LabVIEW, but the junior responsible for setting up our electronics (and ostensibly for programming) has been stubborn about using C++: solely, it seems, because he knows more about C++ than LabVIEW.

Until the middle of this month I was absolutely confused by programming in LabVIEW. Then I watched the NI tutorials and I got it right away (more or less because I LOVED programming in RoboPRO in Principles of Engineering). This kid, though.... we just don't know.

All right, I'll stop rambling.

[Doc Wu]

Isn't that kind of like asking PC, Mac, or Linux?

Whatever you choose is what's best for you.

[davidthefat]

From talking with several of the people who wrote the C++ and Java libraries (WPILib and WPILibJ), the Java libraries are basically wrappers around the C++ code. If you look through the documentation, you'll see that most things are exactly identical, with the exception of capitalization changes to match the Java naming convention.

Java does run slower than C++ on the CRIO. It's running the Squawk JVM, which is optimized for small devices, and doesn't include all the speed improvements that normal desktop Java provides. That said, the speed difference is not going to matter, unless you're doing something really complex and esoteric. The FPGA and C/C++ libraries do nearly all of the serious computational work, from handling encoder pulses to doing image processing.

Personally, I'm a longtime C/C++ programmer and I'm comfortable with LabVIEW, but I've been converted to Java. The whole software stack is open-source, and installing NetBeans with the FRC extensions on my Linux machine was a breeze. Downloading was simple and straightforward; we spent hours last year just trying to get the CRIO to connect to WRW.
funny thing, my mentor and I spend like 3 hours trying to find the demo code for the java... We were looking all in the wrong places LOL

[daltore]

Isn't that kind of like asking PC, Mac, or Linux?

Whatever you choose is what's best for you.

<off-topic.rant>
I would like to point out that PC=Windows has only come about because of the Windows vs. Apple ads that have come up in the past few years to make it seem that Linux doesn't exist. In fact, "PC" is a generalized term that only refers to hardware, and can run any operating system that supports it.
</off-topic.rant>

[Robopanda6]

I don't mind Labview, it's easier to use than the other languages but it's just so messy. I'd rather lines of code than bits and pieces of it on my screen.

[davidthefat]

<off-topic.rant>
I would like to point out that PC=Windows has only come about because of the Windows vs. Apple ads that have come up in the past few years to make it seem that Linux doesn't exist. In fact, "PC" is a generalized term that only refers to hardware, and can run any operating system that supports it.
</off-topic.rant>

PC = Personal Computer

if you want pure power, go get a main frame:D

[JohnFogarty]

Labview all the way, I have alot of experice with the G language so Labveiw is a snap. Though some of the FIRST references screw up I just use FPGA to create custom vi's.

[Jared Russell]

Java, even though C++ is my personal language of choice for general purpose programming.

Two reasons:

1. Easier for the students to learn Java than C++ "correctly"
2. I can run it on my Macbook.

[byteit101]

if you want pure power, go get a main frame:D

if you want pure power, get a nuclear bomb, er, computer! :D

[davidthefat]

if you want pure power, get a nuclear bomb, er, computer! :D

Computers in a nuclear submarine is powered by nuclear power.:ahh:

[dmitch]

Ok, well, if all the other guys want Java, then I say just stick with Java. One of coolest things about FIRST is that it teaches you the benefits of working as a team. For my programming team, majority of the guys know Java, but we chose C++ as a preference for two reasons:


We didn't want to try a "new" language for the cRio platform
C++ was proven to work and was fast
We all kinda-sorta knew C++
Being a captain, I pushed for C++ after having a bad experience with LabView last year
Our mentor is like a 30 yr veteran in the field of C++ and Systems Networking


After working with it for a couple weeks, I feel C++ was the right choice, but I know that Java or LabView would've equally been fine. Maybe not LabView, but that's only because trying to wrap all the programmer's mindset around the real-time execution paradigm is difficult. Even the 30-yr C++ veteran mentor (he's also a huge expert in Java) didn't know why LabView behaved the way it did -- that was the real downer last year. Also, we wanted to diff and git with C++. :)



What was the bad experience you had with labview last year? It would help because that's what our team is using it would help to have an idea of any errors we should expect. Thanks in advance!

[FRC4ME]

619 is using Java this year. Many of the students are taking Java classes in high school, so it fits well. Also, it is so nice not to have to explain memory management to new programmers. C++ has far too many idiosyncrasies that just make new students go, "what the heck?!?" In my opinion, at least.

What I [i]don't]/i] like about Java is that we are limited to ME features. Java without generics has its own idiosyncrasies, too: ((Integer)vector.elementAt(1)).intValue() to extract an int from an array, for example.

[spartango]

192 is using java this year, primarily because students are learning it quite well in class, which leads to a smooth transition into the robotics world. We've noticed no real performance issues(we're sure they're there, but not big enough to hurt our bot) with the JVM this year...

What I don't like about Java is that we are limited to ME features. Java without generics has its own idiosyncrasies, too: ((Integer)vector.elementAt(1)).intValue() to extract an int from an array, for example.

FYI: There is a trick that we've used when developing for squawk(on SPOTs) that allows you to write Java 5 code(with generics etc) and still deploy it to the VM. FRC hasn't gotten around to integrating it with the SDK provided--i expect they will for next year--but if you really want those features...look up "retroweaver". There is also a comment about it in Eric Arseneau's presentation at google:

http://www.youtube.com/watch?v=aCM9KN2pzQE
around 28:00...

[j.cole]

If I knew (and by I, I mean anyone on my team) Java that's what I'd use but since LabView is easier and already known by the team that's what we use.

[_Tanto_]

C++ we've been using c++ for the last 6 years or so and we feel its the most flexible of the three