35

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.

Improve this question
9
  • 3
    I think that static typing with type inference and possible duck typing is the best possible way of doing things. It is also very complicated
    – Casebash
    Sep 2, 2010 at 23:23
  • 2
    I just had a look at C#'s duck typing (I don't use the language), and while it seems to fullfil the definition of duck typing, the verbosity required seems to defeat the purpose. That's not to say that it isn't occasionally useful though.
    – Chinmay Kanchi
    Sep 3, 2010 at 9:59
  • 3
    Is it just me or are there more criticisms of statically typed languages than dynamically typed ones? Also, in my experience, the languages/technology choices of large "enterprises" seem to be dictated by current trends/safe choices rather than any real technical merit.
    – MAK
    Sep 19, 2010 at 17:10
  • 2
    @ChinmayKanchi: Verbosity? You just declare something as dynamic and start using it. It's no more verbose than normal method calls or operator overloads.
    – Joey
    Nov 8, 2013 at 5:57
  • 5
    I can't count the number of hours I've wasted at my current company debugging errors in Groovy on Grails code, which the compiler would have detected immediately had we used Java.
    – W.K.S
    May 11, 2014 at 11:20

9 Answers 9

Reset to default
47

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.

Improve this answer
17
  • 16
    "It's free, YOU work on it!" <-- Biggest problem with F/OSS in general, I'd +1 but I'm out of votes :(
    – Billy ONeal
    Sep 18, 2010 at 16:04
  • 4
    Nice summary. I'll tack on that well-constructed types convey semantic meaning (I can look at a type and understand what it does, how it can be used) and can be used to enforce correctness (I can build a type that only accepts constrained inpus), and I do not get dumb errors from typos (I hate auto-variable declaration)
    – smithco
    Mar 5, 2011 at 18:29
  • 4
    You can get commercial support for any major open-source project. Big companies use dynamically typed PL for big parts (sure suitable ones), Facebook uses PHP (UI) and Erlang (chat), Twitter uses Ruby (UI), Google uses Python (I do not know for what) and Lisp and Python are being used in many sophisticated research projects. Note: I am a C# developer I (almost) never used a dynamically typed language; yet these points do not stand valid to a considerable extend.
    – Kaveh Shahbazian
    Dec 14, 2012 at 21:11
  • 4
    I like your answer but Java isn't dynamically typed...
    – user541686
    Mar 24, 2015 at 6:51
  • 2
    @PaulNathan: You're thinking too hard. The question was asking about dynamically typed languages, and this answer mentions Java as though it's dynamically typed.
    – user541686
    Mar 24, 2015 at 21:30
24

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!

Improve this answer
2
  • 1
    +1 for "...the enterprises of tomorrow [and] will be using those languages."
    – rdmueller
    Sep 20, 2011 at 7:36
  • 6
    "There are a lot of younger companies that will eventually become the enterprises of tomorrow and will be using those languages.": You seem to imply that dynamic languages are rather new and need time to be adopted by more companies. On the other hand, dynamic languages have existed for a long time already.
    – Giorgio
    Dec 30, 2012 at 17:55
19

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.

Improve this answer
1
  • 1
    I can't believe nobody upvoted your answer yet.
    – Sebastian N.
    Mar 16, 2013 at 10:24
11

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.

Improve this answer
9
  • 8
    Really? Last I saw, Google had thrown quite a lot of weight and a substantial development effort behind Python, including hiring Python's creator and allowing him to spend 50% of his time working on the language. Google also contribute a good amount of code to Python, especially now that unladen-swallow has been merged into the Python 3 source tree. That makes Python a "big business name" to me.
    – Chinmay Kanchi
    Sep 3, 2010 at 0:00
  • 13
    @Chinmay Kanchi: Interesting how you draw your conclusion from a statistic with a sample size of 1.
    – Timwi
    Sep 4, 2010 at 20:34
  • 6
    Touché. However, some of your conclusions are flawed as well. Properly implementing a dynamic language is far more difficult than implementing a statically typed language. Dynamic typing is certainly not a "lazy man's hack" as you put it. It allows developers to be lazy, but not the person who writes the compiler/interpreter. In fact, optimizing a dynamically typed language is so hard that I can only think of one language that has, in recent times, received this treatment extensively (JavaScript), though there are optimization/JITting projects for other languages (Python, PHP).
    – Chinmay Kanchi
    Sep 4, 2010 at 22:13
  • 2
    Also, if you think dynamically typed languages are the most commonly used in open-source environments, this is far from clear-cut. Depending on the metric you choose, this might be true, but it often isn't. Measuring lines of code, C wins by a long shot. If you measure what languages are used in open-source projects, including multi-language ones, the most popular languages are JavaScript, C, C++ and PHP in that order. If you only measure the primary language, the most popular languages are Perl, Java, C# and JavaScript. bit.ly/C6xTB
    – Chinmay Kanchi
    Sep 4, 2010 at 22:17
  • 7
    Of course writing an optimizer for dynamically-typed languages is hard, but not an interpreter: you can do away with all type-checking, and the rest is the same. No amateur language maker thinks of writing an optimizer. — Regarding the last bit, I didn’t mean to imply that most open-source software is written in a dynamically-typed programming language, but rather that most open-source programming languages (I said “environments” because I’m talking about compilers/interpreters, IDEs, etc.) are dynamically-typed.
    – Timwi
    Sep 5, 2010 at 13:42
9
  • 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.

Improve this answer
3
  • 1
    While its true that the compiler isn't fastidious, the interpreter usually is. For the most part, the interpreter detects problematic situations and signals errors.
    – Winston Ewert
    Sep 14, 2010 at 18:03
  • 17
    I love dynamic typing but I hate not having to predeclare variables! So many times I end up accidentally introducing a new variable because I misspelled a variable name.
    – Frank Shearar
    Sep 18, 2010 at 5:30
  • 2
    @Frank: I unprintably love that Perl has a setting to force variable declaration. It's one of Perl's advantages, in my opinion.
    – Paul Nathan
    Sep 19, 2010 at 15:00
8

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)

