(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Monday, February 12, 2007
A complete pain
I’m not against types, but I don’t know of any type systems that aren’t a complete pain, so I still like dynamic typing.
—Dr. Alan Kay on The Meaning of “Object-Oriented Programming”
Comments on “A complete pain”:
<< Home
The usual retort to someone who complains about static typechecking is to ask if they've tried ML. You trade type errors at runtime for the occasional incomprehensible message from the type inference engine.
Dynamic typechecking comes with its own pain, though: dumb type mistakes that you only find out about at runtime. For me, it's all about time. If you write some code and can test it immediately, then why not check types dynamically? If you write some code and then have to wait (say, for a slow compiler), then you probably want to rule out a large set of type errors statically.
Dynamic typechecking comes with its own pain, though: dumb type mistakes that you only find out about at runtime. For me, it's all about time. If you write some code and can test it immediately, then why not check types dynamically? If you write some code and then have to wait (say, for a slow compiler), then you probably want to rule out a large set of type errors statically.
The usual retort to someone who complains about static typechecking is to ask if they've tried ML.
I love The Little MLer, it has been a terrific introduction to thinking in types.
I have a gut feeling that it comes down to designing type systems against designing code systems. If what you're doing has a well-defined ontology, a proper static typing system will help.
I usually insert something about Java having a brain-dead type system in comments like this. The problem is that Java programmers who have not been exposed to more sophisticated static typing systems have no idea what I might be talking about: they get static vs. dynamic, but assume that all static systems work like Java (modulo inference).
My plea to anyone reading this who is used to Java, C#, and/or C++ is this: please look into ML, Haskell, or Ocaml. Ignore the functional stuff if you like. Ignore the inference stuff if you like. Look deeply into the flexibility of the type systems backing these languages. Don't let go until you experience the Aha!
I love The Little MLer, it has been a terrific introduction to thinking in types.
I have a gut feeling that it comes down to designing type systems against designing code systems. If what you're doing has a well-defined ontology, a proper static typing system will help.
I usually insert something about Java having a brain-dead type system in comments like this. The problem is that Java programmers who have not been exposed to more sophisticated static typing systems have no idea what I might be talking about: they get static vs. dynamic, but assume that all static systems work like Java (modulo inference).
My plea to anyone reading this who is used to Java, C#, and/or C++ is this: please look into ML, Haskell, or Ocaml. Ignore the functional stuff if you like. Ignore the inference stuff if you like. Look deeply into the flexibility of the type systems backing these languages. Don't let go until you experience the Aha!
I have a gut feeling that it comes down to designing type systems against designing code systems. If what you're doing has a well-defined ontology, a proper static typing system will help.
Bingo. A problem with a heavily explored solution space lends itself to static typing. Searching for a solution in code will feel awkward in that same type regime. The difference between those two sets of problems has generated a few decades of flames.
Bingo. A problem with a heavily explored solution space lends itself to static typing. Searching for a solution in code will feel awkward in that same type regime. The difference between those two sets of problems has generated a few decades of flames.
I did study a lot of languages, for living I write java. And no, I don't want to spend my time explaining my co-workers the intrinsic of enhanced type system. They still don't grasp the "super" in generics, and it's difficult to grasp that 2 sentence of the language denoting the same value doesn't always denote the same type (because the inference rules are based on the grammar, not on the value).
So no, I'll take those type systems for me, but not for everyone.
So no, I'll take those type systems for me, but not for everyone.
<< Home
