Live data from Hacker News

Loren Segal: Too Lazy to "Type"

gnuu.org

11–20 of 36 posts

Re: Loren Segal: Too Lazy to "Type"

#11
post #8

Earlier quoted context omitted.

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.

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.

[deleted]

Re: Loren Segal: Too Lazy to "Type"

#12
post #8

Earlier quoted context omitted.

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.

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

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.

Re: Loren Segal: Too Lazy to "Type"

#13
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?

Re: Loren Segal: Too Lazy to "Type"

#14
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?

Re: Loren Segal: Too Lazy to "Type"

#15
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?

Re: Loren Segal: Too Lazy to "Type"

#16
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).

Re: Loren Segal: Too Lazy to "Type"

#17
post #2

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.

Type inference (Haskell, C#) can be handy. Optional typing (many Schemes/Lisps, e.g. Gambit-C, SBCL or Clojure) is also an option.

I see your point, but dynamic typing is not the only way to get (most of) these benefits, and both of the above show significant performance boosts.

Re: Loren Segal: Too Lazy to "Type"

#18

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…

[deleted]

Re: Loren Segal: Too Lazy to "Type"

#19
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.

Re: Loren Segal: Too Lazy to "Type"

#20
post #13

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?

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