Best way to start?

[Ginto8]

Lessee... Though I don't have a whole lot of practical experience regarding this, I'll put in my 2 cents.

I've been using LV a lot more recently, and it is my opinion that it is very good for rapid development of tools for data display, but not as good for actual program logic. Though that's not to say that you can't have a good bit of program logic in a labview program, it is definitely not one of its stronger points.

For C++, there are some more factors. Do you simply want to be able to put together a program that works, or do you want more reusable code that can easily be adapted to different situations that can come up? For the first option, you don't necessarily need a lot of skill, but if you want the second option (without horribly messing things up), you probably want more than just a few months' experience. I have been working on personal projects using C++ for about 2 years now, and I'm only just starting to really get the hang of what's required for the 2nd choice.

So, in conclusion, if you want an easy-to-learn way to program, that you can put together fairly quickly, go with LV. If you want a flexible, robust way to program - which is used in many practical areas - C++ is, for the most part, the better choice.

[Alan Anderson]

Originally Posted by Ginto8

...I don't have a whole lot of practical experience regarding this...

I think anyone reading the rest of your post should keep in mind that first bit of context.

LabVIEW is tremendously capable of what you call "program logic". It's not even hard to do it. It's simply a different kind of programming from what things like C and Java are designed for. If you're used to procedural programming, LabVIEW will seem difficult until you recognize the "right" way to do things in a dataflow programming language, and then it will become easy.

By the way, LabVIEW too is "a flexible, robust way to program - which is used in many practical areas". Those practical areas just tend not to be the kind of programming one encounters in high school, with NXT G and LabVIEW for FRC beginning to change that.

[Ginto8]

OK, you have a good point. However, when designing robot logic, a more procedural method makes more sense in most cases than a dataflow approach, but insofar as I have seen, LV is simply not as capable with procedural approaches.

[Alan Anderson]

Originally Posted by Ginto8

...when designing robot logic, a more procedural method makes more sense in most cases than a dataflow approach,...

Procedural programming obviously makes more sense to you. It does make a lot of sense to anyone who learned to program using a procedural language like C or Java or even BASIC. But dataflow programming makes at least as much sense to people who know it. I'd even say that a dataflow approach makes more sense than a more procedural method to people with a background in PLC programming or in circuit design.

but insofar as I have seen, LV is simply not as capable with procedural approaches.

You merely haven't seen far enough yet. Give it time.

LabVIEW provides two trivially easy ways to do strict procedural programming (error chaining and Sequence Structure frames), with Case and loop structures able to act just like their procedural counterparts. A moderately experienced programmer can implement a procedural algorithm directly in LabVIEW.

It takes a bit more experience to get to the point of being able to build simple frameworks to combine the best qualities of both the dataflow and the procedure-oriented viewpoints. I think a year of FRC robot programming might be just about enough time to get that experience.