Quote:
Originally Posted by JamesBrown
Learn LabView, it is far from being a joke and is extremely popular in the field of automation. LabView is absolutely programming, it is easily one of the most powerful programming tools available. I have been programming robots for quite a while, in every thing from MIPS to LISP. LabView is as much of a programming language as any of those, every design pattern you can implement in C/C++ (or your choice of other OO languages) can be implemented in LabView. The students out there who bash LabView most likely have not taken the time to learn it and master it. Sure it is cool to hard code every thing, I remember bashing EasyC when I was in High School because it wasn't real programming. However, I guarantee that when you get a real job writing software your boss isn't going to care that you can write code in a more noble language than the one I choose, if my code is as functional as yours, and I can write it faster I will get the raise, the contract, or the job 100% of the time.
|
I'm going to second the godfather of soul.
Text based programming languages are starting to get to the point where assembly was 15-20 years ago (and punch cards before that). Everything is moving more in the direction of even higher level languages (i.e. graphics based).
In the field of embedded controls, everything is being shifted from hand-coded C to auto-coded model-based programming. In my current job and my last job we use
Simulink and
Stateflow to do all of our control design. When I left my previous job 4 years ago, we were already auto-coding the entire sensing and control algorithms from the Simulink/Stateflow models. At my current job, a good number of the control algorithms are already auto-coded from the Simulink/Stateflow models and the goal is for all of them to be auto-coded in the future.
Even for PC programming we're starting to see more graphical programming tools where you draw your windows and drag and drop menus and interface controls, then simply define the behavior of the interfaces and menus.
I don't know if we'll ever completely move away from text-based code (and in some cases, I think text based code is the most efficient method), but it would surprise me if software development was primarily text based 10 years from now.
For the on-topic part: there have been robots in the past that have played significant portions of the match autonomously. I once proposed a system to reward the teams with bonus points based upon how much of the match they played autonomously. I'll have to dig up that old thread and post it.