As usual, the world is not black and white. Sometimes it's just real handy to be able to talk to a typeless/schema-less resource without resorting to reflection, manual DOM parsing etc. I like what Anders Hejlsberg says about the matter; "static when you can, dynamic when you must".
/Casper On Apr 25, 10:09 am, Charles Oliver Nutter <[email protected]> wrote: > On Apr 24, 8:37 am, egervari <[email protected]> wrote: > > > Still, I think people like the fact that they can do duck typing and > > not have to get into hairy inheritance models that don't make sense. > > That stuff can and does get complicated, and the duck typing solution > > is actually pretty simple. Having said that, there are ways to get > > duck typing semantics in a static typing language like scala ;) > > Not efficiently. > > Scala supports something called "structural typing", which Scala users > will claim is "as good as duck typing". In a way it is; you can > specify statically that you want all objects passed to you support a > particular set of methods. That's almost duck typing, where you just > call the methods and damn the torpedos. But there's a catch... > > Scala's structural types can't be implemented with normal Java types, > and so Scala uses reflection to implement them. > > This is a common theme among statically-typed languages. They work > great as long as all types, method calls, parameters, variables, and > so on can be specified up-front for a compile phase to bind it all > together. But the real world isn't quite as perfect; you eventually > want to be able to reflectively load a class or call a method. If > you've ever done that, you're no longer obeying the rigor of your > statically-typed language of choice, and you've started to take > advantage of dynamic-language features (albeit in a very roundabout > way). At its simplest, dynamic typing could be thought of as always- > reflective programming. And of course most dynamic languages do a lot > more than that, like allowing you to add and remove methods to classes > at runtime, something that's literally impossible to do in a > statically typed language. > > And let's not pat ourselves on the back too much about how static our > languages are; I can defeat the static typechecking of any JVM > language by loading different versions of classes underneath you. If > you've ever gotten IncompatibleClassChangeError, you're seeing the > true nature of the JVM: it's dynamically binding almost all calls > anyway. You just don't see that fact as often as for a formally > "dynamic" language since static-typed languages wrap a nice warm > compiler blanket around you and say "everything will be all right". > > All these languages exist on a continuum; none are entirely static or > entirely dynamic. What varies is how much up-front specification you > have to put in your code in order to start the program running, and > what set of guarantees that specification affords your program at > runtime. Sometimes it's fine to specify everything to the letter, and > sometimes you'd like to just be able to call "foo" on some object > "bar" without knowing the exact type. These are different tools for > different problems; none of them are the one true tool, and none of > them are "you know what". > > - Charlie > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
