6 ms·

> 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

> 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
> Sorry, but no it isn't and it's painfully clear to a lot of people. As is the opposite... Language debates are like that. > -Abstraction and code maintenance... No. Scala does not enforce that. You can no more be certain that changing one item involves touching one place in Scala than in, say, Java. Scala does not enforce (or even make violations hard) thread-local state modifications as Clojure does. It allows global, mutable, variables. Scala gives you some useful abstractions with one hand, while giving you harmful ones with the other. In fact, structural types are a prime example here. You can rename a method and your code will break just as it would in Ruby or JavaScript. > -Long-term evolution and extensibility This is really unsupported by evidence. How many Scala projects over, say, 2MLOC and older than 5 years are there? C++ had the same claim. Some of its abstractions helped maintenance, while some harmed it. But Scala's adoption is too small to tell. > - Closing the decade-old gap between data inside and data outside of a language Yeah, they're cool, but Java has had (compile-time) annotation processors (as well as AST generators) for quite some time, and they're well integrated with IDEs, too. Adding macros to the language seems a bit of an overkill. Also, I really doubt that will be a "huge productivity boost". Data formats are pretty standardized. You don't come up with a new one every week, or even every month, and most common data formats already have "type providers" for most languages (say JSON, CSV, XML, SQL, protocol buffers, ASN.1). This is not a big, unaddressed, problem with modern software development.
- frowaway001 13y ago
  > As is the opposite... Language debates are like that. It would work much better if you didn't make up assumptions and tried to sell them as facts. There is a slight difference between “it's possible to disagree about X” and “your claim about X doesn't survive 2 minutes of fact checking”. > Scala does not enforce [...] You can accept the points I made or discuss them, but this is just moving the goalposts AGAIN. You asked “What big software development problem (as opposed to a PL research problem) does Scala solve?” And I gave you a few points. You didn't ask “Is Scala the best thing ever and the last language we need?” and I certainly didn't answer “Yes!”. With your own straw-man which you're trying to make up now, probably only Haskell and a few close friends would suffice, but certainly none of the languages you're trying to sell. Hey, in Scala could at least use the effect plugin, but I haven't such a plugin for e. g. Kotlin yet. > In fact, structural types are a prime example here. You can rename a method and your code will break just as it would in Ruby or JavaScript. Why should that happen? > This is really unsupported by evidence. Don't believe me, just look into to spec or try the language. Again I didn't claim that Scala solves all the problem and makes it impossible for malicious people to write code in a way which will break in the future. No language claims that and you didn't see me claiming that either. As I mentioned, Scala gives you a lot of useful tools which can reduce maintenance issues and some features are designed around the idea of helping you achieve that. > Yeah, they're cool, but Java has had (compile-time) annotation processors (as well as AST generators) for quite some time, and they're well integrated with IDEs, too. Adding macros to the language seems a bit of an overkill. I can't really tell whether this is sarcasm or not. - There is a reason why basically no language since Java adopted that model. - It's pretty damning to see that in the few months in which macros existed, more useful functionality was written than for Java annotation processing ever. - Annotation processing integrates very poorly with IDEs, I'd say not at all. Again, there is a reason why pretty much every annotation processing library needs a special IDE plugin to stop the IDEs from being confused. Just try developing with AspectJ in Eclipse without the AspectJ-for-Eclipse plugin. It just doesn't work. - Annotation processing adds additional hassle to the build script, which needs to be setup, configured and maintained. It's not the first time that I have seen that multiple annotation processing plugins interfered with each other, leaving behind unusable class files and runtime exceptions in production. - Again, IDE support is very poor. You can't even jump from an annotation to the corresponding annotation processing code. The IDE will just jump to the annotation declaration, which is completely unhelpful. Do you want to have a guess which of the issues mentioned above can't exist by design in Scala's macros? All. > Also, I really doubt that will be a "huge productivity boost". Data formats are pretty standardized. You don't come up with a new one every week, or even every month, and most common data formats already have "type providers" for most languages (say JSON, CSV, XML, SQL, protocol buffers, ASN.1). This is not a big, unaddressed, problem with modern software development. I kind of feel like you are missing the context here. I recommend watching one of the F# talks for an introduction. Again, just because you don't see the benefit or the reasoning behind it, doesn't mean that the brightest minds in our profession are all wrong.

