> This is my bet: the age of dynamic languages is over.<p>I doubt it.<p>Yes, all the points the author makes are valid benefits of static typing. But the benefits of dynamic languages still exist. There are reasons people like both types of languages.<p>However, I think a more relevant point was made in the article: that statically-typed languages are looking more and more dynamic. And we can add to that that we see signs of dynamic languages adding more 'static' features, like optional types. Those are signs of convergence, of both major classes of languages learning from each other and improving.<p>But I still don't think we'll end up in the middle with "static, but feels totally dynamic". We'll still have both types of languages around.
The author seems to have missed the Ring Spec [1]. It provides a complete breakdown of what is in a ring response and a ring request for the core spec.<p>The middleware (at least those that ship with ring) are all documented in docstrings explaining the keys they add or work on. This is available in the repl via `clojure.repl/doc` or inspective `(:doc (meta foo))`. It's available in your editor if your editor has clojure support (I only use vim and emacs, and both of these can search/display docs on clojure code). There is also nicely formatted api docs at [2].<p>[1] - <a href="https://github.com/ring-clojure/ring/blob/master/SPEC" rel="nofollow">https://github.com/ring-clojure/ring/blob/master/SPEC</a>
[2] - <a href="http://ring-clojure.github.io/ring/index.html" rel="nofollow">http://ring-clojure.github.io/ring/index.html</a><p>That said, it would be nice if more of clojure was documented using an executable schema or type system, ala Schema or core.typed. The author would have done well to pick less well-documented libraries though.
Totally agreed, using dynamic languages, all became a guessing game, everyone is guessing, the IDE is guessing, the programmer is guessing what's inside this variable?
I agree with the author. Even in a "statically typed" language like Go, which has a simple type system, compared to languages like Scala or Haskell, the benefits of static typing are very real and enables a lot of extremely useful tools (code completion, refactoring, linting, whole program analysis, etc.).
A completely contrary case can be made where static typing is doomed because hardware is getting more and more powerful, JIT and tracing is getting better and dynamic typing is convenient to the programmer while static typing is very convenient to the compiler and the processor.<p>It's nonsense, both ways. Both static and dynamic type systems have their uses and, unless we substantially change the way we use computers (which is plausible) I don't see either side wiping out the other.
A note on Typed Clojure: Ambrose is doing excellent work with it, and I'm excited to see it develop.<p>But I wished there was a bigger push from the top, from Rich himself, on "first-classing" typed Clojure. Aim for 100% annotation coverage for the most popular libraries. Start with core (maybe it already is? I haven't kept up) and ring, then move outwards from there.<p>Library writers will be more motivated to add annotations if the big libraries are doing it.
I don't like when people don't understand the difference between dynamic languages and so-called dynamic typing.<p>For example in Java a dynamic feature is that it has class loaders which enable to load classes into a running Java program. This way a program can be updated and extended at runtime.<p>Other dynamic features are 'late binding', runtime evaluation, code as data, introspection/reflection up to a full blown meta-object protocol which enables things like modifying inheritance, slot allocation, instance creation, method dispatch and so on.<p>One of the features of Erlang for example is that it enables application updates, while providing zero downtime. The demand for that in the telco business is far from 'end'ing.<p>What actually 'dynamic typing' is and if it is seeing its end is a totally different question.
I agree. Dynamic languages had their appeal when the only mainstream alternatives were Java and C++.<p>But in today's world, with verbosity-eliminating type inference, more expressive type systems, and tools that can make use of all the extra information to greatly increase productivity, it's really hard to think of any meaningful benefit dynamic languages can provide (that is related to their choice to have dynamic typing, not other parts of the language).
> that we disdain verbosity<p>Dynamic languages show there's a tradeoff. Repeating yourself is often useful, when maintenance is expected and code is cheap to produce, without having to worry about strict typing.