Hacker News Reader

Comment by Nitramp | Hacker News Reader

This is what the Java designers always talk about: languages have a "complexity budget".

You can choose to spend your complexity budget on different features (static typing, generics, closures, manual memory management, auto casts, overloaded operators, ...). Some features can take away complexity (GC). But once you've overdrawn your budget, the language gets creaky to use and everybody starts talking about "subsetting" the language. C.f. C++ - all those features do serve a purpose, and looking at the feature alone, it might be reasonable.

I think Scala has way blown its complexity budget. They've innovated on too many different fronts. I'd been happy to have Java with closures, first class functions, and maybe better generics.

There was a lot of buzz around DSLs at some point of time, and they decided to go all in with implicits, which I think was a bad idea. I guess they were trying to market the language...

View on HN

I've been digging into scala recently, and although i'd have to agree, I couldn't say necessarily where this budget was blown. I love that the generics are improved over java (I usually don't need the IDE to check complex generics for me in scala as I do in java), but the overall type system can be daunting. First class function and closures are a easy win for me as well. I also love some of the more "advanced" functional constructs, and lazy evaluation (Stream! I love Stream!).

What gets me is the flexibility of the language. I don't want multiple ways to declare and/or bind the same function, and I don't want multiple ways to declare a lambda (why do I need a language shortcut, and then a shorter shortcut to choose from?). I guess where I'm going with this, is that I think the "complexity budget" would have been manageable, still with most of this feature set, if the language wasn't a DSL factory, and there was a single obvious way to write your program (obvious python bias on my part here).

Oh, and while I'm ranting; XML Literals? ಠ_ಠ

I think basically everyone agrees that XML literals are a bad idea. There is a little more background described here: http://www.quora.com/Will-Scala-ever-remove-XML-literals

"I'd been happy to have Java with closures, first class functions, and maybe better generics."

But that would have made Scala just about equivalent to modern C#. That is, a language balanced for the current masses but still with some modern features. This is not Scala.

Scala is amongst those languages that are blazing the paths for the future masses. There is a friendly subset but it is meant for those that are not afraid to play with the experimental at the expense of the farmiliar. Basically Language hobbyist and startups with no legacy code base. It is not hard, I know this because I taught someone with no experience whatsoever in programming and they found it easier than Java. Someday it will be considered clunky and mundane but that day is not today.

But my complaints on Scala could not have been put better than ominus_prime, too many way to do simple things. Another complaint is how well it interacts with the Java ecosystem - Ive noticed C#/F# is a loot smoother than Java/Scala. Simple Enums in Scala are also something that is too hard (for say if you need to interact with java or just dont need full blown algebraic types). Things are a lot better in this regard since 2.8 but still not there IMO.

Enums are awful in Scala. I usually just use this pattern:

    abstract case class MyEnum(id: Int)
    object MyEnum {
      object Foo extends MyEnum(0)
      object Bar extends MyEnum(1)
      object Baz extends MyEnum(2)
    }

I don't understand what you mean when you say they went all-in on DSLs with implicits. I far more often use implicits for integrating Java libraries or papering over clunky apis than for putting together DSLs.

Just take a look at how specs [1] works:

  "Some element" should {
      "behave in some way" in {
          // ...
      }
  }

According to this, the String type has a "should" method and an "in" method, but it really doesn't. Instead, there is an implicit conversion from a string to another type that actually has those methods. They idea here is to make the DSLs more fluent by removing the need to worry about complex type interactions while designing the interface. It lets the users use the pre-existing types they're already familiar with.

[1] http://code.google.com/p/specs/

These DSLs in Scala can be awful. I mean:

    val ivySvn = "ivysvn" % "ivysvn" % "2.1.0" from "http://maven.twttr.com/ivysvn/ivysvn/2.1.0/ivysvn-2.1.0.jar"

Oh, but if you use a different maven convention, just double up the first percent sign:

    val ivySvn = "ivysvn" %% "ivysvn" % "2.1.0" from "http://maven.twttr.com/ivysvn/ivysvn/2.1.0/ivysvn-2.1.0.jar"

Readable, yes; intuitive, no.

Implicits are obviously useful for DSLs, I'm not disputing that. My point is that they're obviously useful for other things as well, and so it doesn't make sense to say their inclusion in the language is a sign that the designers are going "all in" for DSLs - that designation would seem to be reserved for features like macros or parser combinators.

> I'd been happy to have Java with closures, first class functions, and maybe better generics.

What you want is Fantom. It's an incremental improvement over Java with lots of features that doesn't blow the complexity budget IMHO.

http://fantom.org/doc/docIntro/Tour.html

I'm pretty far removed from the Java ecosystem, but that's more or less what Groovy shoots for too, right? Or is Groovy more complex?

Reply on news.ycombinator.com