pron 13y ago

> Sorry, but no it isn't and it's painfully clear to a lot of people. As is the opposite... Language debates are like that. > -Abstraction and code maintenance... No. Scala does not enforce that. You can no more be certain that changing one item involves touching one place in Scala than in, say, Java. Scala does not enforce (or even make violations hard) thread-local state modifications as Clojure does. It allows global, mutable, variables. Scala gives you some useful abstractions with one hand, while giving you harmful ones with the other. In fact, structural types are a prime example here. You can rename a method and your code will break just as it would in Ruby or JavaScript. > -Long-term evolution and extensibility This is really unsupported by evidence. How many Scala projects over, say, 2MLOC and older than 5 years are there? C++ had the same claim. Some of its abstractions helped maintenance, while some harmed it. But Scala's adoption is too small to tell. > - Closing the decade-old gap between data inside and data outside of a language Yeah, they're cool, but Java has had (compile-time) annotation processors (as well as AST generators) for quite some time, and they're well integrated with IDEs, too. Adding macros to the language seems a bit of an overkill. Also, I really doubt that will be a "huge productivity boost". Data formats are pretty standardized. You don't come up with a new one every week, or even every month, and most common data formats already have "type providers" for most languages (say JSON, CSV, XML, SQL, protocol buffers, ASN.1). This is not a big, unaddressed, problem with modern software development.

frowaway001 13y ago
> As is the opposite... Language debates are like that. It would work much better if you didn't make up assumptions and tried to sell them as facts. There is a slight difference between “it's possible to disagree about X” and “your claim about X doesn't survive 2 minutes of fact checking”. > Scala does not enforce [...] You can accept the points I made or discuss them, but this is just moving the goalposts AGAIN. You asked “What big software development problem (as opposed to a PL research problem) does Scala solve?” And I gave you a few points. You didn't ask “Is Scala the best thing ever and the last language we need?” and I certainly didn't answer “Yes!”. With your own straw-man which you're trying to make up now, probably only Haskell and a few close friends would suffice, but certainly none of the languages you're trying to sell. Hey, in Scala could at least use the effect plugin, but I haven't such a plugin for e. g. Kotlin yet. > In fact, structural types are a prime example here. You can rename a method and your code will break just as it would in Ruby or JavaScript. Why should that happen? > This is really unsupported by evidence. Don't believe me, just look into to spec or try the language. Again I didn't claim that Scala solves all the problem and makes it impossible for malicious people to write code in a way which will break in the future. No language claims that and you didn't see me claiming that either. As I mentioned, Scala gives you a lot of useful tools which can reduce maintenance issues and some features are designed around the idea of helping you achieve that. > Yeah, they're cool, but Java has had (compile-time) annotation processors (as well as AST generators) for quite some time, and they're well integrated with IDEs, too. Adding macros to the language seems a bit of an overkill. I can't really tell whether this is sarcasm or not. - There is a reason why basically no language since Java adopted that model. - It's pretty damning to see that in the few months in which macros existed, more useful functionality was written than for Java annotation processing ever. - Annotation processing integrates very poorly with IDEs, I'd say not at all. Again, there is a reason why pretty much every annotation processing library needs a special IDE plugin to stop the IDEs from being confused. Just try developing with AspectJ in Eclipse without the AspectJ-for-Eclipse plugin. It just doesn't work. - Annotation processing adds additional hassle to the build script, which needs to be setup, configured and maintained. It's not the first time that I have seen that multiple annotation processing plugins interfered with each other, leaving behind unusable class files and runtime exceptions in production. - Again, IDE support is very poor. You can't even jump from an annotation to the corresponding annotation processing code. The IDE will just jump to the annotation declaration, which is completely unhelpful. Do you want to have a guess which of the issues mentioned above can't exist by design in Scala's macros? All. > Also, I really doubt that will be a "huge productivity boost". Data formats are pretty standardized. You don't come up with a new one every week, or even every month, and most common data formats already have "type providers" for most languages (say JSON, CSV, XML, SQL, protocol buffers, ASN.1). This is not a big, unaddressed, problem with modern software development. I kind of feel like you are missing the context here. I recommend watching one of the F# talks for an introduction. Again, just because you don't see the benefit or the reasoning behind it, doesn't mean that the brightest minds in our profession are all wrong.