5 ms·

GHC does a lot of the same things (arguably more stuff) and it's extremely fast, especially if you don't use -O*. Anyway, type-checking is probably the fastest

GHC does a lot of the same things (arguably more stuff) and it's extremely fast, especially if you don't use -O*. Anyway, type-checking is probably the fastest part of compilation so there's no reason to give up Hindley-Milner for speed reasons. (One of the best features of GHC is that you can use GHCi to typecheck)

Flow 14y ago
I wonder if those implicits in Scala makes the compilation non-linear in time.
yummyfajitas 14y ago
GHC doesn't do subtyping. I suspect that is the main reason why Scala is slow - it's certainly the reason why the code is more complex.
- mietek 14y ago
  OCaml does objects and subtyping, while still managing to remain quite fast. http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-objects.html http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-objects.html
  - bad_user 14y ago
    OCaml doesn't have Haskell's type-classes or Scala's implicits. Scala's subtyping is also nominative (versus structural) and it's basically impossible to do type-inference for nominative subtyping. Whether this is good or bad, the fact remains that Scala runs on top of the JVM while Ocaml doesn't. If you ever work with Ocaml you'll notice that the type-inference system breaks down when you're working with OOP and in Ocaml you're really dealing with 2 type-systems shoved in the same language. What Ocaml does really well, compared to both Haskell and Scala is type-inference, but it's kind of a weak language IMHO as far as functional programming is concerned. I also don't get all this complaining, because in practice Scala compilation speed is not a problem. After working with Scala in production for a couple of months now, I'm beginning to suspect that all this is just hyperbole perpetuated by people that never worked with Scala a single day in their lives.
    - yummyfajitas 14y ago
      In practice (I write Scala every day) compilation speed is a problem. I just recompiled a work projec, just under 28kloc. 124 seconds is a problem. Admittedly, we do make heavy use of the type system.
      - eeperson 14y ago
        Out of curiosity, how much of a problem is it? Is incremental compilation noticeably slow or is it just the full compile?
        yummyfajitas 14y ago
        It's friction in the development process. Incremental compilation suffers from the fragile base class problem. In a well structured app with proper encapsulation and rigid (and type annotated) interfaces, it helps a lot.
      - bad_user 14y ago
        The reason for why it hasn't been a problem for us is because we've been making heavy usage of SBT's support for sub-projects. Scala makes it easier than other languages to decouple components, so after a while you begin to spot possible sub-projects all over the place. The project I'm working on right now is about 15kloc, but it's split in 3 sub-projects. Coupled with incremental (and continuous) compilation, this compilation speed issue hasn't been a problem for me. Also, if you look around, many open-source projects built with Scala follow the same technique. It's quite sane too.
      - felipehummel 14y ago
        How many times you do full recompile during a day? I'm curious because in my workflow I rarely do full recompile.
        yummyfajitas 14y ago
        If your project isn't properly encapsulated, incremental recompilation will often come close to a full recompile, or at least recompilation of a big chunk of code. For example, if you delete AbstractFooBase.unusedMethod, sbt will recompile every file everywhere that references a concrete Foo instance. (In principle it should only need to recompile files which reference unusedMethod, but it's not that smart yet.)
michaelochurch 14y ago
Haskell didn't build on top of a decade-old enterprise language. Both Haskell and Scala have some excellent work behind them, but they were built under different constraints.

Flow 14y ago

I wonder if those implicits in Scala makes the compilation non-linear in time.

yummyfajitas 14y ago

GHC doesn't do subtyping. I suspect that is the main reason why Scala is slow - it's certainly the reason why the code is more complex.

mietek 14y ago
OCaml does objects and subtyping, while still managing to remain quite fast. http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-objects.html http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-objects.html
- bad_user 14y ago
  OCaml doesn't have Haskell's type-classes or Scala's implicits. Scala's subtyping is also nominative (versus structural) and it's basically impossible to do type-inference for nominative subtyping. Whether this is good or bad, the fact remains that Scala runs on top of the JVM while Ocaml doesn't. If you ever work with Ocaml you'll notice that the type-inference system breaks down when you're working with OOP and in Ocaml you're really dealing with 2 type-systems shoved in the same language. What Ocaml does really well, compared to both Haskell and Scala is type-inference, but it's kind of a weak language IMHO as far as functional programming is concerned. I also don't get all this complaining, because in practice Scala compilation speed is not a problem. After working with Scala in production for a couple of months now, I'm beginning to suspect that all this is just hyperbole perpetuated by people that never worked with Scala a single day in their lives.
  - yummyfajitas 14y ago
    In practice (I write Scala every day) compilation speed is a problem. I just recompiled a work projec, just under 28kloc. 124 seconds is a problem. Admittedly, we do make heavy use of the type system.
    - eeperson 14y ago
      Out of curiosity, how much of a problem is it? Is incremental compilation noticeably slow or is it just the full compile?
      - yummyfajitas 14y ago
        It's friction in the development process. Incremental compilation suffers from the fragile base class problem. In a well structured app with proper encapsulation and rigid (and type annotated) interfaces, it helps a lot.
    - bad_user 14y ago
      The reason for why it hasn't been a problem for us is because we've been making heavy usage of SBT's support for sub-projects. Scala makes it easier than other languages to decouple components, so after a while you begin to spot possible sub-projects all over the place. The project I'm working on right now is about 15kloc, but it's split in 3 sub-projects. Coupled with incremental (and continuous) compilation, this compilation speed issue hasn't been a problem for me. Also, if you look around, many open-source projects built with Scala follow the same technique. It's quite sane too.
    - felipehummel 14y ago
      How many times you do full recompile during a day? I'm curious because in my workflow I rarely do full recompile.
      - yummyfajitas 14y ago
        If your project isn't properly encapsulated, incremental recompilation will often come close to a full recompile, or at least recompilation of a big chunk of code. For example, if you delete AbstractFooBase.unusedMethod, sbt will recompile every file everywhere that references a concrete Foo instance. (In principle it should only need to recompile files which reference unusedMethod, but it's not that smart yet.)

michaelochurch 14y ago

Haskell didn't build on top of a decade-old enterprise language. Both Haskell and Scala have some excellent work behind them, but they were built under different constraints.