Because often 'static language' is used in place of 'Java'; pretty sure those languages are much more succinct and readable than Java is, thus they're not as likely to become 'large' codebases. I'm probably wrong though.

Whenever I recall programming in Java though, I remember highly verbose, boilerplate-ridden codebases, and bits of code that are little more than abstractions for bits of code underneath them (with unit tests alongside them that test bit of code A calls functions B and C, which of course has no value whatsoever).

Nowadays I do Javascript, much better. Today I frowned upon a colleague who is used to Objective-C who proposed writing documentation. Pfff.

But this is a very big problem. It seems to me that the popularity of dynamic languages recently is almost entirely driven by Java backlash.

So developers with limited experience encounter some big "enterprise" Java code base and recoil in horror. Instead of making the deduction that enterprise Java is terrible, they jump all the way to compile time types being horrible.

Honestly, "statically typed language" often means C#/C++/Java. All languages which trend verbose.

While Scala/Haskell/F#/etc are great at concision, they aren't that common in traditional SW industrial applications.

Modern C# and C++ both have facilities that make the languages much more concise (lambdas in combination with std::algorithm resp. LINQ, type inference and the like). Java 8 will also have some of that and I can see it becoming a much nicer language to work with because of those changes.

Quite correct. But historically - and worse, codebases with a Standard Style that is perhaps older - these languages trend verbose.

IME, I've tried to make super concise modern C#, and it simply isn't concise compared to Haskell or even Python. YMMV, of course.

1. C# is not as verbose as Java and C++. Latest versions especially.

2. C# supports dynamic typing as well as static.

3. C# and F# are the easiest to mix and match within one solution.

> C# supports dynamic typing as well as static.

Are you talking about automatic types? Because that's the only thing that resembles dynamic typing I ever found in C#. And it misses about all the reflection available in most dynamic types languages, thus, even if it's somehow possible to not define types, it's useless.

C# fully supports dynamic types [1] and has very good reflection support [2] since version one.

[1] http://msdn.microsoft.com/en-us/library/dd264736.aspx

[2] http://msdn.microsoft.com/en-us/library/system.type.aspx

Those are 'anonymous' types. I wasn't talking about them.

    ExampleClass ec = new ExampleClass();
    //ec.exampleMethod1(10, 4); // compiler error

    dynamic dynamic_ec = new ExampleClass();
    dynamic_ec.exampleMethod1(10, 4); // runtime error

Well for Haskell and ocaml, it's more the type inference and functional nature than the static typing that saves code.

As for scala, it's not quite as functional or well typed inferred as the others... interested in what the LOC savings would be.

Realistically though what's being compared is Ruby/Python vs. Java. It's much more than just the language it's the culture, java is just plain bureaucratic, a lot of routine paperwork for not a lot of functionality.

I'd say its because its easier to get on with human-friendly abstractions in a dynamic language. For example you spend less time packing structs into something that can be used by a customer with a dynamic language. Things happen faster, if all you've got is a number, string, and table type. So, you end up with abstractions that do more.