4 ms·

> 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

> 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
> You can accept the points I made or discuss them, but this is just moving the goalposts AGAIN. 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. > Why should that happen? Sorry, I made a mistake there. The compilation will break when you try to pass the object to a method that accepts that structural type. > 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. 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. > 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. 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. You can only attribute some of that to marketing. I also do not think it's a coincidence that all languages developed at Google, a company that knows a thing or two about large scale development, follow the Java philosophy. I am not a PL researcher and not particularly interested in PL research aside from learning a thing or two about the potential of programming languages, but I am very much interested in moving the software development industry forward. Some of the things PL researchers focus on I find to be genuine problems with software development – like taming concurrency, which Haskell does a good job at though perhaps at an unacceptable cost to the industry, and Clojure and Erlang do an excellent job with despite their lack of PL researchers – while other areas, like developer productivity, I find to be the wrong problems to focus on. Let me explain the last point because I think it's important. We have some good languages (Ruby, Python) that are excellent for productivity, and are extensively used in some domains. Where those languages fail - concurrency, large-scale engineering - productivity is less of an issue. But then I found Clojure (and, mind you, I personally prefer static typing and think it's generally better for engineering, though I recognize this is just a means to an end), and saw a language that is probably as "productive" as Ruby, yet actually tackles the big issues (like making sure some careless team member does not introduce a very hard to find race condition). I think Scala takes powerful though complex features and channels them – unlike, say, Haskell – into all the wrong places (productivity), and at the same time makes it impossible for a mere mortal to understand how a basic collection is written. You can argue details all you want with me, and say that you could do this and could do that, but a language that makes collections the domain of experts without at least fixing the real hard issues, is just plain misguided.

pron 13y ago

> You can accept the points I made or discuss them, but this is just moving the goalposts AGAIN. 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. > Why should that happen? Sorry, I made a mistake there. The compilation will break when you try to pass the object to a method that accepts that structural type. > 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. 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. > 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. 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. You can only attribute some of that to marketing. I also do not think it's a coincidence that all languages developed at Google, a company that knows a thing or two about large scale development, follow the Java philosophy. I am not a PL researcher and not particularly interested in PL research aside from learning a thing or two about the potential of programming languages, but I am very much interested in moving the software development industry forward. Some of the things PL researchers focus on I find to be genuine problems with software development – like taming concurrency, which Haskell does a good job at though perhaps at an unacceptable cost to the industry, and Clojure and Erlang do an excellent job with despite their lack of PL researchers – while other areas, like developer productivity, I find to be the wrong problems to focus on. Let me explain the last point because I think it's important. We have some good languages (Ruby, Python) that are excellent for productivity, and are extensively used in some domains. Where those languages fail - concurrency, large-scale engineering - productivity is less of an issue. But then I found Clojure (and, mind you, I personally prefer static typing and think it's generally better for engineering, though I recognize this is just a means to an end), and saw a language that is probably as "productive" as Ruby, yet actually tackles the big issues (like making sure some careless team member does not introduce a very hard to find race condition). I think Scala takes powerful though complex features and channels them – unlike, say, Haskell – into all the wrong places (productivity), and at the same time makes it impossible for a mere mortal to understand how a basic collection is written. You can argue details all you want with me, and say that you could do this and could do that, but a language that makes collections the domain of experts without at least fixing the real hard issues, is just plain misguided.