4 ms·

> I am really not. My claim is a general one about Scala's kitchen-sink design philosophy, and why it's inappropriate for an "big engineering" language, as oppo

> I am really not. My claim is a general one about Scala's kitchen-sink design philosophy, and why it's inappropriate for an "big engineering" language, as opposed to fast development languages like Ruby or Perl, yet it is you who insist on focusing on detail, which is part of the problem. So I responded to the detail. And that claim is just not defensible in any kind of way. Have a look at C# and C++. Both of them are magnitudes more kitchen-sinky than Scala by pretty much every measurable metric. Both of them are considered to be “big engineering languages”. Don't believe me, look into the spec. Scala is certainly not the language which ships features which have been explicitly designed for working with the MS Office API for example. I can give you dozens more if you want. > You are most certainly wrong here, though I can't prove it. You're forgetting that 99.9% of Java code is not open-source. In the organizations where I previously worked we used annotation processing where needed. Well, there is certainly Scala code which isn't open-source, too. That doesn't mean that looking at the existing, available software out there is not a reasonable metric. Anyway, even if that point was wrong, I have mentioned a lot of issues concerning Java's annotations processing and pretty much every item should be a deal-breaker if the goal wasn't to ship a failed experiment. People use Java annotation processing, because the alternatives are even worse, not because Java annotation processing is so great. > Those brightest minds are usually the brightest minds in PL research. I don't think it's a coincidence that most of the languages designed by them, while brilliant in some respects, are not widely adopted in the industry. Those are the brightest minds which shipped most of the stuff which made C# great. I wouldn't call C# PL research by any means. > while other areas, like developer productivity, I find to be the wrong problems to focus on. Developer productivity is certainly not the sole focus of Scala. But developer productivity means that people have more time to look at the hard problems they are trying to solve instead of fighting the language and shipping the business value they are paid for instead of wasting time on unrelated issues. A language which has e. g. concurrency done right, but is so painful to deal with that everyone writes single-threaded code to get home early, is completely useless. > but a language that makes collections the domain of experts without at least fixing the real hard issues, is just plain misguided. Scala's collections are the most pleasant ones I have worked with and I think most people will disagree on that. I also think that Scala's trade-off on letting the library authors solve hard problems once instead of letting every user deal with them on their own each and every time they use it is a reasonable trade-off. In other languages you would probably have to implement every operation yourself if you wanted to define a new collection type. Mostly tedious, error-prone work. In Scala instead, you understand the CanBuildFrom facility once and get almost the complete implementation for free, overriding only the operations you care about. Note that understanding CanBuildFrom is a one-time effort, while in other languages you will hit those issues every time you want to create a new collection type. Again, seems like a reasonable trade-off to me.