Improve this answer
12
  • 2
    "Are perceived by" some programmers. When I have arguments with programmers about dynamic typing, they usually end up admitting that they've never actually used that kind of language.
    – Frank Shearar
    Sep 18, 2010 at 5:29
  • 1
    @Frank are you saying that people who argue for the inferiority of dynamic typing generally haven't used it?
    – Winston Ewert
    Sep 18, 2010 at 15:58
  • 3
    @Frank: I have used that kind of language, and most of the time the result has been unmaintainable mess. (To be fair, it was PHP, and PHP has other problems besides dynamic typing)
    – Billy ONeal
    Sep 18, 2010 at 16:02
  • @Billy: I think this is common. I was down on dynamic typing for years because of my experience with VB - when eventually I realized that this terrible, schizophrenic implementation of dynamic typing wasn't typical, my opinion changed dramatically.
    – Shog9
    Sep 18, 2010 at 16:15
  • @Winston: I'm saying that the people with whom I've argued haven't. It's been a case, for me, "dynamic typing can't possibly work"... but they'll happily use many techniques first developed in, by and for dynamic languages (IDEs, refactoring, off the top of my head). Also, questions like this: stackoverflow.com/questions/2317579 indicate that while probably not universal, my case of arguing with it-can't-work-but-I-haven't-tried programmers isn't isolated. (Me, I think both approaches have value.)
    – Frank Shearar
    Sep 18, 2010 at 19:01
8

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.

Improve this answer
4
  • 3
    Languages with loosy-goosy typing rules create many opportunities for things which are wrong to kinda sorta work. In JavaScript, for example, passing a number to code which expects a string will often behave as though one had passed a string representation of that number, but not always. Trying to e.g. append 456 to 123 won't yield 123456, but will instead yield 579. Unless it's clear who's responsible for number-to-string conversion, it may either be done redundantly or fail to get done at all.
    – supercat
    Sep 28, 2014 at 22:44
  • 1
    @supercat, I think PHP and JavaScript are good examples for the two ways of dealing with that issue (with regard to operators): in PHP operators are unambiguous - + takes numbers and adds them, if you want concatenation you need to use .; in JS both operations share the same operator - if you don't know how your values will behave you're expected to convert them explicitly. Of course this also has to do with loose typing vs strict typing (Python is even stricter), but basically you have to either make sure your values have the right type or make your operations enforce the expected types.
    – Alan Plum
    Oct 2, 2014 at 22:45
  • 1
    I'm not very familiar with PHP, but it sounds like it uses what I would call the "right" approach. Javascript is IMHO abominable in many ways, but I think the behavior of "+" is one of the worst. Actually, I'm not convinced that loosy-goosy dynamic typing would have much advantage over a stronger type system that allowed an interface to declare that things of some other class or interface type should be regarded as implementing or deriving from it, with specific rules about how claims would be prioritized. The big limitation I'm aware of with present structurally-typed frameworks is that...
    – supercat
    Oct 2, 2014 at 22:53
  • 1
    ...if two people independently develop similar interfaces, there's no way for a third party to write code that can use them interchangeably. If a third party could define a new interface and declare that implementations of either or both of the existing ones should auto-implement the new one (using wrappers supplied in the new interface if needed) I think that would handle 99% of what is semantically good about dynamic typing.
    – supercat
    Oct 2, 2014 at 22:55
4

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.

Improve this answer
2
  • I didn't want to clutter up my answer with my personal stance, which is this: right tool for the right job. Whatever kind of language you use is better suited for some tasks, and worse suited for others, than another kind of language.
    – Frank Shearar
    Sep 19, 2010 at 12:55
  • 7
    When the other programmer comes from Haskell, he/she already knows it is the superior language to both Java and dynamic languages ;)
    – Andres F.
    Feb 20, 2013 at 16:04
0

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

Improve this answer
2
  • I don't know why this was downvoted, but it's an insightful statement. Enterprises are slow and conservative. People also prefer gradual change (like the dynamic keyword in C# which lets you occasionally use dynamic typing in a statically typed language) to sudden change (like Ruby).
    – Kartick Vaddadi
    Apr 23, 2016 at 6:35
  • @KartickVaddadi this was probably downvoted because it implies that dynamic typing is a new feature that statically typed languages haven't caught up with yet. not only is this wrong, there is also no explanation why this would be the case. it doesn't answer the question
    – symbiont
    Apr 23, 2021 at 2:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.