

Loren Segal: Too Lazy to "Type" - akahn
http://gnuu.org/2010/12/13/too-lazy-to-type/

======
btilly
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.

~~~
jamii
Except for short scripts I generally start programming by figuring out what
the data will look like. In a strongly typed language I have a built in
language for describing my data. Of course the data structures change as the
program evolves but I find it massively helpful to have that description up
front.

What's that quote? Something like:

"Show me your algorithm and I will remain puzzled, but show me your data
structure and I will be enlightened."

~~~
jeff95350
Exactly.

To often, I think we're focused on the _writing_ of code rather than the
_reading_ of code. Annotations sometimes seem repetitive, but repetitive can
aid the readability.

Type inference might be a very nice compromise. Haskell allows you to annotate
with type information, and that may provide more helpful errors, but usually
it's optional. But people do it anyway, because type information tells a
reader so much about the program.

If we just focus on _writing_ , then clearly the programming language is meant
only for unidirectional communication from a human to a computer. But if we
focus on reading as well, then it becomes about humans communicating with
other humans.

------
grav1tas
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?

------
johnnygood
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?

~~~
ambition
Solving this problem in general is a major area of research. Look up "Partial
Evaluation."

~~~
grav1tas
Yes! I second this. Partial evaluation is especially compelling stuff for
improving efficiency. I'm glad other people on HN are into it.

------
munificent
> 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.

------
Xuzz
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?

~~~
chromatic
Your definition of good may or may not include "do these higher level
abstractions preclude, in theory and practice, well-known and cheap
optimizations?"

~~~
Xuzz
Depends if you care about "code fast" or "develop fast".

~~~
kristianp
It would be cool if a language could be both, by using this research to create
a language that recognises the difference between load time and run time. The
dynamic parts would be used to load the program, after which dynamic changes
would be turned off, allowing function dispatch or whatever it is that is slow
in a dynamic language to be sped up.

~~~
Xuzz
Basically, a (very!) enhanced preprocessor? That would definitely be useful.

------
calebmpeterson
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?

~~~
munificent
Type inference is nice and goes a long way, but it's still fundamentally
different from being able to modify types imperatively at load time. For
example, in Ruby, it's trivial to swap out a method with a version that does
some logging, but only on Tuesdays. Scala can't really do that because it
presumes all types are locked down before any code (such as code to tell if
today is Tuesday) has executed.

~~~
sha90
One of the points in the article is that this kind of behaviour modification
is not done _that_ often. Yea, it happens... but not as much as you'd think.

~~~
munificent
I don't think you have that right. I read it as that kind of behavior
modification isn't done that often _after load time_. During load time, all
sorts of shenanigans are going on (monkey patching, etc.)

~~~
sha90
Well, you're right about that distinction-- but from your comment "only on
Tuesdays" I understood you were talking about behaviour modification some time
after "load time". Also keep in mind the first paper cited in the article
(profile-guided inference) actually points out that in most cases, "load time"
can be inferred nearly statically-- as in, you would not need to run a test
suite, you would only need to "load" the base code. This is a feasible task,
in most cases.

------
akeefer
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).

------
fleitz
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.

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

~~~
sha90
Read the Starkiller dissertaion (for Python):
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.268&rep=rep1&type=pdf)

The compiler gives enormous optimizations for certain (admittedly extremely
specialized) numerically intensive programs / calculations. Of course, if the
compiler was developed further (it might be, actually), you'd probably see
optimizations for larger sets of programs.

------
michaelfeathers
'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.

