Rantings and ravings about the typing discipline war
1/20/2020: * There is no known definitive argument on either side that would definitively bury its respective contender. Programmers sometimes seem too afraid of some kind of Tower-of-Babel-effect that would ruin the progress of Computer Science, and I believe that the whole debate around static and dynamic type systems is just a reflex of that. * There is a component of dynamism in every computer system that programmers crave, and it usually lives out of bounds of the language environment, on the operating system level. Static typing proponents seem to be either OK with that or oblivious to that fact. Dynamic typing proponents brag to have this inside their own environment, but don't take any real advantage of that. * From an engineering perspective, it is all about error propagation delays and the costs involved; it is easy to add sound types to your internal logic but a little bit harder at the system boundaries (i.e., this is why we need state-based monads in Haskell, for example). * On that same line, this is the reason why static typing becomes attractive if your problem domain is tractable as a cohesive unit, as dynamic typing does if you decide to model your system out of decoupled units. Communication overheads tend to dictate the preferred approach, even if unconsciously, and this is also the reason why dynamically-typed environments tend to be slower than statically-typed ones. Please notice that (1) this has nothing to do with modularity and (2) there are no hard restrictions on treating your problem the other way around. * "So, give me an example of a thing dynamically-typed languages can do that statically-typed languages can't?" That one is easy. ``` GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Prelude> sayHello = putStrLn messageToBeDefined <interactive>:1:21: error: Variable not in scope: messageToBeDefined :: String ``` There are two possible reactions to the code snippet above: * You propose a statically-typed solution on the grounds of the expected result, which would be to print a given greeting message, oblivious, if not dismissive or outright mockingly, to the fact that dynamic typing advocates are interested in the internal language mechanisms instead. In that particular case, you are taking an [unfalsifiable](https://en.wikipedia.org/wiki/Falsifiability) stance on the problem, which makes any discussion on scientific grounds not only harder, but impossible. * You mention the mechanisms Haskell have which allow you to provide dynamic code evaluation at the expense of missing important features of the programming language, such as type inference, and slightly more verbose code, which is perfectly acceptable. Hopefully, at this point, you will realize that the choice for a given paradigm comes down to personal judgment. 1/21/2020: * People (e.g. me) usually conflate static/dynamic *typing* with early/late *binding*, either due to ignorance or laziness. It is very common that you find early binding on statically-typed systems and late binding on dynamically-typed systems. But binding strategies are not a binary choice: they sit in a spectrum. It is expected that static typing systems introduce the necessity for earlier binding to some degree, because type checks, at least, should be provided ahead of time.