4 ms·

The assembly optimizations come for free, in a sense, because what is really being optimized with the extra work is composability. Assembly time isn't all that

The assembly optimizations come for free, in a sense, because what is really being optimized with the extra work is composability. Assembly time isn't all that important, but composability is absolutely essential. Regarding things that aren't fully built, I really would need an example to be able to comment. I think the analogy has reached the limit of its usefulness :)

taeric 13y ago
I think my point is best summed up by saying that I can still run a project that has failing unit tests. To my knowledge, I can not run a program that fails type checking. The argument for this is typically "once it typechecks, it works." However, sometimes I can see enough from the output of a non-test passing piece of code to know whether the idea is even sound.
- nbouscal 13y ago
  I think the only reason you think not being able to run a program that doesn't type check is a problem is because you are used to a workflow in which running a program is how you test your ideas. The workflow used to explore ideas while programming in a strongly typed language is of course very different. Personally I think it's a lot better, but that's just opinion.
  - taeric 13y ago
    That is an amusing personal attack. :) I test my ideas by executing them, yes. Are you truly claiming that you have all of your ideas completely fleshed out before you test any of them? That sounds incredibly impressive, if so. Can it be done in some cases? Almost certainly. I question whether it can in all, though. Even most.
    - mightybyte 13y ago
      You don't have to have them completely fleshed out. But you do have to have them fleshed out to the type level. The Haskell compiler can be an invaluable aid in fleshing out the design of problems. Especially when they are complex difficult to wrap your head around.
    - nbouscal 13y ago
      Certainly wasn't intended to be a personal attack. I'm not claiming that I don't test my ideas, I'm claiming that I do so in a different way. Rather than testing ideas by running the program, I test my ideas by type checking it.
      - taeric 13y ago
        Most of my ideas I first test by a simple sketch of boxes up on a whiteboard. Going from there to some toy code to try out what I suspect are the tough parts of those boxes. I realize with liberal use of undefined, I can get something similar in Haskel. So, I am not trying to claim in precludes this behavior. Just claiming that it is a rather drastic change to the flow many people are used to. And really, I don't like claiming many people are used to this. As, I can really only speak for myself.
        nbouscal 13y ago
        I don't think they're quite as different as you think, but, it sounds like we agree. Two different ways of doing the same thing. To me, being different from what most people in software engineering are used to really doesn't sound so bad, judging from our industry's track record.
        taeric 13y ago
        Oh, I definitely agree with that. And don't get me wrong, I actually want to learn and use Haskel somewhere. I just get wary whenever I see the conversation leaning towards indications that it is a clear win. Seems like it is a qualified win. Too many of the stories read more like your typical "developer learns new way of thinking, becomes better for it." Which is ultimately what makes it so frustrating. When someone learns lisp and becomes a better programmer. There isn't much for them to say, other than "learning to think the lisp way has helped me be a better coder." There are those that get hung up on the metaprograming of lisp. Which is amazing. But, for the most part you can do that elsewhere now. The only thing left is it really is a frame of thinking. Contrast this with Haskel. Few stories focus on how it helped them see a more comprehensive view of types. Instead, the talk turns to how Haskel is a saving grace that the unwashed masses just isn't used to.
- eru 13y ago
  > To my knowledge, I can not run a program that fails type checking. GHC added support for that. (They jokingly called it Python-mode.) See https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime
  - taeric 13y ago
    Wow, missed this post. Will have to look into that. Very curious how that works. Thanks!

taeric 13y ago

I think my point is best summed up by saying that I can still run a project that has failing unit tests. To my knowledge, I can not run a program that fails type checking. The argument for this is typically "once it typechecks, it works." However, sometimes I can see enough from the output of a non-test passing piece of code to know whether the idea is even sound.

nbouscal 13y ago
I think the only reason you think not being able to run a program that doesn't type check is a problem is because you are used to a workflow in which running a program is how you test your ideas. The workflow used to explore ideas while programming in a strongly typed language is of course very different. Personally I think it's a lot better, but that's just opinion.
- taeric 13y ago
  That is an amusing personal attack. :) I test my ideas by executing them, yes. Are you truly claiming that you have all of your ideas completely fleshed out before you test any of them? That sounds incredibly impressive, if so. Can it be done in some cases? Almost certainly. I question whether it can in all, though. Even most.
  - mightybyte 13y ago
    You don't have to have them completely fleshed out. But you do have to have them fleshed out to the type level. The Haskell compiler can be an invaluable aid in fleshing out the design of problems. Especially when they are complex difficult to wrap your head around.
  - nbouscal 13y ago
    Certainly wasn't intended to be a personal attack. I'm not claiming that I don't test my ideas, I'm claiming that I do so in a different way. Rather than testing ideas by running the program, I test my ideas by type checking it.
    - taeric 13y ago
      Most of my ideas I first test by a simple sketch of boxes up on a whiteboard. Going from there to some toy code to try out what I suspect are the tough parts of those boxes. I realize with liberal use of undefined, I can get something similar in Haskel. So, I am not trying to claim in precludes this behavior. Just claiming that it is a rather drastic change to the flow many people are used to. And really, I don't like claiming many people are used to this. As, I can really only speak for myself.
      - nbouscal 13y ago
        I don't think they're quite as different as you think, but, it sounds like we agree. Two different ways of doing the same thing. To me, being different from what most people in software engineering are used to really doesn't sound so bad, judging from our industry's track record.
        taeric 13y ago
        Oh, I definitely agree with that. And don't get me wrong, I actually want to learn and use Haskel somewhere. I just get wary whenever I see the conversation leaning towards indications that it is a clear win. Seems like it is a qualified win. Too many of the stories read more like your typical "developer learns new way of thinking, becomes better for it." Which is ultimately what makes it so frustrating. When someone learns lisp and becomes a better programmer. There isn't much for them to say, other than "learning to think the lisp way has helped me be a better coder." There are those that get hung up on the metaprograming of lisp. Which is amazing. But, for the most part you can do that elsewhere now. The only thing left is it really is a frame of thinking. Contrast this with Haskel. Few stories focus on how it helped them see a more comprehensive view of types. Instead, the talk turns to how Haskel is a saving grace that the unwashed masses just isn't used to.
eru 13y ago
> To my knowledge, I can not run a program that fails type checking. GHC added support for that. (They jokingly called it Python-mode.) See https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime https://ghc.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime
- taeric 13y ago
  Wow, missed this post. Will have to look into that. Very curious how that works. Thanks!