|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||||
|
|||||
|
Re: What Language To Use?
In team 67's case, they had two independent groups programming (no common programmers). They had so many people interested in programming that a single team would have been too large to be reasonably productive (I fully agree with this opinion - Too many programmers on a project of this size is a bad thing).
I talked with 67's lead LV programmer from that year. After talking with him, about LabVIEW, he made no mention of any interaction with the C++ guys at all. |
|
#2
|
|||
|
|||
|
Re: What Language To Use?
In 2010, we started off using Java. However, we wanted to use the camera tracking code, and somewhere in the native libraries or WPILibj, it was crashing (I recall getting some sort of error in Netbeans's debug console).
Therefore, early on, we switched to LabVIEW. This worked great, until the end of build season, at which point... -- the camera stopped working again (after updating the cRIO image). We also experienced issues with code downloads (the only available workaround was to reimage before every download). As our code that year was relatively simple (because the default vision worked out of the box), it was within our capabilities to have coded in both languages (and C++ too, for that matter). Had we done so, we could've switched languages away from LabVIEW -- likely solving the code download issue (since Java and C++ use FTP, and LabVIEW doesn't AFAIK) as well as possibly restoring camera function. I am considering writing code in multiple languages this year -- even if we only get vision (assuming it exists in the next game) working in one or two languages, it'll still be driveable should we encounter a killer bug in one of the cRIO's images. Of course, this means nothing if you don't have programming time to spare -- after choosing a "main" language, don't sacrifice the quality or performance of your main code just to work on the backups. Just my 2¢. |
|
#3
|
|||||
|
|||||
|
Re: What Language To Use?
Quote:
Quote:
|
|
#4
|
|||
|
|||
|
Re: What Language To Use?
Quote:
We did not change our code at all when we updated LabVIEW, so that rules out a mistake on my part. I apparently missed the No App DIP fix -- the post came two days later, so I probably either forgot to check the thread or subscribe to it (we wouldn't have done any further programming after this point until regionals). Thanks for the help. Note: I still feel my point about using multiple languages (iff you have the resources to) holds, even if this one instance turned out to be a solvable problem (it would've been nice to just switch languages, rather than needing to scramble for a last-minute solution). |
|
#5
|
|||
|
|||
|
Re: What Language To Use?
Here is my two cents: do not get caught up in the whole "which" language debate in the first place. Just pick one. The language you use will not affect performance of the robot (unless you are doing some memory intensive calculations and need to optimize). What is important is the way you think and come up with a solution. Regardless of the language, the solution is the most important thing here. Different languages will not hinder your ability to come up with that solution; chances are, you won't be using features specific to one language. For example, pointers; every object other than primitives in Java are essentially pointers. Don't be immature and say "oh, but I want to use pointers, so I must use C++". No. You also probably will not need inline assembly either. Java just makes memory management easier too. If your java program has a memory leak, you are doing something very wrong...
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|