C or LabVIEW: CompactRIO

[dcbrown]

Originally Posted by Dave Flowerday

This is correct from my perspective, and also the very reason why I think it's most valuable that we're teaching C and low-level stuff to the kids interested in software on our team. When you make the bulk of the code easier to write (as graphical tools are starting to do), it becomes a commodity. For these jobs, you no longer need a software engineer to implement them - anyone with a logical mind has a decent chance at being able to do it. Of course, that means that the 10% of programmers out there who know how to get down and dirty with C and/or assembly coding and debugging become more valuable, and the value of the rest decreases. I think it's important that the kids on our team who show real interest in software be steered towards this 10%.

Agreed (not that it matters). In my view this is the difference between an applications programmer/coder and a systems programmer/engineer.

Although I believe there will be parity between LabView and C programming environments for the FIRST added value in the new platform - specifically in terms of the standard sensor suite included in the KOP. I cannot see how real parity will exist in the 2-3 year short term between the two environments. My reasoning is based upon what the customer base for cRIO has been using - only LabView. So the body of art in terms of VI blocks, knowledge, etc. exist only in LabView within the current customer community. That plus the fact that LabView can be used to model a system and provide the simulation of most of the sensor inputs for testing/simulation makes that environment have benefits that the C environment cannot match from a whole program standpoint in the near term.

I don't even like LabView but my opinion is it would be irresponsible for me to not push LabView as the main programming environment for the robot going forward given the functionality and current art associated with the new platform. I could easily envision that 10-20% of the code would still be in done in C just because it fits better, but that the majority of the software team would be using LabView. So this would reflect the typical 80-90% applications programmers and 10-20% of systems programming mentioned by Dave above.

For me, LabView promotes being a user of black box technology pieces rather than promoting understanding how to be a creator of useful technology. There is nothing wrong with being a technology user, but where's the fun in that?