> 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.
> “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.
I wasn't calling anyone an idiot, and I don't know who you are, buddy, but I'm starting to get the feeling that I might have some years experience over you; perhaps even a decade, so chill.
Look, you can go on believing Scala is simple all you want for whatever measure of simplicity you define; Martin Odersky even tried using grammar size as a measure (personally, I wouldn't go for consistency as a measure, though, because machine language is also very consistent, but YMMV...)
Then, you can try to get the team working on the next aircraft-carrier control system (or a huge mail routing system or air traffic control software) to adopt Scala, and see how fast they throw you out the window.
> Claiming that those things which Java can't do (e. g. having a remotely useful type system (1), typeclasses, ...)
Again with the features. I don't care about what type system a language has and how mathematically correct it is. I care about writing maintainable, correct and efficient code. Types might help achieve those goals, but it's not as if the more "correct" the type system is, the better those goals will be served. Why? some of the reasons are cultural, some have to do with the way humans think, and some have to do with the way computers "think".
You think Scala helps achieve those goals, I think Scala is detrimental to them. I abandoned Scala about 5 years ago and I have no intention of using it again, especially now when there are languages which I find superior to Scala in every respect that I think matters. If you feel Scala works for you I'm not going to convince you otherwise. For me and for the organizations I've worked for it didn't work at all.
> You think Scala helps achieve those goals, I think Scala is detrimental to them. I abandoned Scala about 5 years ago and I have no intention of using it again, especially now when there are languages which I find superior to Scala in every respect that I think matters. If you feel Scala works for you I'm not going to convince you otherwise. For me and for the organizations I've worked for it didn't work at all.
I think this explains all of it. The thing you are talking about has pretty much no resemblance with Scala today. You can bash Scala-from-5-years-ago as much as you want as long as you stop misleading people that your claims are in any way relevant to what Scala is today.
Really, look at how your extrapolations from pre-historic Scala versions worked out til now. You only embarrassed yourself. I recommend being honest next time and just sharing your experience about Scala 2.5/2.6/2.7. I think we could all have a good time telling war stories, considering how hilariously unstable the compiler was at that time.
Dude, look, I stopped using Scala because it's gotten sooo much worse worse with each version; whatever coherence it had at first, it quickly shed away in a frenzy of misguided notions about what developers really need. I actually liked it in the early days. My claims are my view, as someone who's been developing software professionally for over two decades. I am well aware that there are those who disagree. Of course, you are entitled to your opinion. It could be the best damn language in the world for you, but it sucks for many, many others. I can tell you that some companies looked at Scala carefully and rejected it; some adopted it only to discard it a couple of years later. You should accept the undeniable fact that Scala does not appeal to some knowledgeable, experienced people, even after they consider it carefully. And it's OK - I like many things that other people don't like, and they have good reasons not to like them. I would concede that Clojure, too (and I really think Clojure is an exceptionally well designed language), does not have a very broad appeal; neither does Scala.
Use it in peace. If 5 years from now a significant portion of the software development community is using Scala, then you were right and I was wrong; if not, you'd better recheck your convictions. Maybe the language you like so much doesn't solve problems that hurt badly enough, or doesn't solve them well enough, for people to pay the price of its complexity and lack of coherence.
Either way, Scala has certainly taught us a few things and we can learn from its mistakes. Maybe some of the lessons will be used to create a language that works for me and those who see things my way, too.
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.