![]() |
Re: Preferred Programming Language
Quote:
LabVIEW: Industrial hardware. Primarily used in (non-SW or borderline non-SW) engineering roles. As a SW person, it has the least utility (in terms of usage in SW roles). C++: High performance, high throughput computing. Used in low level (firmware), low latency (market trading, game dev), large calculation (ex. CAD, High throughput computing, supercomputers), and other projects that require the strength of C++. Also used in many other scenarios such as general business applications (usually "legacy" projects at this point), and mobile apps (cross platform ironically enough). Java: General business applications, "enterprisiey" systems, web-backend code (sometimes), Android. C#/.NET: Similar to Java, but more web-backend and lacks Android (w/o Xamarin tools). Some game dev with Unity engine. Python: General business apps, utility scripts, some large calculation (with numpy), web-backend code. There are many other categories I haven't covered, but this is a general idea. Basically, everything but LabVIEW will be great experience for a wide variety of programming careers. Of the current languages, C++ is the only one that will get you into the embedded firmware, high throughput computing scene, but Python is making some gains in some of the C++ space (not much in the real time systems or top tier game dev though). |
Re: Preferred Programming Language
I would recommend trying python first, since it is the easiest language to learn and use (Plus it's waay easier to do networking in if you want to use a co-processor for openCV).
My next recommendation would be C++. The reason why most people tend to go for java over C is because java tends to be more simplified than C. However because of the WPIlibs libraries it is just as easy to use java as it is to use C. C is easier to use for networking that java (Surprisingly). |
Re: Preferred Programming Language
LabVIEW. Why? If your team is small, like ours, and has only 2 or 3 programmers, then it is easier to train each new programmer with it. That's the sole reason.
Honestly, the visual does get kind of messy. I, personally would love to see us use Java in the future for the "easier to keep neat" part. And I'd love to start moving programmers straight to a very necessary language. |
Re: Preferred Programming Language
Quote:
Eclipse can pick up on almost every single syntax error quite easily. I've dealt with issues such as users putting a space in front of their variable names in Labview causing them to fail for seemingly no reason. Labview has no advantage in this field. |
Re: Preferred Programming Language
Quote:
|
Re: Preferred Programming Language
Quote:
Quote:
Quote:
Quote:
|
Re: Preferred Programming Language
Quote:
If your LabVIEW code is getting too messy for your tastes, you're likely trying to do more in one place than you ought to. Keep unrelated things separate, and use subVIs to encapsulate specific functionality. If you're good about using the graphical nature of the language, you can usually manage not to have a VI spill past the edges of the screen. |
Re: Preferred Programming Language
Quote:
Then it would work over SSH :) |
Re: Preferred Programming Language
Quote:
Second: LabVIEW is extremely proficient at not just detecting syntax errors, but at preventing them in the first place. If you're talking about labels used in the RefNum Registry, then you have a point, but claiming "seemingly no reason" is overblown. A misspelled string passed to a RefNum Get function will give a distinct error. In the typical TechnoKats robot code, each resource name exists only once in the entire program (it wouldn't have to exist at all if it weren't required in order for Test Mode to work properly). The problem of spelling a name two different ways simply does not occur. I know of at least three ways to do this, each with its own tradeoffs among such things as quickness of setup, speed of use, and simplicity of making major changes. |
| All times are GMT -5. The time now is 19:21. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi