Loren Segal: Too Lazy to "Type" (opens in new tab)

The point of the article is that virtually all real Ruby programs could be transformed, after the fact, into statically typed programs.

The significant point missed is that I can start typing the program without having figured out what the types will be. After the fact you can do the translation, but postponing having to work out not immediately relevant details is huge for developers.

The author makes an interesting point about how we can overuse dynamic programming when statically-typed programming can pretty much get us where we want to go. I've wondered why we haven't seen a big contender to Ruby/Python/PHP/Perl that has good type inferencing, but maybe that's what Mirah hopes to do? As much as I love Ruby's runtime code manipulation, I'm not really certain what the heck it's good for in the areas where it's largely used, and why it can't be replaced by code that's verifiable. If a language like ruby lost its type dynamism tomorrow and had it replaced with a type inferencer and all the programs that needed trivial type coercion just worked, what exactly wouldn't continue to work? What is it that's so huge that requires the dynamic aspect, especially in web design?

This is something that has bothered me about my Ruby usage. A lot of the time, I feel like I'm writing "dynamic" code that really just needs to be pre-processed.

  class Cool
    [:ice, :soda, :snow].each do |item|
      define_method item do
        #some code
      end
    end
  end

There isn't a real reason why that couldn't be pre-processed. I don't know a ton of Java, but the idea of compile-time code generation is appealing. Does anyone know more about this?

> Another fairly interesting paper titled "Evaluating the dynamic behaviour of Python applications", shows that programs in dynamic languages with these runtime modification behaviours often stop modifying their behaviour after a certain amount of "load time".

I find that deeply reassuring, since that's the core idea behind Magpie, the language I'm working on. It's a dynamic language with a static type-checker. The idea is that it runs dynamically at load time so you can imperatively and dynamically build your types and then after that, it statically checks the results, then invokes main() and (presumably) runs in a more or less static fashion after that.

If these dynamic languages are usually used in a mostly-static manner, just without the typing and some added load-time flexibility, doesn't that just mean they operate at a higher level of abstraction? Isn't that a good thing?

As a heavy user of statically typed languages who is learning JS and Scala currently, can anyone with more experience with dynamically typed languages confirm or deny the point of the article. Scala, with it's type inferencing seems like it might be a happy medium between. Thoughts anyone?

For what it's worth, the main points of the article are fairly similar to our reasoning behind the Gosu language's design: type inference helps alleviate a lot (not all, but a lot) of the pain of having to write type annotations in languages like Java, and the addition of the ability to do some kinds of metaprogramming at load time (but not at runtime) gives you a lot of the benefits of the sorts of metaprogramming you traditionally do in a dynamic language like Ruby (again, not all, but a lot of the typical use cases).

The problem with java isn't static typing, checked exceptions, XML configuration, type erasure, lack of lambdas, lack of closures, EJB 1.0, 2.0, 3.0, J2EE, JSP, servlets, servlet containers, etc. The problem is ALL of those problems combined. It tries to be everything to everyone, and turns out to be just a pain in the ass to everyone.

Every year they redo the entire infrastructure trying to do something that doesn't suck. I gave up in 2003 and never looked back. Every time I see the code for a java web project, or talk to java devs about the issues they face I want to throw up in my mouth a little. If the language is so great why is half the code written in XML, if I wanted to write code in XML, I'd use XSL.

I don't use ruby because dynamic coding / dynamic typing is a panacea, I use ruby because most of the infrastructure is designed to do something useful out of the box with no configuration. If I want it to do something more, I configure.

I'd use F#/ASP.NET MVC/nhaml in a heartbeat over ruby/RoR if all the gems and things that make life easy were readily available. I really don't think ruby is that great of a language, but the gems, rails, etc are awesome enough that I'll put up with the things I don't like.

I'd prefer that people in the java mindset who think I'm too lazy to type keep thinking that and keep their mindset away from any API/gem/module/library I use. Please for the love of god keep thinking the reason I don't use java is that I'm too lazy to type.

JSRs, JCPs, reference implementations, TCKs, JDKs, J2EE, J2SE, J2ME, etc, they are wonderful, I'm so jealous. Unfortunately, I'm just too lazy to type to experience all the wonderful benefits of such technology, so you'll have to keep all that wonderful technology all to yourselves and away from my crappy dynamically programmed, eval'd, dynamically typed, slow & bloated code.

I wonder what the performance benefit of adding optional type hints to ruby or python would be.

'Too lazy' makes it sound negative. The fact that we can mine types from production runs can mean less work for us and a more fluid design style.

For what it's worth, I think run-time data mining has the potential to transform the industry.