Re: Getting Dynamic Productivity in a Static Language
Posted: Mar 31, 2009 3:11 AM
> >> While I agree with the specific examples you give, it
> >> doesn't change that the conceptual simplicity of
> >> learning the language itself is greater when you have
> >> the Smalltalk/Ruby/Python/Groovy etc. model of method
> >> invocations are messages sent between objects.
> >> ...
> I'm not feeling it. How does "message passing" simplify
> the mental model? A programmer still needs to understand
> the concept of types, even if they are dynamic. Do I not
> have classes in Ruby? Are there not function types as
> well? That's the rub. A dynamic type system has types, but
> you are not supposed to admit that in your programs.
> Somehow you are supposed to know what "messages" are ok to
> send and what type of information should be in them. Call
> me crazy, but I think it's beneficial to have a
> declarative type system around to help me (and my tools)
> with these things.
Well maybe I'm wrong about this. What "simple"means isn't so easy to get at. But one example is collections. When you use dynamic typing, you can put anything into a collection, then take it out and call anything on it. If the thing you pull out has the method you call, it will work. Else it will throw an exception at runtime. That's about all you need to explain it.
Now when you go to static typing, you'll find you want to talk about type parameterization. In Python a list is an ordered sequence of elements. In Scala, a list is an ordered sequence of elements of a particular type.
List in Scala therefore takes a type parameter, for example, a
List[String] would contain strings. This not only enforces that only strings go in there, but more importantly makes it possible to statically invoke string methods on the objects you pull out of it. So already it is a bit more complicated, but the plot thickens.
At some point you may have a
List[String] and want to pass it to a method that takes a
List[Object]. Can you? Well that brings up the question of variance. It turns out that you can in this case, because
List in Scala is covariant in its type parameter. But there are also nonvariant type parameters, where there is no inheritance relationship provided by the type parameter, and contravariant, where the inheritance relationship is upside down. So this adds more complexity to understanding the language, even though this bit of language complexity here may actually simplify your life later when you're trying to refactor a program.