3 ms·

At first glance the 'almost any method can behave like an operator' stuff is really cool I dislike operators and all the unspoken, must-be-remembered complexit

At first glance the 'almost any method can behave like an operator' stuff is really cool I dislike operators and all the unspoken, must-be-remembered complexity they impose with regard to associativity and order. I actually think the S-expression syntax of Lisps is a lot better. A lot of these "weird" decisions were made in the interest of backward compatibility (in the ideological sense, not character-for-character) with Java. If Odersky hadn't supported these infix operators, which have a lot of weird-seeming rules about first characters and what it means when it ends with a ':', the language wouldn't be nearly as palatable. ETA: It really seems like the language designer merely looked at Java and tried to create an interoperable language that was as "un-java-like" as possible. I think Scala was designed to use the good parts of Java while throwing out the cruft. It's designed to be a "meeting point" between Java, Erlang, and Haskell. Clojure, I feel, has disowned its Java heritage more than Scala has.

pron 15y ago
It's designed to be a "meeting point" between Java, Erlang, and Haskell. Plus, a DSL building language. I actually think that the features Scala introduced to enable DSLs were the harbingers of the Scala insanity. Why did the designers of a high-performance statically-typed language think that it would be a good idea to support DSLs?
- michaelochurch 15y ago
  DSL support is tricky business. Consider Greenspun's Tenth Law. I think it's generally assumed in modern languages that it's better to allow this sort of thing than not do so and risk that people roll their own. On Greenspun: why are large Java programs hard to read? The language itself is simple. The problem is that most Java (or C++) programs devolve into shitty DSLs after about 2000 LoC.
- cageface 15y ago
  I agree with this 100%. Maybe it was an attempt to ride the DSL fad that Rails ushered in, but it really feels like Scala incurs a lot of extra complexity to support this feature. The Scala code I've written is pretty straightforward but I've made a point of resisting the temptation to build DSLs.
- nessus42 15y ago
  The biggest reason for supporting DSL's, as far as I understand it, is so that, as with Lisp, much of the functionality of the language can be moved out of the compiler and into libraries. This will make the language proper actually rather simple, though, of course, great complexity can come out of simple, orthogonal rules.

pron 15y ago

It's designed to be a "meeting point" between Java, Erlang, and Haskell. Plus, a DSL building language. I actually think that the features Scala introduced to enable DSLs were the harbingers of the Scala insanity. Why did the designers of a high-performance statically-typed language think that it would be a good idea to support DSLs?

michaelochurch 15y ago
DSL support is tricky business. Consider Greenspun's Tenth Law. I think it's generally assumed in modern languages that it's better to allow this sort of thing than not do so and risk that people roll their own. On Greenspun: why are large Java programs hard to read? The language itself is simple. The problem is that most Java (or C++) programs devolve into shitty DSLs after about 2000 LoC.
cageface 15y ago
I agree with this 100%. Maybe it was an attempt to ride the DSL fad that Rails ushered in, but it really feels like Scala incurs a lot of extra complexity to support this feature. The Scala code I've written is pretty straightforward but I've made a point of resisting the temptation to build DSLs.
nessus42 15y ago
The biggest reason for supporting DSL's, as far as I understand it, is so that, as with Lisp, much of the functionality of the language can be moved out of the compiler and into libraries. This will make the language proper actually rather simple, though, of course, great complexity can come out of simple, orthogonal rules.