7 ms·

As some people already mentioned, you should really stop treating your personal opinions (which quite often lack both substance and any evidence) as the one tru

As some people already mentioned, you should really stop treating your personal opinions (which quite often lack both substance and any evidence) as the one true thing. I also find it a bit irritating that you love the vague claims like in the last article, but don't like articles with a precise and to-the-point description of issues. It's almost like you want to love all negative articles on Scala, but have to hate even neutral or remotely positive ones, completely irregardless of the quality of the article and the issues raised in them. It leads to this whole train-wreck of reasoning here which you seem to be forced to post in pretty much every post with the word “Scala” in it. Nobody can prevent you from spending your time with things you hate, but from my experience, live is happier if you spend it on things you love. I can't say it any better than dancapo said it here: https://news.ycombinator.com/item?id=6844600 https://news.ycombinator.com/item?id=6844600 Maybe you should really at least try to consider the points he raises.

pron 13y ago
There is very little in my comment pertaining specifically to Scala. I did not like or dislike anything in the previous article as I barely skimmed it (unlike this one, which I've read). The specific issues mentioned in this one are all well and good, but since the main point here is about ditching an old language in favor of a new one, I responded to that. I don't know which "reasoning" you're referring to, as I simply pointed out that when discussing something that can be a major decision for a software company as switching languages, it's best not to start with specific language features, as they may lead you down the wrong path. Also, I try to form my opinions after a lot of consideration, and you can be certain that I read most arguments against them. Sometimes I remain unconvinced, as in the case of Scala. I am not prejudiced against Scala. I think Martin Odersky is a very smart PL researcher, and when Scala first came out many years ago, I actually strongly advocated adopting it in a very, very large organization. My opinion has changed over the years, partly because of the path Scala has taken, partly because of new options that are now available, and partly because I've gained more experience with large projects and large teams. My own criticism of Scala is, I believe, well informed; the fact that you consider its lack of minute detail as lack of evidence demonstrates the Scala's community obsession for tiny details to the detriment of a grander vision. The comment you referred me to demonstrates the same. I do not dispute that Scala's features are well integrated in the compiler. It's a very nice compiler. What I meant in my comments on those other threads is that Scala mixes concepts whose mix creates a negative synergy, whose only purpose is that sometimes you can use one concept and sometimes you can use another. It doesn't matter that case classes are implemented as classes. Conceptually, they are meant to be used differently; again, that's getting bogged down in detail. Scala never gives a compelling reason why it is so useful to mix different concepts in a single language and pay such a heavy price in complexity, other than "sometimes it's better to use one and sometimes another". That's not a hallmark of great design. What big software development problem (as opposed to a PL research problem) does Scala solve?
- frowaway001 13y ago
  > My own critique of Scala is, I believe, well informed; Sorry, but no it isn't and it's painfully clear to a lot of people. > the fact that you consider its lack of minute detail as lack of evidence demonstrates the Scala's community obsession for tiny details to the detriment of a grander vision. You have a lot of talent in interpreting things the way you want. If people would have said “there are minor inconsistencies, but Scala has a grand vision it focuses on and that's what counts” you would have turned around and argued that it's the lack of attention to detail which makes everything in Scala horrible. Sorry, but I have seen how you do this more than I care to count already. It gets tiring and embarrassing to read. People have tried to tell you that “making up facts to retroactively fit your opinions” is not a good thing and then you just do it again: > I do not dispute that Scala's features are well integrated in the compiler. Let's just ignore the way you try to derail the debate here and move the goalposts around for a minute, because probably everyone who has spent 5 minutes to look at the actual source code realizes how mind-boggling wrong this claim is. The compiler goes to great lengths to catch all the weird corner cases and shield it's users from inconsistencies which e. g. sometimes arise when running on a JVM or having to deal with other languages running on that platform. Please have a look at javac, fsharpc and others. None of them come even close to effort scalac does to present its users with a consistent, coherent behaviour. They just let the user deal with all those minor annoyances. > Scala never gives a compelling reason why it is so useful to mix different concepts in a single language and pay such a heavy price in complexity, other than "sometimes it's better to use one and sometimes another". That's not a hallmark of great design. Sorry, you mentioned it yourself already that your mainly interested in a language which dresses up Java's minor pain points. I can understand that when coming from that point of view trying to understand the reason why Scala does things in a certain way is not interesting. But you should at least differentiate between “there is no reason” and “I didn't care enough to look for the reason”. > What big software development problem (as opposed to a PL research problem) does Scala solve? - Abstraction and code maintenance: In all languages, you can arrive at a certain point where refactoring/abstracting things any further (to increase readability, maintainability, modularity) doesn't add more value than it costs. The difference is that in Scala you are the one who can make this decision, not the compiler. This is a huge advantage, which can't be understated, but is also hard to describe if you haven't seen it yourself. Dropping into an unknown code base and being able to be positive that changing/fixing/modifying one item involves touching one place, instead of possibly dozens or hundreds of pieces of code, is a considerable benefit. (Not really related to this, but implicit classes are an interesting example of how lots of code maintenance issues are made impossible by design, when compared to inferior approaches like extension methods.) - Long-term evolution and extensibility: Scala gives you lots of options and tools to evolve your code in a way which minimizes the impact on the consumers of your code. Have a look at how Scala doesn't expose any public fields in classes, how easy ensuring binary compatibility is with tools like the Migration Manager, have a look how typeclasses enable you to design your code with extension points in mind right from the start, have a look how @deprecated and friends allow you to have meaningful transitions between old and new code if necessary. This reduces the amount of technical debt accumulated over a period of time and makes it easy to keep existing code bases up to the changing/growing requirements of the real world. - Closing the decade-old gap between data inside and data outside of a language: Type providers go a huge step toward a state where developers can just stop worrying whether their data is in the source code of their language, inside a database, stored in an XML file, or wherever else. This will be a huge productivity boost to all developers.

pron 13y ago

There is very little in my comment pertaining specifically to Scala. I did not like or dislike anything in the previous article as I barely skimmed it (unlike this one, which I've read). The specific issues mentioned in this one are all well and good, but since the main point here is about ditching an old language in favor of a new one, I responded to that. I don't know which "reasoning" you're referring to, as I simply pointed out that when discussing something that can be a major decision for a software company as switching languages, it's best not to start with specific language features, as they may lead you down the wrong path. Also, I try to form my opinions after a lot of consideration, and you can be certain that I read most arguments against them. Sometimes I remain unconvinced, as in the case of Scala. I am not prejudiced against Scala. I think Martin Odersky is a very smart PL researcher, and when Scala first came out many years ago, I actually strongly advocated adopting it in a very, very large organization. My opinion has changed over the years, partly because of the path Scala has taken, partly because of new options that are now available, and partly because I've gained more experience with large projects and large teams. My own criticism of Scala is, I believe, well informed; the fact that you consider its lack of minute detail as lack of evidence demonstrates the Scala's community obsession for tiny details to the detriment of a grander vision. The comment you referred me to demonstrates the same. I do not dispute that Scala's features are well integrated in the compiler. It's a very nice compiler. What I meant in my comments on those other threads is that Scala mixes concepts whose mix creates a negative synergy, whose only purpose is that sometimes you can use one concept and sometimes you can use another. It doesn't matter that case classes are implemented as classes. Conceptually, they are meant to be used differently; again, that's getting bogged down in detail. Scala never gives a compelling reason why it is so useful to mix different concepts in a single language and pay such a heavy price in complexity, other than "sometimes it's better to use one and sometimes another". That's not a hallmark of great design. What big software development problem (as opposed to a PL research problem) does Scala solve?

frowaway001 13y ago
> My own critique of Scala is, I believe, well informed; Sorry, but no it isn't and it's painfully clear to a lot of people. > the fact that you consider its lack of minute detail as lack of evidence demonstrates the Scala's community obsession for tiny details to the detriment of a grander vision. You have a lot of talent in interpreting things the way you want. If people would have said “there are minor inconsistencies, but Scala has a grand vision it focuses on and that's what counts” you would have turned around and argued that it's the lack of attention to detail which makes everything in Scala horrible. Sorry, but I have seen how you do this more than I care to count already. It gets tiring and embarrassing to read. People have tried to tell you that “making up facts to retroactively fit your opinions” is not a good thing and then you just do it again: > I do not dispute that Scala's features are well integrated in the compiler. Let's just ignore the way you try to derail the debate here and move the goalposts around for a minute, because probably everyone who has spent 5 minutes to look at the actual source code realizes how mind-boggling wrong this claim is. The compiler goes to great lengths to catch all the weird corner cases and shield it's users from inconsistencies which e. g. sometimes arise when running on a JVM or having to deal with other languages running on that platform. Please have a look at javac, fsharpc and others. None of them come even close to effort scalac does to present its users with a consistent, coherent behaviour. They just let the user deal with all those minor annoyances. > Scala never gives a compelling reason why it is so useful to mix different concepts in a single language and pay such a heavy price in complexity, other than "sometimes it's better to use one and sometimes another". That's not a hallmark of great design. Sorry, you mentioned it yourself already that your mainly interested in a language which dresses up Java's minor pain points. I can understand that when coming from that point of view trying to understand the reason why Scala does things in a certain way is not interesting. But you should at least differentiate between “there is no reason” and “I didn't care enough to look for the reason”. > What big software development problem (as opposed to a PL research problem) does Scala solve? - Abstraction and code maintenance: In all languages, you can arrive at a certain point where refactoring/abstracting things any further (to increase readability, maintainability, modularity) doesn't add more value than it costs. The difference is that in Scala you are the one who can make this decision, not the compiler. This is a huge advantage, which can't be understated, but is also hard to describe if you haven't seen it yourself. Dropping into an unknown code base and being able to be positive that changing/fixing/modifying one item involves touching one place, instead of possibly dozens or hundreds of pieces of code, is a considerable benefit. (Not really related to this, but implicit classes are an interesting example of how lots of code maintenance issues are made impossible by design, when compared to inferior approaches like extension methods.) - Long-term evolution and extensibility: Scala gives you lots of options and tools to evolve your code in a way which minimizes the impact on the consumers of your code. Have a look at how Scala doesn't expose any public fields in classes, how easy ensuring binary compatibility is with tools like the Migration Manager, have a look how typeclasses enable you to design your code with extension points in mind right from the start, have a look how @deprecated and friends allow you to have meaningful transitions between old and new code if necessary. This reduces the amount of technical debt accumulated over a period of time and makes it easy to keep existing code bases up to the changing/growing requirements of the real world. - Closing the decade-old gap between data inside and data outside of a language: Type providers go a huge step toward a state where developers can just stop worrying whether their data is in the source code of their language, inside a database, stored in an XML file, or wherever else. This will be a huge productivity boost to all developers.