Do dynamic typed languages deserve all the criticism? [closed]

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.

Answer 1

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.

Answer 2

You're giving way too much technical credit to Enterprise decision makers. There is an old saying, "Nobody got fired for buying IBM." If you go a different route and things get rocky (they always do), nobody wants to risk being blamed. Stick to the standards and blame someone else.

There are a lot of younger companies that will eventually become the enterprises of tomorrow and will be using those languages.

And let's not forget the buggillion lines of code written in VBA!

Answer 3

The reason enterprises use C, C++, C# and Java isn't because they are statically typed (at least not directly). Enterprise decision makers aren't making these kind of choices on the basis of an objective comparison of type systems, I assure you.

Enterprises do care about:

• Long term maintenance costs: can you reasonably expect things to continue to work well in 10 years time? It's actually a good thing if language evolution is conservative and backwards-compatible (as with Java). The static typing is helpful here because it catches a major type of bugs at compile time before they get into your production systems.....
• Talent availability - will you be able to find developers to maintain your shiny new system? what if the original developer leaves, will everyone else understand the code? This places a high hurdle on introducing any "new" language (especially if it also creates new requirements for deployment, build systems, operational support etc.). This gives a massive advantages to the languages that are widely used (C, C++, C# and Java)
• Integration costs: is it easy to connect / integrate with other technologies that you already have in place or are likely to acquire? If you already have a stack of legacy J2EE systems then you need to integrate with them. A new Java EE solution is likely to be much more practical for this than e.g. Python.
• Predicatbility / low risk: is the platform / language proven, and can I be sure that it will work? This is usually more important than simple productivity. It's much easier for a manager to persuade his boss to give him a big budget for manpower to build a new system than it is for him to go back later and say that it hasn't worked.....
• Enterprise Backing / support - are major international organisations committed to supporting the language and platform? Will they sign a contract to support me so that I have someone to call on if things go wrong?
• Vendor neutrality / platform independence - am I going to get locked in to a single supplier? Or do I have a wide range of future supplier options / transition paths available? You don't want to be stuck in an architectural dead-end, unable to make progress while your competitors eat your lunch. If you are doing your job properly as an enterprise architect, you need to be thinking at least 5-10 years ahead on this stuff.

Personally, I think that if you want to use dynamic languages in the Enterprise, then your best chance by far is to use something that piggy-backs on an existing enterprise ecosystem. Most notable are the new dynamic JVM languages: e.g. JRuby, Groovy, Clojure. As far as IT management concerned, these are "safe" dynamic language choices because they operate within and play nicely with the rest of the Java enterprise ecosystem.

Answer 4

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.

I think this is only their primary excuse. The real reason is that businesses don’t really take them all that seriously and feel that they are perhaps a bit too amateur. Java and .NET are “big business names”, have good commercial marketing, commercial customer support, and are thus widely taken very seriously indeed.

It is unfortunate that there is practically no statically-typed language that is anywhere near as popular as the big business names. Why are open-source/free-software programming environments almost always dynamically typed? This might indicate that a statically-typed language is actually not that easy to make, and that dynamic typing is a “lazy man’s hack”. If that is the case, the businesses who decide against dynamically-typed languages might actually have a point.

Answer 5

• Dynamically typed languages tend to be slower than their statically typed cousins.
• Errors are harder to catch and can be harder to debug
• The compiler/interpreter tends to be a lot less fastidious about what you can and can't do. i.e., you pretty much only catch syntax errors at the compilation stage
• If you're not very careful with the design of a dynamically typed language, you end up with Javascript, which is the language of code-smells

EDIT: I should mention that my main programming language at the moment is Python, which is dynamically typed. Personally, I love the freedom that comes with not having to pre-declare variables, but at times, it would be nice to specify (for example) what kind of parameters a function takes to catch errors early rather than late.

Answer 6

Dynamically typed languages are perceived (by some programmers/bosses) to produce code that does not work as well. The fact that a dynamically typed program compiles tells you very little about its correctness. The fact that a statically typed language compiles tells you a lot more. (On the other hand, there is still a long way between compiles and does the right thing, so this might be less meaningful then it seems)

Dynamically typed languages are perceived to be scripting languages. You'd never write an application in bash or a batch file. All dynamically typed languages tend to be looped into that category (unfairly).

Dynamically typed languages are slower then statically typed languages. (But we'll see how well work on JIT changes that)

Answer 7

Note: this is mostly subjective and based on my experiences and impressions.

Dynamically typed languages are very different from statically typed languages. These differences probably become more important in heavyweight enterprise software than in most other applications.

Statically typed languages tend to be very prescriptive. A method will only take input that exactly matches its signature. Access levels tend to be very important and interfaces are defined explicitly, with verbose but unambiguous restrictions in place to enforce those definitions.

Dynamically typed languages on the other hand are very much pragmatic. Type conversions often happen implicitly, functions may even play along if you provide the wrong type of input as long as it behaves sufficiently similar. In languages like Python, even access levels will be based on contract rather than technical restrictions (i.e. it's only private because you're told not to use it and it has a funny name).

Many programmers prefer dynamic languages because they (arguably) allow rapid prototyping. The code often ends up shorter (if only because of the lack of type declarations) and if you want to violate proper protocol because you need a quick and dirty solution or want to test something, that's easily possible.

Now, the reason that "enterprisey" companies often prefer statically typed languages is exactly that they are more restrictive and more explicit about those restrictions. Though in practice even statically typed code can be broken by idiots with a compiler, many problems will be much more visible much earlier into the process (i.e. prior to runtime). This means that even if the codebase is large, monolithic and complex, many errors can be caught easily, without having to run the code or send it over to the QA department.

The reason that benefit doesn't outweigh the downsides for many programmers outside that environment is that these are errors that will often be easily caught by thorough inspection of the code or even by attempting to run it. Especially when following a test-driven methodology, these errors often become trivial to catch and easy to fix. Also, with many such companies having a much shorter release cycle, productivity is often more important than rigidity and a lot of (basic) testing is being done by the developers themselves.

The other reason that enterprisey corporations don't use dynamically typed languages much is legacy code. As silly as it may seem to us nerds, large corporations will often stick to solutions that work, even if they are well past their shelf-life. This is why so many major companies enforce Internet Explorer 6 and are so slow to upgrade their OSes. This is also why they will often write new code in "old" languages (e.g. ancient versions of Java): it's much easier to add a few lines of code to an unliving piece of software than to get approval for a complete rewrite in a new language.

tl;dr: static languages feel more like bureaucracy, so enterprisey managers like them better.

Answer 8

No, I don't think dynamically typed languages deserve all the criticism. (Or if you prefer, they deserve as much criticism as statically typed languages.)

In my experience (and I make no attempt at trying to generalise this statement), the programmers who criticise dynamic languages haven't used them. The conversation usually goes "but with static typing the compiler catches so many errors!" and I say "well, that's just not a problem, in my experience". (Usually the other programmer's from a Java, Delphi or similar background; I don't know any Haskell or ML programmers.)

The only thing that really gripes me is when someone claims that technique Foo can't possibly be done (or might be very hard to do) in a dynamically typed language... when that technique was invented in, by and for a dynamically typed language. IDEs? Smalltalk. Automatic refactoring? Smalltalk. Callers-of/implementors-of? Smalltalk.

Answer 9

Enterprises are just not adopting new languages and tools fast enough and there are good reasons for it. But, when one of the mainstream tools like C# implement some of these features, then they will get trickle into the mainstream enterprises ....