Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Preferred Programming Language (http://www.chiefdelphi.com/forums/showthread.php?t=138935)

jkoritzinsky 13-03-2016 23:53

Re: Preferred Programming Language
 
Quote:

Originally Posted by Jaci (Post 1556611)
Guys, all we're doing now is discussing edge cases that can affect a programmers experience. To any outside observers viewing this thread, we're just confusing them more.

The answer isn't as simple as "in 0.1% of cases, this will happen in X language, so therefore, you MUST use Y language". The answer to the question "which language should I use" isn't black and white. Each language has its own pros and cons, and where it fits in in the grand scheme of thing. If they didn't, we wouldn't have thousands of different languages in existence today.

Referring back to OP, they want to know what language will prepare you for the real world, not which language is easiest to learn. You don't do FRC because it's easy to learn, it's hard to learn, hence "Hard Fun". If you want to be good at something, it will take hard work. If you want to be prepared for the industry, it takes hard work.

Let's try not to deviate from the question and answer what the OP wants to know, and hopefully, the reason most of you are here - what will prepare you for the future industry?

From my limited experience, here's what I've realized about each language. I am probably wrong somewhere in here, so please correct me if I am.

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

ProfessorAlekM 14-03-2016 08:12

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

Hitchhiker 42 14-03-2016 08:38

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.

Arhowk 14-03-2016 09:21

Re: Preferred Programming Language
 
Quote:

Originally Posted by wt200999 (Post 1556595)
Sounds like a great reason to use LabVIEW!


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.

jdaming 14-03-2016 11:54

Re: Preferred Programming Language
 
Quote:

Originally Posted by Arhowk (Post 1556723)
Labview has no advantage in this field.

This is completely untrue and shows your lack of understanding. I use LabVIEW often in my Automation Engineering job and it has many advantages to traditional languages you just have to understand what those are (as many people have listed in posts above). I have experience with all three of the supported languages and python (never on a robot just in home use) and can certainly say that all of them have advantages and disadvantages, learn what those are and make an informed decision.

Ether 14-03-2016 12:42

Re: Preferred Programming Language
 
Quote:

Originally Posted by Spoam (Post 1556544)
The flexibility to use robot code written by a novice without worrying that a syntax error will cause a heap corruption

Quote:

Originally Posted by wt200999 (Post 1556595)
Sounds like a great reason to use LabVIEW!

Quote:

Originally Posted by Arhowk (Post 1556723)
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.

Quote:

Originally Posted by jdaming (Post 1556831)
This is completely untrue and shows your lack of understanding. I use LabVIEW often in my Automation Engineering job and it has many advantages to traditional languages you just have to understand what those are

Without making any judgement either way regarding the claim in Arhowk's post, the phrase "in this field" in context seemed to be narrowly referring to syntax checking only.



Alan Anderson 14-03-2016 16:17

Re: Preferred Programming Language
 
Quote:

Originally Posted by Hitchhiker 42 (Post 1556706)
LabVIEW...
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.

How would you keep a text-based language neat? Unless you're talking about the formatting of indivicual lines, you can probably do the same sort of thing in a graphical language.

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.

techhelpbb 14-03-2016 16:26

Re: Preferred Programming Language
 
Quote:

Originally Posted by Alan Anderson (Post 1557063)
How would you keep a text-based language neat? Unless you're talking about the formatting of indivicual lines, you can probably do the same sort of thing in a graphical language.

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.

LabView UI in TUI?
Then it would work over SSH :)

Alan Anderson 14-03-2016 16:35

Re: Preferred Programming Language
 
Quote:

Originally Posted by Arhowk (Post 1556723)
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.

First: if you're talking about LabVIEW variable names, I'm going to assume you don't know what you're talking about.

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