Agree on CRUD, but on typing I'm the opposite. Anything sufficiently complex logic, especially etl or projects with multiple models of the same entity, is easier for me in a language with duck typing. It's just amazing how all our brains adapt slightly differently to the different sorts of problems we face and the bag of tricks we use, in addition to the different languages and tools.
Ad-hoc polymorphism (traits/type classes) and parametric polymorphism (generics) largely solves this, whilst giving you a high degree of confidence that your code correct at compile time.
I've found code written in a duck-typed style brittle and hard to refactor safely - it's very easy to try to restructure something, then find out down the line that something blows up because of some incorrect assumptions in another part of the codebase. You can try to grep for all the method usages, but that is a laborious, error prone process in codebases that are sufficiently large enough.
I feel bad for anyone who has to swim in your wake. People who embrace dynamic typing generally create write-only code that no one can maintain, since they labor under the delusion that little things like clarity of purpose are a waste of time.
Duck typing vastly reduces the amount of code one has to write that does nothing, making the purpose of the code much more clear. The tradeoff is in compilation, not clarity of purpose. The code tends to be more flexible to changes in the underlying data, as it is easier to modify!
A sad example of those defending static typing are the Java programmers. I point out that Java supports duck typing via reflection, even if the syntax is painful. They say they don't use reflection, they use Spring. [Head in hands]
In any case, there are many happy programmers in my wake, they don't need your sympathy! :-)
> Duck typing vastly reduces the amount of code one has to write that does nothing, making the purpose of the code much more clear. The tradeoff is in compilation, not clarity of purpose. The code tends to be more flexible to changes in the underlying data, as it is easier to modify!
It's much harder to make changes because even something like renaming a field requires major testing. You end up writing much more code that does nothing, because the test coverage you need for everything is much longer than the type annotations that would give you the same level of confidence, and whenever you change anything you have to update all your tests by hand. Hope you get the data model right first time! Look at one of those videos of people refactoring Haskell for what a type system can get you.
> A sad example of those defending static typing are the Java programmers. I point out that Java supports duck typing via reflection, even if the syntax is painful. They say they don't use reflection, they use Spring. [Head in hands]
If Java is what you think of when you think of static typing, I don't blame you for hating it. If Java-style typing and duck typing were the only options I'd use duck typing. But there are much better options out there. When I write Scala, most of the time my code looks exactly the same as what I'd write in Python.
Yeah, I got my first exposure to the dynamic side of Java half a year ago. Its honestly not that difficult to deal and the shit it can do is pretty silly.
Field field = instance.getClass().getDeclaredField("secretField");
field.setAccessible(true);
System.out.println("The old private value is " + field.get(instance) + " but lets change it!");
field.set(instance, "new value");
