7 ms·

I like this "problem" because it encourages small programs. Also, Scala's type system is just very complex. If you have a 2000-file program with cyclical depen

I like this "problem" because it encourages small programs. Also, Scala's type system is just very complex. If you have a 2000-file program with cyclical dependencies you are screwed. If you use Scala-IDE (which has an embedded sbt doing incremental compiles, which become non-incremental if your dependency structure is fail and you have a huge SCC) on such a project you are doubly screwed. That's not a problem with Scala. Bigass programs aren't a good idea in any language. The programmer-to-program relationship should be one-to-many (for engagement, productivity, modularity, code quality) and not the "enterprise" reverse.

untog 14y ago
Using slow compilation speed to encourage small programs is a terrible "solution".
- michaelochurch 14y ago
  It's slow because it's doing a lot. If you don't want a cutting-edge, powerful static type system there's an awesome JVM Lisp (Clojure) that I recommend highly.
  - mietek 14y ago
    On the other hand, if you do want a cutting-edge language with a powerful static type system, and a compiler an order of magnitude faster than Scala's, you could try Haskell.
  - calpaterson 14y ago
    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.
ryanpers 14y ago
I'm sorry but this is possibly one of the worst comments I've seen... There is a conservation of complexity that you just can't get rid of in an application. To suggest that Scala encourages small programs, you are also suggesting that Scala is only appropriate for small problems, and thus it isn't a scalable language. See: http://c2.com/cgi/wiki?ConservationOfComplexity http://c2.com/cgi/wiki?ConservationOfComplexity Ultimately, the baseline requirements drive the minimal complexity of code. Sure a poor programmer can drive up the complexity with unnecessary constructs, but the converse is not true: a great programmer can drive to simplicity. For example, a flight control system for a 777 can never be reduced to a single file of 700 lines of code. It will likely always be 2000+ files, and have lots of inter-dependencies. So I guess (run time safety issues of Scala aside) Scala is not an appropriate language for complex problems by your own words?
- michaelochurch 14y ago
  Scala's compile speed (with incremental compiles) is generally acceptable if you have reasonable dependency patterns. If you have cyclic dependencies, it's a problem. However, cyclic dependencies are signs of things that are wrong in development practices that can't be blamed on the language. You mentioned flight control systems: those are unlikely to be written in Scala, being real-time systems, but if one were, it would not need to be compiled and recompiled on the fly. Scala's a great language but it's not the right language for every problem. No language is.
  - ryanpers 14y ago
    Good non-answer. For many large, non-trivial systems have several requirements: - tends to have complex dependencies - needs fast builds This was a classic: http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620 http://www.amazon.com/Large-Scale-Software-Design-John-Lakos... Essentially how to design C++ systems so that incremental compiles don't sink you. Developer productivity is important. Scala is badly failing on this front IMO, it reminds me of the old bad days of C++ in a major way.

untog 14y ago

Using slow compilation speed to encourage small programs is a terrible "solution".

michaelochurch 14y ago
It's slow because it's doing a lot. If you don't want a cutting-edge, powerful static type system there's an awesome JVM Lisp (Clojure) that I recommend highly.
- mietek 14y ago
  On the other hand, if you do want a cutting-edge language with a powerful static type system, and a compiler an order of magnitude faster than Scala's, you could try Haskell.
- calpaterson 14y ago
  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.

ryanpers 14y ago

I'm sorry but this is possibly one of the worst comments I've seen... There is a conservation of complexity that you just can't get rid of in an application. To suggest that Scala encourages small programs, you are also suggesting that Scala is only appropriate for small problems, and thus it isn't a scalable language. See: http://c2.com/cgi/wiki?ConservationOfComplexity http://c2.com/cgi/wiki?ConservationOfComplexity Ultimately, the baseline requirements drive the minimal complexity of code. Sure a poor programmer can drive up the complexity with unnecessary constructs, but the converse is not true: a great programmer can drive to simplicity. For example, a flight control system for a 777 can never be reduced to a single file of 700 lines of code. It will likely always be 2000+ files, and have lots of inter-dependencies. So I guess (run time safety issues of Scala aside) Scala is not an appropriate language for complex problems by your own words?

michaelochurch 14y ago
Scala's compile speed (with incremental compiles) is generally acceptable if you have reasonable dependency patterns. If you have cyclic dependencies, it's a problem. However, cyclic dependencies are signs of things that are wrong in development practices that can't be blamed on the language. You mentioned flight control systems: those are unlikely to be written in Scala, being real-time systems, but if one were, it would not need to be compiled and recompiled on the fly. Scala's a great language but it's not the right language for every problem. No language is.
- ryanpers 14y ago
  Good non-answer. For many large, non-trivial systems have several requirements: - tends to have complex dependencies - needs fast builds This was a classic: http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620 http://www.amazon.com/Large-Scale-Software-Design-John-Lakos... Essentially how to design C++ systems so that incremental compiles don't sink you. Developer productivity is important. Scala is badly failing on this front IMO, it reminds me of the old bad days of C++ in a major way.