Often the argument is that if languages are superheroes, Scala is trying to be one with all the possible superpowers. When you learn how to use them and have control over when to use them (and for good or bad), everything will be a breeze. But the assumption that everyone will spend time learning the right ways and not use in production before achieving zen is impractical.
If you compare Scala other recently released languages (swift, kotlin, ceylon) they're all kindof similar, some claim to be less complex but imho aren't. Functional + OO is becoming the norm: the C# team is considering to add pattern matching and it looks like java 10 may have some twisted form of type classes.
'Scala the language', is imho very nicely designed, the problems arise in the compiler implementation and the core libraries. Scala carries around too much dead weight in it's core libraries. Some poor choices were made while scala wasn't widely used yet and it's very hard to fix that now. If you look at the roadmap for scala it's obvious that they are trying to address these issues.
Clojure is much, much less complex then Scala and it is functional and OO. Many people see clojure as purly functional but clojure programmes are often designed in OO style as well.
OO here meaning polymorphism over types of your data 'object'. The diffrence is that you usally never mutate your object.
It is fair to say however that the emphasis of clojure is functional and your code is expected to be functional style, only when you really need it, you start adding polymorpism but even then protocolls are expected to be a implementation detail quite often. Also, we access our objects the same way we do our hashmaps and even the same function often work on both objects or hashmaps.
Some people might of course dislike this approche where OO is not really not used in the traditional way and is kind of pushed down. So clojure I would say, is techniclly multi-paradigm but culturally its not.
We've had dynamic OO+FP languages for a very long time but only in the last 10 years have we seen them with static type systems. I really like clojure (though I haven't used it in anger) but I think you're wrong when it comes to complexity.
Complexity with dynamic languages grows with the size of the project. I know that because of the focus on purity & immutable data structures clojure mananges to mitigate this problem but I'm afraid it's still there.
The last few years several features have been added to clojure that increased the complexity(/surface area) of the language and the documentation is often a mess. I'm not a clojure hater, just pointing out that the complexity with clojure lies elsewhere.
edit: kinda forgot about Ocaml (~18 yrs old apparently)
> Complexity with dynamic languages grows with the size of the project.
I was talking about language complexity, not how complex the project is.
That said, I have nothing against static typing, my argument was not really about typing at all. It was more about how OO and functional interact in clojure compared to java. Also types by itself dont really make all that good of a documentation, at least not the kind you care about when looking something up in the internet.
I am a fan of schema, and I think the future really is in the combination of schema and core.typed. I dont really like to devlop with pre set types and structures, but you could with schema/core.typed. I prefer to work dynamiclly and once im happy with the shape of my data, I 'set it in stone' by writing the correct schema for it. Then you can just always validate everything during devlopment/staticlly. When you deploy you can turn on validation only for data from the outside. This is how I would like to do it, until schema and core.typed work together I just use schema.
For the most part macros make most code much, much easier to read. The clojure compunity is also really fixed in its way, how and when macros are written.
Take one example, core.match. Now in a language that does not have pattern matching code that can be easly written with pattern matching is very hard to read. In clojure its very easy to read.
Now one might argue that a 'good' langauge should have support for pattern matching. To that I say, the language creators can never have all the features everybody wants, it will slow down devlopment of the language and increase complexity.
I would rather read one or two nice clojure macros that reduce tons of boilerplate as you would need in other languages. The same happens in other languages, for exmaple rust. I really enjoy using macros there as well. Give me a language with macros 100%, it improves read and write ability in the waste majority of cases.
If you really belive that core.typed makes clojure as verbose as Java then you have not looked at it. Also, its not like people use clojure over java because they dont have to write down types. There are tons of other reasons people use clojure.
Also, core.typed can do things that java can not.
> Yes, but it doesn't even have types!
While I understand what you mean, you should write down what you mean. Clojure has types, but not static typing.
... except Scala isn't confident enough to be an instrument. It has to be all of them it once. It's a trumpet with strings taught across the bell (which you can play with or without a bow), and drum skin draped over the leadpipe.
It's a construction set with many pieces which you can combine to make new instruments. Maybe you have a mouldable body which can be made to support one neck and several auxiliary strings... and then you have a harp guitar. Maybe add some tenor strings to that later.
"support one neck and several auxiliary strings..."
And then as you add more and more features suddenly a case class has 22 and the whole thing crashes down but nobody told you about the 22 airity limit because "the ivory tower says thats bad design and I don't care what the real world needs" and although redesign is simple enough, its kinda shocking. I wonder what other silent spinning propellers can be walked into without warning. Maybe none, maybe lots, but I don't look forward to the ensuing ivory tower tongue lashing because I dared to use it in the real world.
Languages shouldn't get in your way. Even if the real world IS doing it wrong, it should at least support you failing with some style and grace.
And as the powerpoint shows, that compiler is possibly the slowest compiler I've ever used for a given complexity of task. Really... my project was an internal use only super specialized vaguely crud app using play framework for weird engineering data, but nothing fundamentally shocking or unusual, and a full compile from clean source shouldn't take 7 minutes and 33 seconds. What is that like one second per line of source?
Those complaints said, everything worked and it was vaguely enjoyable and interesting although a boring CRUD app does not exactly scratch deeply into the language features. Was a fun experiment, probably wouldn't do it again.
You know quite well that the removal of this restriction is brand new and it would be very easy to encounter it in the wild.
Why do you go out of your way to use smarmy tactics to argue against anytime someone who has a legitimate complaint? It would be way more productive to acknowledge the weaknesses and then tell the good story of Scala.
There are valid complaints about Scala, but the complaints from all those HN armchair experts are far removed from it. There is nothing useful to be done except making fun of it.
Are you claiming that there wasn't an arity limit on case classes that you could run into through no fault of your own using the Scala web stack? Or just that if you had to diagnose that problem it shouldn't bother you as it isn't a valid complaint?
What would elevate someone from HN "armchair expert" in your mind, such that their complaints were valid? Is it even possible for someone to mention something they don't like about Scala without you immediately dismissing them as not knowing what they are talking about?