pron 13y ago
BTW, when I said developer productivity I didn't mean actual productivity (which is harder to quantify, as it includes all time spent on testing and maintenance throughout the lifetime of the project), but "developer productivity" as it's become known in PL vernacular to mean less boilerplate and fewer LOC. And I guess we'll just agree to disagree, because I think we disagree about what's important even more than we disagree about the merit of each feature in Scala on its own. I believe Scala's tradeoffs are very misguided (and yeah, C++ is certainly similar) while you think they're justified. I believe that even an excellent feature should be left out of a language if it increases its complexity and the benefits do not solve a problem I care about every day, while you might think it's OK to increase a language's complexity even for features that won't be used so often. I think that in modern software development, application developers are better served by an opinionated language (especially when it comes to concurrency) while infrastructure software developers (assuming your software environment allows to easily mix languages) can certainly live with some annoying boilerplate if the language "closer to the metal", but both value simplicity; you might think that "one language to rule them all" with few constraints is preferable even at some cost to both types of developers.
- frowaway001 13y ago
  > I believe that even an excellent feature should be left out of a language if it increases its complexity and the benefits do not solve a problem I care about every day, while you might think it's OK to increase a language's complexity even for features that won't be used so often. No, I don't think we disagree here at all and I think it's one of the design principles behind the language. “do not solve a problem I care about every day” is just another phrase for “anything I'm remotely unfamiliar with”. And again, just because you decided to not invest the time to understand thing X, doesn't mean all daily users of X are idiots. You couldn't offer much here except structural types, so let me just take it is an example. Structural types were not “added” to the language because they are “so great and useful”, but because it eliminated an inconsistency where one would have types which one could express and a subset of types which would be e. g. a valid type for a method's parameter. Treating types consistently is a huge reduction in complexity for users because they don't have to divide types into types which can be used everywhere and types which can't be used everywhere. If you think this is just an academic idea, have a look at the weird corner cases this creates in Java where you can call methods on an instance directly, but if you assign that instance, the methods seem to not exist anymore. Ceylon, by the way not only agrees on that with Scala, but the designers marked this as one of their pillars of language philosophy (principal types). Almost everything you can do in Java is probably easier and more consistent in Scala. Claiming that those things which Java can't do (e. g. having a remotely useful type system (1), typeclasses, ...) make the language simpler is just trying to ignore that problems are not solved by wishing them to go away. Those things just crop up in an ugly way elsewhere, be it in ridiculously complicated frameworks, in bytecode manipulation, etc. (1) There is a reason proponents of dynamically-typed languages bring up Java when they explain what's wrong with static typing.

pron 13y ago

BTW, when I said developer productivity I didn't mean actual productivity (which is harder to quantify, as it includes all time spent on testing and maintenance throughout the lifetime of the project), but "developer productivity" as it's become known in PL vernacular to mean less boilerplate and fewer LOC. And I guess we'll just agree to disagree, because I think we disagree about what's important even more than we disagree about the merit of each feature in Scala on its own. I believe Scala's tradeoffs are very misguided (and yeah, C++ is certainly similar) while you think they're justified. I believe that even an excellent feature should be left out of a language if it increases its complexity and the benefits do not solve a problem I care about every day, while you might think it's OK to increase a language's complexity even for features that won't be used so often. I think that in modern software development, application developers are better served by an opinionated language (especially when it comes to concurrency) while infrastructure software developers (assuming your software environment allows to easily mix languages) can certainly live with some annoying boilerplate if the language "closer to the metal", but both value simplicity; you might think that "one language to rule them all" with few constraints is preferable even at some cost to both types of developers.

frowaway001 13y ago
> I believe that even an excellent feature should be left out of a language if it increases its complexity and the benefits do not solve a problem I care about every day, while you might think it's OK to increase a language's complexity even for features that won't be used so often. No, I don't think we disagree here at all and I think it's one of the design principles behind the language. “do not solve a problem I care about every day” is just another phrase for “anything I'm remotely unfamiliar with”. And again, just because you decided to not invest the time to understand thing X, doesn't mean all daily users of X are idiots. You couldn't offer much here except structural types, so let me just take it is an example. Structural types were not “added” to the language because they are “so great and useful”, but because it eliminated an inconsistency where one would have types which one could express and a subset of types which would be e. g. a valid type for a method's parameter. Treating types consistently is a huge reduction in complexity for users because they don't have to divide types into types which can be used everywhere and types which can't be used everywhere. If you think this is just an academic idea, have a look at the weird corner cases this creates in Java where you can call methods on an instance directly, but if you assign that instance, the methods seem to not exist anymore. Ceylon, by the way not only agrees on that with Scala, but the designers marked this as one of their pillars of language philosophy (principal types). Almost everything you can do in Java is probably easier and more consistent in Scala. Claiming that those things which Java can't do (e. g. having a remotely useful type system (1), typeclasses, ...) make the language simpler is just trying to ignore that problems are not solved by wishing them to go away. Those things just crop up in an ugly way elsewhere, be it in ridiculously complicated frameworks, in bytecode manipulation, etc. (1) There is a reason proponents of dynamically-typed languages bring up Java when they explain what's wrong with static typing.