I think, especially in programming language communities, that there tends to be a preference towards making a static language for their compile time guarantees, and this is a pretty concrete counterargument as to why people find dynamic languages “easier to program in”
It’s amazing the person who has the blog is only 18 years old, and he is writing about very abstract concepts. I am following him since he was 16, and I see a lot of potential in there.
Also, I don’t agree with some of the points he raised there, but hey, when I was 18 (or 16) I was far away from his level of understanding. Things started to click for me when I was in my early 20s, not 16.
You know, I wasn’t that impressed by this article, but I am coming around to your point of view given that additional context.
I have mixed feelings about the blog post. I don’t think it is wrong per se, but I think this text conflates language features that are orthogonal too much. The initial description of the problem is good, explaining what is meant by inconsistency and feature biformity. But there’s a lot of things after that I just don’t agree with. Maybe there’s some different core assumptions to start with we disagree on.
But in the end, different tools require different features. Programming languages are tools. There’s no one-size-fits-all solution to every use case.
I do not understand “counterargument” here either. Counterargument for what? I don’t think anyone suggests that choice of typesystem isn’t a tradeoff.
Maybe not here, but I tend to get the feeling that the argument for static typing goes “it may look harder than dynamic types, but it’s really not that bad”, where as this article shows some more concrete disadvantages of static type systems
There is no meaningful debate if static or dynamic systems are better. It’s a tradeoff. And as such, arguments either for or against make little sense if the context about the situation they were designed for is ignored or left ambiguous.
Would have been a lot better if printf() wasn’t used as an example. That’s like justifying DI or AOP with mocking frameworks or logging or justifying closures with shitty hacks you do to make the JS experience 10% less painful. Or macros justified with DSLs. Reflection justified with serialization.
Very long and a little bit of tricky read but certainly interesting observations. As a Scala developer I actually see the problem with static vs dynamic code all the time. A desire to force everything into the static type system so errors are found early is commemerable, but even in places it doesn’t necessarily make sense. A common example is taking user input and shoving it in a cats
NonEmptyList. A type which exists soley so that calling.headwon’t cause an exception. Apparently using.headOptionis a deal breaker. The other place is the desire to serialise classes into json structures automatically. This is again commendable and makes programming much easier in some constraints, but it then remanifests as a problem when you realise that internal types and external types need to diverge in some way. At runtime it’s easy to change mappings between two arbitrary structures and you can inspect the data, but trying to do it via the limited language exposed by a macro is painful.I agree with your second point but not the first, because presumably the code processing user input has a better idea of what to do if the input is invalid because it is an empty list then some other random part of your program that requires a non-empty list but finds out that it has been given an empty list instead.
