I have read a few articles on Internet about programming language choice in the
ID: 639199 • Letter: I
Question
I have read a few articles on Internet about programming language choice in the enterprise. Recently many dynamic typed languages have been popular, i.e. Ruby, Python, PHP and Erlang. But many enterprises still stay with static typed languages like C, C++, C# and Java.
And yes, one of the benefits of static typed languages is that programming errors are caught earlier, at compile time, rather than at run time. But there are also advantages with dynamic typed languages. (more on Wikipedia)
The main reason why enterprises don't start to use languages like Erlang, Ruby and Python, seem to be the fact that they are dynamic typed. That also seem to be the main reason why people on StackOverflow decide against Erlang. See Why did you decide "against" Erlang.
However, there seem to be a strong criticism against dynamic typing in the enterprises, but I don't really get it why it is that strong.
Really, why is there so much criticism against dynamic typing in the enterprises? Does it really affect the cost of projects that much, or what? But maybe I'm wrong.
Explanation / Answer
Yes, I believe that they do.
There are a few reasons that need to be considered in the selection of a language for a new project:
Run-time speed. Compared to C/C++/Fortran, Perl and Python are so slow it's funny.
Initialization speed. Compared to the above fast languages, Java falls over and cries as the JVM keeps loading and loading and...while(1)....
Prototype-ability. Exhaustively going through and doing the declaration/definition work required for C++ or Java increases the LOC, which is the only known metric that reliably correlates with bugcounts. It also takes a lot of time. It also requires a bit more thinking about types and connections.
Internal fiddlability. Dynamically messing around with your internals is great until you begin to debug your self-modifying code. (Python, Lisp, Perl)
Correctness verification. A compiler can provide a quick once-over pass of semi-correctness of your code in C++, and this can be really nice.
Static analysis details. C and Java have pretty good static analysis. Perl is not completely statically analyzable at a theoretical level (Possibly Python too). I'm reasonably sure Lisp isn't either.
Weird platforms only take C, in general.
Support chain. If you can have a contract that you will get your bugs looked at and worked on, that's huge.
If you can presume that the organization you are working with has a principle of "Going forward"(There's an accounting term for this), and won't just randomly decide to not work on the software, then you have a much better case for using the software. Since there's no Major Business selling (carrying implication of taking responsibility of maintaining it) Python/Perl/$dynamic_language, it considerably reduces risk.
In my experience, open source maintainers often have an issue with fully taking responsibility for bugfixes and releasing updates. "It's free, YOU work on it!" is not an answer that is acceptable to most businesses (not their core compentencies, among other things).
Of course, I'm not talking about the webapp/startup world, which tends to play by high risk/high reward rules and be very open to staying on the frothing edge of tech.