Java and C# are not silver bullets. The languages are good solutions to a certain class of problems, using them for problems that could be better solved with a different language stagnates the growth of other languages.
Now I am wondering: Is a general programming language really predestined for certain kind of problems and not suited for other kind of problems?
I can see that performance could be an issue. But apart from that, is the problem domain really a relevant aspect for choosing a language?
I could agree that platforms and frameworks could be targeted a certain problem domains, but I cannot really see if this is true fro languages. I also think reality shows that the same kind of applications can be solved with all kind of languages, and the results are equally valuable.
I think there are much more important influences for choosing a language than the problem domain. Like experience of the team, available knowhow and infrastructure, reusing investments and creating homogenous environments ...
Can anybody explain to me how the problem domain is relevant for choosing a general purpose language? I would be very much interested in examples ...
I agree that DSLs offer a whole new perspective on this topic, but we are talking about general purpose languages here ...
I also agree that there are niche problem domains (like scientific calculations) that could certainly better solved with special languages, but again, we are talking about general purpose languages ...
I guess you wouldn't write a web app in C.
ReplyDeleteBut then you could say that C isn't general purpose.
So in that sense, with general purpose being "languages that have similar qualities" then sure, they will be about as viable as each other.
But that's just a generalisation and in some cases one "general purpose" language will be better suited.
It's all about the concepts which the language bases itself on and the way that people think about problems.
ReplyDeleteI think the easiest way to see this is a (somewhat contrived) example. Imagine there are two languages, which run equally efficiently for equivalent problem specifications. The first one is basically just C; its conceptual model matches the way the hardware it runs on fairly closely. The second is something like Haskell; most of its concepts come from mathematics and formal computer science, and as such it places fairly strong restrictions on what you can and cannot do.
Both of these would be capable of calculating whatever you wanted (assuming they're both Turing-complete), but the C-like language would be better suited for tasks that require knowledge of the hardware (systems programming) while the Haskell-like language would be better suited for mathematical/theoretical type programs. (The difference between two C-like languages would be negligible, assuming equivalent libraries and efficiency.)
Both would work for other things, of course, but they may not be as nice to use.
(I posted this here as well.)
"I guess you wouldn't write a web app in C."
ReplyDeleteIf I were a development manager and had a team of 50 C programmers and needed a web app, I probably would.
But since now I have a team of Java programmers, that means I'm not going to have projects built using Ruby, or anything else because of support issues.
Is the problem domain really a relevant aspect for choosing a language?
ReplyDeleteYes, of course, it follows from information theory.
If programmer time is money, then shorter programs are better programs. ("Shorter" should in general mean quicker to write, easier to understand, less maintenance, etc.)
Let's say particular programming idiom ends up being frequent in your problem domain. If a given language L can represent that idiom in fewer characters (or lines of code, or conceptual complexity, or whatever measure you want to use) than its competitors, then it should follow that a typical program written in L would be shorter. The principle is very similar to Huffman coding.
For a concrete example, consider string processing -- you can write an awk or perl program to perform a given text munging task in a small fraction of the time it takes to write it in something like Java.
"But since now I have a team of Java programmers, that means I'm not going to have projects built using Ruby, or anything else because of support issues."
ReplyDeletewould you consider using something like clojure or groovy, considering it could interoperate easily against your codebase and would have higher productivity?
I think very concurrent applications are a great problem space that OOP languages seem to fall short in, while FP languages seem to be better geared for the task.
ReplyDeleteBuilding a language for a specific problem domain will naturally give it advantages.