What Language To Use?

[Sconrad]

Originally Posted by Andrew Schreiber

Not to be a jerk but HTML is a markup language NOT a scripting language. If they know a scripting language it is actually really useful as they already know the basics of programming (variables, flow, logic etc).

You are right. HTML is not a scripting language. I meant markup manguage but the terms got jumbled up in my head (maybe humans do need more than 5 hours of sleep a day ) I have nothing against people who have programmed in any language, as taking up a language shows they are interested in programming and computers, which, IMHO, is more important than previous knowledge.

[JamesBrown]

Originally Posted by PRich1477

Look into getting a team Dropbox account, or something similar (if you haven't already). We use our Dropbox for everything. Our CAD is shared on there (CAD is very important to us since we use sheet metal), our code (with all previous versions, so we can revert if we mess up), as well as team pictures and videos for the marketing and Chairman's team.

Very good idea, however dropbox is not the best solution for software revision management. If you are programming in JAVA or C I strongly reccomend using SVN, this will allow you to commit changes, allow you to see who is working (or has worked) on what and you can always roll back to older versions. Both windRiver and NetBeans have plugins for SVN. I am not sure if LabVIEW supports svn but I do recall a thread discussing it a while back.

[DonRotolo]

Originally Posted by Team 3705

My team also has a bad design team.

Is the team bad, or just their designs, or both? Or is it a case where the design is great, but just for a different game? Or is it a reliability problem? Or...?

You can't fix everything in software, but some rational and logical suggestions might be able to turn bad into good. How can we help?

[AustinSchuh]

Originally Posted by PRich1477

I'd estimate that over 80% of our Dropbox is CAD files, with about 4 robots worth of parts and assemblies on there (2010 x 1, 2011 x 1.5, 2011.5 x 1.5).

Our SVN repository has our CAD files in it as well as all the code. SVN works for CAD files as well.

[Andrew Schreiber]

Originally Posted by AustinSchuh

Our SVN repository has our CAD files in it as well as all the code. SVN works for CAD files as well.

About the only thing you lose is diff-ing the files.

For reference, Git works as well. Use whatever works best for your team.

[theprgramerdude]

Originally Posted by Mk.32

What off season is for.
If you have enough programmers, you can even have 2 teams, one that codes in Python and one that does C++. And for competition use which ever works better.

Don't do this. You can (and definitely should, if you have time and are considering multiple languages) do it during the off season to get a hang of each language and play around with which one is better/easier to code with, but if you do this during build season, you will not end up using better code. You'll end up using code that only has half the time put into it that it could have had, which usually implies it's not as great as what it could have been.

[Joe Ross]

Originally Posted by theprgramerdude

Don't do this. You can (and definitely should, if you have time and are considering multiple languages) do it during the off season to get a hang of each language and play around with which one is better/easier to code with, but if you do this during build season, you will not end up using better code. You'll end up using code that only has half the time put into it that it could have had, which usually implies it's not as great as what it could have been.

It's definitely not the best choice for many teams, but for larger teams it can be a good choice. Team 67 won a world championship having run some competitions with c++ code and some competitions with LabVIEW code.

[theprgramerdude]

Originally Posted by Joe Ross

It's definitely not the best choice for many teams, but for larger teams it can be a good choice. Team 67 won a world championship having run some competitions with c++ code and some competitions with LabVIEW code.

How can it be a good choice? While I am not aware of how Team 67 produced their code, the fact that they wrote good versions in both c++ and LabView simply proves that they write good code.

Unless the programmers know enough to write code in C++ and Labview and use each environments components interchangeably in the code that is used on the robot (highly unlikely), developing on both platforms means time is lost that could have been spent improving upon only one platforms existing code.

The exception occurs only when you have several programmers who are only fluent in one language, in which case, yes, it might be a good choice to split them up, although productivity-wise, it would make more sense to have them retrained in c++/labView, so everyone is using a single language and the entire programming team can actually work together, rather than having several teams not working together.

[apalrd]

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.

[flameout]

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

[apalrd]

Originally Posted by flameout

We also experienced issues with code downloads (the only available workaround was to reimage before every download).

This is a common problem involving user code taking up too much of the processor (as the bootloader runs in low priority, it can not run at all if the user code does, say, vision all the time). The solution is to flip the "No App" switch, reboot, then download. It has nothing to do with the cRio image (although an update could've increased processing requirements somewhere to put your code over the edge, so to speak).

Originally Posted by flameout

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.

The real reason that LV dosen't reboot the processor to restart the code - It talks to the bootloader, which then restarts the user code. This allows for much faster code development while using the "Run" from Robot Main, as you don't have to reboot each time. When the LV user code is using too much of the processor, the bootloader can't run, and bad things happen (in the user code too - usually it struggles to run the lower priority user code, probably the cause of your vision issues).

[davidthefat]

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

[Bryan Herbst]

If there is any question about which programming language to use, I would follow Don's advice and stick with C++, Java, or Labview.

You will find that if you encounter any problems, there will always be a mentor or student on another team nearby that can help you with any of those three. If you go with Python, your choices for assistance will be far more limited.

Python is fun for the off-season, but I would always stick to an officially supported language for the competition, because the libraries for the officially supported languages have been heavily tested and you get the support of other teams.

[WizenedEE]

I want to know why people keep saying that python is sketchy and shouldn't be a first choice of language. It's not as if the motors will suddenly stop working, is it (assuming it's properly programmed and tested)?

[apalrd]

Originally Posted by WizenedEE

I want to know why people keep saying that python is sketchy and shouldn't be a first choice of language. It's not as if the motors will suddenly stop working, is it (assuming it's properly programmed and tested)?

Because it's not officially supported (so WPI/FIRST/NI can't help you) and very few teams use it (compared to LV, C++, and Java), so you have less community help.