Oct 13, 2010 (last update: Oct 14, 2010)
When to use what language and why
Score: 3.4/5 (135 votes)
Its been debated here for the past couple of months what language is "the best" or more appropriately, "the worst" which defines another as better inherently.
Well I'd like to straighten one thing out. There is no best language. There is no best paradigm. There is no best algorithm, method, optimization, technique, ANY OF IT. All good programmers know this, and all real computer scientists know that a language is just a tool in the science of computation. If some one builds a better screw driver, why not use it? Well perhaps this screw driver is only better at getting the job done faster, and not getting it done more efficiently. Or maybe it's great at both of those but the screws are not tightly in the wall because of it. This is comparable to the differences in all computer languages.
So one coder might ask "When should I use "XYZ"?" and when answered they might ask "why?"
I'm here to answer these questions.
When should I use Assembly: You should use assembly when you need the lowest level access to the hardware available. Or when you need to hand optimize things like algorithms and the like. That's not to say you can't use assembly for a desktop application, but it is entirely impractical. As a rule of thumb, use assembly when you need more raw control then you do quickly written and readable code.
When should I use C/C++: Well first of all, c and c++ are both lower level languages, not nearly as low as Assembly but low none the less. Now they are also non garbage collected languages, so you will have to deal with debugging memory leaks and the like, but that presumable flaw is one of the greatest strengths of languages like these. While you may spend more time writing and fixing code then you do optimizing the code, you have the power to optimize it a hell of a lot better than garbage collected code. So anyone who tells you "use java/C#/Scala/etc for you're Kernel/game engine/generic time and resource critical application" because they think you'll get it done faster, and thus make more money because of it, knows nothing about computer science nor economics. Build x number of shitty toys in a month and you're left with a pile of shit. build 1 amazing toy in a month and every one will want your toy...cause come on, who wants to play with a pile of shit?
Now you may think, if thats so why should i ever use languages like java/c#/scala/F#/etc? well the truth is some times you do want to implement faster than you want something to be efficient, and in some cases some of these languages do a better job at both.
So when should I use java: If this wasnt an impartial article I'd say never and leave it at that. BUT this is supposed to be neutral so Java is great for server based applications, as well as client based web apps. It's fast and great with databases, while at the same time having some over head. My biggest problem with java is it's not that great of a language, in fact it's pretty bad. But thats what people get for trying to turn a language designed to teach students computer science and OOP into an industry standard. It was never meant to be what it is today.
What about c#: Use C# when ever you'd think to use java. The way I see it is C# is just like java...except it works.
how bout functional paradigm languages like F#: you want to use languages that are functional when you need more platform independence. Functional languages make it easier to process your algorithm, method, function, etc independent of thread of CPU. It's great for multiple platforms, and multiple threading. This is also why scala excels at these things.
So all things considered you need to remember one thing when programming. It's not about finding the best tool out there and sticking to it like it's dogma. It's really about finding the best technique to learning how use these tools so you can have a full toolbox when it comes time to build your software.
Edit: I was late for class and forgot to add a "will add more later" and remove the above section.