5 ms·

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

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.

thisisananth 16y ago
But it is evolution. isn't it and there be better software for all of us.
masklinn 16y ago
> Isn't this a bit of an unfair comparison? 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.
- bad_user 16y ago
  You're a little unfair in regards to C#. 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.
  - masklinn 16y ago
    > Since C# 1.1 they've only added features that are mostly orthogonal to the existing ones 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.
    - bad_user 16y ago
      Delegates (1.0) are types specifying method references, anonymous delegates (2.0) are anonymous code-blocks making usage of delegates, and lambdas (3.0) are just defined delegates with generic variables. "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).
      - masklinn 16y ago
        > Delegates (1.0) are types specifying method references, anonymous delegates (2.0) are anonymous code-blocks making usage of delegates, and lambdas (3.0) are just defined delegates with generic variables. 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?
- jbooth 16y ago
  Java learned a ton from previous language's mistakes. 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. 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..)
  - masklinn 16y ago
    > Java learned a ton from previous language's mistakes 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.
    - jbooth 16y ago
      Well, there's no pleasing some people. I bet Gosling's pretty happy with how it went over the last 15 years, though. 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?
      - masklinn 16y ago
        > Well, there's no pleasing some people. I bet Gosling's pretty happy with how it went over the last 15 years, though. 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.
- billmcneale 16y ago
  > Java simply refused to learn from previous language's mistakes. 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.
- j_baker 16y ago
  I would argue that Java learned a lot from other languages, just not ML or Haskell. Parts of it are heavily based on Smalltalk, Objective-C, C++, Simula, Modula-3, and even Lisp.
  - masklinn 16y ago
    > Parts of it are heavily based on Smalltalk, Objective-C, C++, Simula, Modula-3, and even Lisp. 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.
gtani 16y ago
scala vs. F# is a mroe interesting: http://programmers.stackexchange.com/questions/9095/what-are-the-biggest-differences-between-f-and-scala http://programmers.stackexchange.com/questions/9095/what-are... http://news.ycombinator.com/item?id=1374635 http://news.ycombinator.com/item?id=1374635 http://www.developer.com/features/article.php/3883051/Scala-vs-F-Comparing-Functional-Programming-Features.htm http://www.developer.com/features/article.php/3883051/Scala-... http://stackoverflow.com/questions/2905081/scala-versus-f-question-how-do-they-unify-oo-and-fp-paradigms http://stackoverflow.com/questions/2905081/scala-versus-f-qu...

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.

thisisananth 16y ago

But it is evolution. isn't it and there be better software for all of us.

masklinn 16y ago

> Isn't this a bit of an unfair comparison? 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.

bad_user 16y ago
You're a little unfair in regards to C#. 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.
- masklinn 16y ago
  > Since C# 1.1 they've only added features that are mostly orthogonal to the existing ones 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.
  - bad_user 16y ago
    Delegates (1.0) are types specifying method references, anonymous delegates (2.0) are anonymous code-blocks making usage of delegates, and lambdas (3.0) are just defined delegates with generic variables. "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).
    - masklinn 16y ago
      > Delegates (1.0) are types specifying method references, anonymous delegates (2.0) are anonymous code-blocks making usage of delegates, and lambdas (3.0) are just defined delegates with generic variables. 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?
jbooth 16y ago
Java learned a ton from previous language's mistakes. 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. 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..)
- masklinn 16y ago
  > Java learned a ton from previous language's mistakes 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.
  - jbooth 16y ago
    Well, there's no pleasing some people. I bet Gosling's pretty happy with how it went over the last 15 years, though. 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?
    - masklinn 16y ago
      > Well, there's no pleasing some people. I bet Gosling's pretty happy with how it went over the last 15 years, though. 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.
billmcneale 16y ago
> Java simply refused to learn from previous language's mistakes. 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.
j_baker 16y ago
I would argue that Java learned a lot from other languages, just not ML or Haskell. Parts of it are heavily based on Smalltalk, Objective-C, C++, Simula, Modula-3, and even Lisp.
- masklinn 16y ago
  > Parts of it are heavily based on Smalltalk, Objective-C, C++, Simula, Modula-3, and even Lisp. 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.

gtani 16y ago

scala vs. F# is a mroe interesting: http://programmers.stackexchange.com/questions/9095/what-are-the-biggest-differences-between-f-and-scala http://programmers.stackexchange.com/questions/9095/what-are... http://news.ycombinator.com/item?id=1374635 http://news.ycombinator.com/item?id=1374635 http://www.developer.com/features/article.php/3883051/Scala-vs-F-Comparing-Functional-Programming-Features.htm http://www.developer.com/features/article.php/3883051/Scala-... http://stackoverflow.com/questions/2905081/scala-versus-f-question-how-do-they-unify-oo-and-fp-paradigms http://stackoverflow.com/questions/2905081/scala-versus-f-qu...