Isn't this a bit of an unfair comparison?
Java the language is at least 8 years older than Scala the language. Scala had the benefit of learning from previous language's mistakes.
Java the language is at least 8 years older than Scala the language. Scala had the benefit of learning from previous language's mistakes.
No, because it's not like Java was the first language to ponder about these, and it did not learn from previous languages (mistakes or successes). Pretty much all of Scala's improvements over Java predate Java itself by decades.
Java simply refused to learn from previous language's mistakes.
To some extent, C# did as well by starting out as a slightly improved Java instead of an actually good language, which means even with all the improvement they're doing since they're not deprecating and removing old crud the language is now chock-full of crap and far more complex than it could (and used to) be.
Since C# 1.1 they've only added features that are mostly orthogonal to the existing ones. Secondly, the features they've added aren't half-baked. Sure there's room for improvement, but they behave as you expect them to, and the designers specifically leave room for improvement all the time.
Sure, I hate that everything I want to do still has to be specified within a class / static method; that's Java-related legacy done probably because of marketing reasons, but C# has 2 things I wish for whenever I'm working with Scala ...
- the ability to get the expression tree of a closure. There was a plugin for Scala at some point, but it's dead.
- dynamic typing, which structural typing cannot really replace.
You say chock-full of crap, but IMHO language designers should learn from its evolution, because it was a good one.
Yes. Like delegates (1.0), anonymous delegates (2.0) and lambdas (3.0). Or `for`, `foreach` and List.ForEach. Orthogonalith, schmortogonality.
> Secondly, the features they've added aren't half-baked.
Though I disagree with your statement (C#'s properties are crummy, its Nullables are half-assed if even that, the collections are a mess, the enumeration suck goats, arrays are covariant, implicit conversions are terrible ideas, extension methods are a half-assing of open classes, tuples are painfully awful, out parameters everywhere is a gigantic joke, and I'm not even actually looking for these things), I didn't state they were half-baked. Me thinks the lady protests too much.
> Sure there's room for improvement, but they behave as you expect them to
Which is irrelevant to the point and completely uninteresting.
> IMHO language designers should learn from its evolution, because it was a good one.
There was nothing good about it. Trying to make a small but crappy language into a good language by accretion is not "good evolution".
edit: let's make this clear: I understand the constraints of the C# team (at least some of them) and I understand they weren't (and aren't) out to create a good language, let alone a revolutionary one. Doesn't mean I have to agree with that.
"for" is different than "foreach", and "for" is there because the language being named "C#" it had to have some heritage from C. Also all ForEach methods are built on top of IEnumerable.
I.e. features are built on top of each other.
For the record I think implicit conversions are a great idea, that properties are OK, and extension methods are cleaner than open classes.
Not to mention, there's stuff you can do with extension methods / implicit conversions that you cannot do with open classes (and viceversa).
Delegates are references to code blocks, anonymous delegates are references to code blocks, lambdas are references to code blocks. They're three features which do the same thing, meaning they are not orthogonal (and they could have been build from lambdas up and I'd have said the same thing).
> "for" is different than "foreach"
Yes, one has 3 more letter than the other one. Any usage pattern of `for` can be replicated by `foreach` and the right enumerables, and vice versa. Not only are they not orthogonal, they're fully redundant.
> and "for" is there because the language being named "C#" it had to have some heritage from C. Also all ForEach methods are built on top of IEnumerable.
This is completely irrelevant to my point and absolutely uninteresting.
> I.e. features are built on top of each other.
These features also fundamentally do the same thing i.e. they're not orthogonal. Your original claim was the following:
> Since C# 1.1 they've only added features that are mostly orthogonal to the existing ones
I gave you 4 features which are anything but orthogonal to preexisting features.
> that properties are OK
Goodness gracious, stockholm syndrome much?
http://news.ycombinator.com/item?id=1942859
http://www.reddit.com/r/programming/comments/ec95s/jon_skeet...
Compare Java to C++, for example -- the top 5 things that annoy me about C++ are mostly fixed in Java (#ifdef, STL inconsistency, .h and .cpp files for one class, destructors, bounds checking..)
No. It only "learned" from C++'s mistakes, if even that, and threw out the baby with the bathwater (threw out templates but tamer generics as well, threw out non-nullable references, threw out context management — RAII or other)
> The fact that it's ubiquitous, not perfect, has traditionally been slow/judicious to adopt new features (good), and hasn't had a release in the better part of a decade (bad) , amplify the perception of it's flaws.
No, the fact that it's full of flaws that have been criticized from the start does that.
> bounds checking..
Java didn't fix bounds checking, they only fixed the memory unsafety of it, because Java is a GC'd language and therefore memory safe by default.
Personally, I think throwing out templates is exactly what should have been done. And Java has generics.
What other lessons were they supposed to learn according to you, exactly?
Sure, if his goal was to create a super popular enterprisey language, to create the son of Cobol and to bring mainstream language improvements to a shrieking halt for a decade, he succeeded admirably on all counts.
> Personally, I think throwing out templates is exactly what should have been done. And Java has generics.
If you can't even be arsed to read what you reply to, I don't think there's any point in me continuing.
I addressed templates, which to the extent I've seen them, are a confusing nightmare. You can say that's because I'm not smart enough, but I'd retort that I don't want to debug something that smart.
Non-nullable references you can make a case for, but but it's minor and you can also say 2 types of references complicates things much more than one type of reference. Java dodges all kinds of confusion by only having one kind. And context management, which is such a relic that I had to google it, seems to be a hack to make memory management easier to deal with. Again, clever, but I'm not sure I want to debug it. How about avoiding static state and dodging the whole problem.
Java has 50 keywords total, including "void" and all primitive types, and it can do almost all of what C++ can. Yes, the OO model is a product of 1995. See smalltalk. EJB is "enterprisey", Java is not. And all organizations, regardless of hipness, need maintainable code.
Anyways, certainly nothing is perfect, so I'd love to hear more thought-out reasons why Java sucks.
You probably never programmed in C++ before. Trust me on that, Java was a breath of fresh air and it was obvious to everyone that it learned a lot from past languages.
> No, because it's not like Java was the first language to ponder about these, and it did not learn from previous languages (mistakes or successes). Pretty much all of Scala's improvements over Java predate Java itself by decades.
Maybe, but if these features had been put in Java in 1995, it's very unlikely it would have met the success it knows today.
Sometimes, the hard part in language design is knowing what feature not to add. Java did great in that respect.
Scala... not so much, if the language complexity is any indication.
Very small parts, and very badly implemented. Apart from C++ which is definitely the major influence on Java. The rest boils down to "hey smalltalk is object-oriented and java is object-oriented, so java is based on smalltalk amirite?"
And the answer is no.