> static typing is for example by definition anti-modularity and anti-adaptability
This is so painfully wrong. Static types are not in the way of modularity and type correct programs are not hard to adapt to another type correct program.
I would say it's the exact opposite. Types are perfectly modular and compose beautifully. Adapting your program's design in a type safe environment is a breeze, because your compiler/types more often than not tell you exactly what you can and cannot do.
And also, imagine trying to build a system that works like our body does, particularly fascinating is the process of wound healing: https://en.wikipedia.org/wiki/Wound_healing
You know, there's a reason for why Akka's actors, a library built for a fairly static and expressive language (Scala), are dynamically typed. Try finding out why that is.
The existence of the Expression Problem is orthogonal to whether or not types promote modularity or not. In fact it has a type-safe solution. I recommend reading through the original post Wadler wrote to get a better sense of what it is saying: http://homepages.inf.ed.ac.uk/wadler/papers/expression/expre...
(There is also a link at the bottom of the Wikipedia article you linked to.)
One can imagine the immune system being a kind of type checker for the body. Is it "static" or "dynamic?" Both! The "innate" immune system is basically fixed at DNA compile-time, while the evolutionarily later "adaptive" immune system is updated at runtime by exposure to pathogens.
I think it's unfortunate that we conflate strong explicit typing with static compilation. Common Lisp, for example, can be seen as statically typed; it can give you compile-time type errors. But you can also recompile at runtime; add new types at runtime; and so on.
Exactly - I did want to express that, forgetting to mention that it's not a black and white issue. I mentioned the healing process as fascinating, because the cells act as independent actors that when the wound happens, they first start arguing against each other, but then they start cooperating to reduce the wound, to provide cover for the new tissue and to form the new tissue. We are far from building systems that are as smart as the process of evolution could build.
Ruby is more dynamic than other languages and that's in a bad sense. I always get a kicker when thinking about the purpose of the "class" keyword, being to open the class context or create the class as a side-effect if it doesn't exist. Ruby is built for runtime mutation of types - which is good in certain contexts, but unfortunately you cannot scope those mutations, leading to the ultimate side-effecting hair ball if not careful about both your code and other people's libraries - it would be useful to say, modify the String type or import this library, but only for this block of code.
Notice how the very definition you give of the Expression Problem has the constraint of "retaining static type safety"?
It doesn't care about dynamic solutions, and they don't capture as much information anyway. Of course you can express anything in a dynamic fashion, in the end assembly is untyped too.
So, if those indeed were "people smarter than you", you didn't understand what they were saying.
I don't get the misunderstand we are having here. I was claiming that static typing has problems with modularity and adaptability because - one reason would be the expression problem.
You're then saying that the expression problem wouldn't exist if dynamic typing is allowed. Well, that was my whole point.
Akka will have typed actor support in future versions. There are obvious reasons why a direct port of code that was originally written for an untyped language (Erlang) would be written in an untyped way.
No, I'm right, because people smarter than me have said it.
Wow. Just... wow. Seriously? No! The expression problem can be solved in Haskell in a straightforward manner using type classes[0].
You know, there's a reason for why Akka's actors, a library built for a fairly static and expressive language (Scala), are dynamically typed. Try finding out why that is.
Because Scala is a crappy, broken language built out of compromises with the JVM? Take a look at Haskell's distributed-process[1] library. It solves the problem that Akka punted on (namely type-safe serialization of function closures).
Akka has to expose the actor registry, has to handle network connectivity issues and scalability issues, which means messages have to go through actors posing as proxies and routers; and actors may be dynamically created - and also because of the async model, actors can and must change/adapt their interface asynchronously, like when doing back-pressure and waiting for acknowledgement that a message was received on the other end, during which there can be no progress, as in "context.become", fundamental for the actor model - which actually renders static typing useless.
Saying that Haskell's distributed-process solves the problems that Akka is solving is short-sighted and wrong. But then again, the main reason for why Haskell hasn't attracted me has nothing to do with technicalities and everything to do with a vocal minority of Haskell users that I find totally repulsive.
> But then again, the main reason for why Haskell hasn't attracted me has nothing to do with technicalities and everything to do with a vocal minority of Haskell users that I find totally repulsive.
This.
> The expression problem can be solved in Haskell in a straightforward manner using type classes.
Lol, WUT? No.
Btw, I think that you are actually trying to lecture Scala people about typeclasses just shows how clueless you are.
This is so painfully wrong. Static types are not in the way of modularity and type correct programs are not hard to adapt to another type correct program.
I would say it's the exact opposite. Types are perfectly modular and compose beautifully. Adapting your program's design in a type safe environment is a breeze, because your compiler/types more often than not tell you exactly what you can and cannot do.