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.
I wouldn't say that. I think the main difference is that Scala spent its language design budget on more useful things compared to Java. Have a look at C# if you want to see a language with tons of features.
> 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?
From experience, that amount of code is considerably smaller than Java because I can be pretty sure that some piece of Scala code usually won't mutate stuff all over the place.
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.
Another way to say this is that Java is a lower-level language than many newer languages, consequently it's much more wordy. And it is certainly wordy, to the degree that it's difficult to follow one's own code. And I see you make a similar point.
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++.
BigInteger four = new BigInteger("4"); BigInteger sum = four.add(new BigInteger("2")); // assuming you won't need 2 again so why store a in var
I never wished for the ability to do operator overloading anymore than I do when I have to use BigInteger in java. It just makes math look so unnatural and hard to read. You end up with variables all over the place to do Math on numbers or have to create a bunch of them in the method arguments. Just an utter mess when compared to the similar class in C# that does it with operator overloading.
What Scala has done however is to pick particularly powerful features that are allowed to intersect as much as possible giving a lot of flexibility. At the same time it has introduced and encouraged functional programming concepts which are new to many OO programmers with Java backgrounds. This can make it seem a little daunting but I found it no more difficult to learn than any other language and easier than some.
The compile times are simply because the compiler is doing a lot more. It's always going to be slower than the Java compiler, though there are still optimisations that can happen. That's a trade off, the additional expressivity and safety of the type system is either worth it to you or not. In the case of Play, you're getting compile time checked routes and templates for example.
In terms of reasoning, it is much easier to reason about idiomatic Scala code in isolation than it is Java. This is because you have much richer type information and can apply the substitution model without being worried about mutation and side affects. It is true however that the flexibility you are given can be misused and you aren't forced to stick to a functional style, so when someone goes off the reservation that can result in hard to comprehend code. Most of the FOSS projects I've seen in Scala avoid this but YMMV.
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.The fact that operators are methods and can be overridden simplifies things - you no longer need to know and remember operators. They are always methods on the type you are looking at. This is what I mean by more regular and fewer surprises, the footprint is smaller.
So you can use this simpler, more powerful feature to create DSLs. They are compile checked and are "real Scala". The tools autoamtically help you. Of course, DSLs exist in Java but they often involve tools like JTB and JavaCC, extra compilation steps, no compiler assistance for users - I could go on. Which is more complex?
Anyway, I agree you could abuse the more powerful language features to write hard to comprehend code. However if you take a look at Scala code in the wild, you will see that these concerns so far have been largely theoretical and of course you can also write incomprehensible junk in Java or any other language should you wish.
I'd encourage people to try the Coursera Scala course which is running again soon, and see for yourself.
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.
scala> def ==(a: Any) = false
<console>:7: error: overriding method == in class Any of type (x$1: Any)Boolean;
method == cannot override final member
def ==(a: Any) = false
^
Maybe you should actually use the language for a few minutes before commenting? :-)I hope you do realise that my point isn't even specifically about Scala, but about syntactical abstraction in general.
Yes, that's what all the Typesafe employees repeat ad nauseam at conferences and on mailing-lists. Anyone who has spent more than a year coding in that language knows how ridiculous that claim is.
I'll just pick one example: _ has six different meanings depending on where you use it.
It's fine to like a language (I love quite a few myself) but don't drink the kool aid and try to remain objective about the strengths and weaknesses of your tools.
FYI: I don't work at Typesafe, and I share his experience.
One great thing about Scala is that one can immediately tell whether someone has actually used it by looking at the complaints.
Things like "OMG _!!!", "Null, Nothing, None ... sooooo confusing", "Perl", "C++" give it away immediately. I wonder why people are not more upfront and honest about not having spent more than 5 minutes with Scala. It's totally OK, no one can learn everything.
Having used Scala for several years now the claim is a long way from ridiculous.
I find the idea that an opinion contrary to yours means someone is drinking kool aid and failing at objectivity a little ironic.