|
There are basically not many conclusive and reliable studies out there that would show empirical evidence for or against dynamic or static languages (software engineering is not even a social science in this respect, i.e. psychology and sociology are more empiric than us). From my personal and anecdotal evidence, I would say that dynamical languages are on average a good choice in terms of productivity. More or less, Smalltalk and Lisp have explored that design space and we have a fairly solid understanding of what a good dynamic language looks like (basically, most of them really look all the same if you look beyond the syntax). There are established practices and resources. I would even go so far and say that with dynamical languages - even though they are highly flexible - we have a pretty homogeneous situation. The most important differences between let's say Ruby, Python, Javascript and Clojure is in the ecosystem (libraries, etc). So I say: So dynamic languages are this robust and reliable family van. With statically typed languages the situation is not so homogeneous. The selling point of statically-typed languages is that they can give you compile-time guarantees. Yet we have expressive and non expressive type systems. Languages that only allow for simpler types (golang), for complex types (ML/Haskell, and Rust which is simpler in terms of polymorphism yet more complex because it has these lifetimes). What I am trying to say is that already when speaking about expressivity, there are differences in statiically typed languages that are pretty huge. Yet they don't map 1:1 to productivity. I don't think there is a language better suited for compiler-writing than Haskell, yet it will be an unproductive language when I use it as a replacement for shell-scripts (or Python scripts that do shell script tasks). And I frankly don't know if Golang would be the right tool for this (if I had the choice between Golang and Python for writing a compiler ,I would probably choose Python). When it comes to a CRUD application, it probably is not so much a question of which language you pick for implementing it, but for how well you understand the patterns (MVC, etc) established for CRUD applications, how nice the ecosystem supports you (libraries, frameworks, etc) and how well you write your tests. |