The Future Won’t Be Statically Typed

We’re having some “crystal ball discussions” sometimes at the office, trying to see what the future of Java, Ruby, computer languages, software and the world in general is going to be. The easy part is the world of course, with no fish in 40 years it’s easy to guess how all that is going to end up. For computing languages however, it’s a bit trickier.

I’m more and more convinced that statically typed languages will come to an end (just like the fish but quicker), replaced by duck typing based languages. There’s been many criticisms of duck typing but usually those voicing them don’t have an extensive experience of development using non statically typed languages or are Java fundamentalists. I haven’t heard anybody developing significantly in Ruby complaining about it not being statically typed. So I’ll spare you the whole argument about safety and compile-time checking because in the end it doesn’t really matter. You can theorize all you want but the pure fact is that static typing is a pain and pain slows us down and doesn’t help us doing things.

So very practically I can think of only one reason that could still make the duck typing alternative less appealing to some: the IDE. But IDEs will eventually catch up, using instrumented interpreters to detect types dynamically for example. There are solutions, even if they don’t cover all situations, 95% is good enough.

Say goodbye to your type definitions, generics and typed annotations (even annotations are statically typed for christ sake!) because I’m pretty sure you won’t see much of them 5 years from now.

Advertisements

11 comments so far

  1. Ricky Clarkson on

    I think we’re more likely to see Gilad Bracha’s optional types, or something similar.

    In other words, make a prototype, then start adding type annotations (either directly in the source, or somewhere else – it doesn’t have to make for verbose source code) that are checked by a tool, not necessarily the compiler.

    However, as far as I can see, Bracha neglects the possible benefits of typing at runtime, such as dynamic dispatch how CLOS does it. Maybe I need to read closer.

  2. Raphaël Valyi on

    Hi,

    Actually, the fish matters more than duck typing… No fish, no coders, no language, that’s pretty serious.
    Aside from that, I’m doing quite a lot of Ruby by now and have been a Java guy for a while. I think statically types are sometimes really missing in Ruby. Of course in general you protoype more easily and faster with duck typing. And most of the time it just doesn’t break (if you take care about some unite test though).

    But still, there are times where statical type is lacking (be it optionnal which would be great):
    * when you are coding dozens of thousands of lines within large teams (which is less common in Ruby though since you get 5 times more productive). Then you are going to forget some unit tests, you might get conflicting methods/ The two Rails 1.2 regressions I’m commenting here are just some of those typical cases that would never have occured with java and really suck to debug:
    http://rvalyi.blogspot.com/2007/02/rails-12-and-rb-gsl-ruby-math-lib-dont.html
    http://rvalyi.blogspot.com/2007/02/rails-12-plays-wrong-with-gettex.html

    * Also, static type is a design by contract and is auto-documented. Without it, you are relying on the developper willing or not to write great rdoc
    and specs. In companies where you are supposed to code mostly stupid/boring code some stupid decision maker wanted, everybody knows people don’t write great code doc. Or else it’s getting very unmaintainable entropic specs.

    * Finally, being also a C++ guy (but only in the 1% of case such an optimization is justified), I would say interpreters might always optimize better statically typed code, making them to run faster and use less memory. And there are times where this matters.

    Except those remarks, I think JRuby has got a bright future and java as a language might only be used in egde cases rather than systematically.

    Optionnal types would also just be great! Put a contract where your really need to (optimization, code clarity execution safety) and still let people code fast most of the time.

  3. mriou on

    Ricky, I’m not a strong believer of optional types. It’s certainly a good idea but people naturally embrace the path of least resistance. So if it’s optional, it’s not needed.

    Raphael, I partly agree with all your points. And partly disagree. Regressions and bugs exist in all languages, you can see some in Ruby that are caused by the absence of static typing but there are as many that haven’t been written because there is no static typing. It’s easy to ignore what you don’t see.

    As for auto-documented statically typed APIs… I’m not sure. Most Ruby APIs I’ve seen are much better designed and easier to understand that Java ones. Because of the tools available in Java people tend to write really crappy APIs, relying on these tools. And when you come down to it, I rather have an undocumented Ruby API because the code is just easier and quicker to read. Undocumented and badly designed Java APIs are for me the worst of all (save maybe undocumented and badly designed c++ APIs).

    On the performance side, I totally agree but then statically typed or not, you won’t rely on Ruby anyway. I think that whatever comes next, you will still have some C or C++ routines hanging around. And again Ruby makes it really dead simple to interface C or C++, especially compared to JNI. The future will certainly be much more multi-language and again, the one that will bind them all is very unlikely to be statically typed…

  4. Raphaël Valyi on

    “Because of the tools available in Java people tend to write really crappy APIs, relying on these tools”. I recognize most of Ruby API I’ve seen arround were nicely designed and well documented. May be that’s partly because Ruby is such a superior language than java.

    But I should say, the worst API I’ve ever seen in modern programming languages were written in javascript. For instance, I had to debug a Zimbra Ajax tree widget, I had to jump into literally thousands of mysterious code (those folks are crazy not to use prototype), always asking myself what really should be the type of some object at some point, never knowing what regression could generate my own code. I also had similar hard times with the MoinMoin wiki written in python, even if I think MoinMoin is still the best wiki engine. As far as I remember, I never had such hard times with any Java API. For instance, when I look at the Swing API, I find Swing a master piece of object oriented library and I really enjoyed discovering by myself all possible extension hooks with great facility thanks to easy code navigation and static types. At the same time, I never had the opportunity to hack a Ruby API of such complexity (Rails might be as complex, but I only used Rails the basic way).

    “I think that whatever comes next, you will still have some C or C++ routines hanging around. And again Ruby makes it really dead simple to interface C or C++, especially compared to JNI.”
    Agree 100%. That’s why I would be so much happy if JRuby were to mimic RubyInline transparently with JNI calls. Would that ever happen?

    “The future will certainly be much more multi-language and again, the one that will bind them all is very unlikely to be statically typed…”
    Agree 100%. IMHO, Java will only be used in edge cases (may be those were you would use C++ today, may be a little more widely) and powerfull languages like Ruby are going to be the universal glue code. Most of the time, a coder is supposed to fullfill a customer will to integrate existing API’s to do some custom requirement. That’s plain stupid to use java fo that, ruby is definitely a better glue code to achieve such integration in a snap, and change in a snap when the customer change his mind. And JRuby is possibly the best ruby interpreter to do that java integration.

    Regards.

  5. […] The Future Won’t Be Statically Typed « Skunk Works I’m more and more convinced that statically typed languages will come to an end, replaced by duck typing based languages (tags: programming languages java ruby duck_typing) […]

  6. phil swenson on

    I’m kind of torn on this issue…. I think I like the optional idea. I think the reason that java APIs suck has nothing to do with typing… it’s because of the Sun philosophy of being all things to all people. They make you do tons of setup for the simple case and treat the simple cases the same as the complex cases (witness the mail API).

    It’s worth noting that the next version of javascript (2?) supports optional typing, so I’m not so sure the trend is definitely away from static typing.

  7. mriou on

    Phil, my point wasn’t that Java APIs suck because static typing, it was that APIs written with duck typed weren’t necessarily cryptic. Like you I think that the quality of APIs have nothing to do with typing.

    As for the next version of Javascript (actually ECMAScript 4th revision, Javascript being the implementation, not the spec), it’s going to be interesting to see how it’s use. My take is that optional static typing will be only very rarely used. We’ll see if it proves me wrong…

  8. […] The Future Won?t Be Statically Typed Skunk Works – I’m more and more convinced that statically typed languages will come to an end, replaced by duck typing based languages […]

  9. […] Skunk Works has an article about how “The Future Won’t Be Statically Typed”. There’s been many criticisms of duck typing but usually those voicing them don’t have an extensive experience of development using non statically typed languages or are Java fundamentalists. […]

  10. anon on

    All those “Ruby-dynamic-everything idiots” piss me off. Try writing a game/compiler/browser/virtual machine/DBS in a dynamic language. You can’t, performance would be too awful. (Maintainance would be awful too, by the way.) “Dynamic language” = useful for scripting; worthless for serious/large systems. Dynamic typing will not win. Type inference a la Haskell will.

  11. Matthieu Riou on

    Have you tried? There are games written in Ruby and Javascript and they aren’t slow. There are compilers as well and they aren’t slow (actually performance of a compiler doesn’t matter that much, it’s the VM that does). Heck have you heard of GWT? It’s Java but gets compiled *to* Javascript and the result is pretty fast and makes pretty big applications.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: