xjru

Maybe you shouldn't try so hard to deliberately misunderstand what I'm saying. Your nitpicking doesn't change the fact that you can redefine what == does in your own classes.

I hope you do realise that my point isn't even specifically about Scala, but about syntactical abstraction in general.

It doesn't matter which operator you choose as an example. It's the same with a == b.

And I don't agree that it's a theoretical problem that only arises with bad code. It's simply a downside that we have to be aware of when we use DSLs, even well designed ones. For some purposes bland code is just better than smart code.

But I do agree that a Scala based DSL is hugely superior compared to any byte code manipulation based Java framework that obscures lanaguage semantics beyond recognition. It's also way easier to reason about Scala code than about Python/Ruby style meta programming.

I don't doubt that Scala does the things that both languages do in a cleaner, more regular way. But the kind of syntactical abstraction that Scala supports lets you replace semantics that you can't replace in Java, which creates uncertainty. Consider this:

  a = b

In Java or C this can only mean one thing. The value of variable b is assigned to variable a. In Scala it could mean the same thing, or the = operator could be overloaded and b could be a method call. If you need to know which one it is, for instance because you're trying to understand someone elses code, then you have more work to do than in Java.

I don't deny that. What adds to complexity more than verbosity, though, is that Java's lack of abstraction facilities leads to the overuse of frameworks, including byte code manipulation and excessive reflection. At that point it can get really obscure.

But you can write straighforward Java, and on average reading someone elses Java code is easier than reading typical C++ code for instance. I don't have experience with reading other people's Scala code but it seems similar to C++.

Immutability is not a language feature in Scala as it's not enforced like it is in Haskell, so you don't have any guarantees about what a piece of code doesn't do. Granted, you can make a better guess than in Java where mutability is concerned.

Scala's syntax is flexible enough to let you build DSLs. It makes use of operator overloading, optional braces after method calls, infix methods, etc. All features that Java doesn't have.

Being able to build DSLs is a good thing, but the whole point of DSLs is to hide some of the semantics of the underlying language and let you think in terms of the domain the DSL was built for. So there is clearly a power/complexity/understandability trade-off.

Scala has way more language features than Java, that's for sure. It does have powerful abstractions and it makes a lot of things more elegant. You could say the same about C++ compared to C.

But in both cases, sensible people can disagree on whether or not the additional power justifies the additional complexity and those insane compile times.

And just to be a little more specific in what I mean by complexity: What I mean is, how much do you know about what a particular piece of code does when looking at it in isolation? How much additional context do you need to figure out what it does? How many possibilities are there?

Powerful syntactical abstractions are a double edged sword.