'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.
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.
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)
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.
Yes, but it doesn't even have types! (Except clojure-typed, which is so cumbersome and verbose that it's faster to just write Java.)
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.
Isn't that a very low bar?
> Clojure has types, but not static typing.
Types are – by definition – static.
(defalias AnyMonad
"A monad with bind, result, and optionally zero and plus."
(TFn [[m :< (TFn [[x :variance :covariant]] Any)]]
'{:m-bind (All [x y]
[(m x) [x -> (m y)] -> (m y)])
:m-result (All [x]
[x -> (m x)])
:m-zero (U (All [x] (m x)) Undefined)
:m-plus (U (All [x]
[(m x) * -> (m x)])
Undefined)}))
Until you need to decipher someone else's code full of NIH macros.
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.
My point is that there are many types of code complexity and abusing macros for your in-house DSL is one of them.
This happens a lot in many Lisp shops.
Some people are willing to invest the time needed to learn to play piano, guitar, violin...
Others are happy to be able to play triangles.
Analogies are so OO.
It's a scalable language by design.
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.
Works fine for me:
scala> case class Foo(a1: Int, a2: Int, a3: Int, a4: Int,
a5: Int, a6: Int, a7: Int, a8: Int,
a9: Int, a10: Int, a11: Int, a12: Int,
a13: Int, a14: Int, a15: Int, a16: Int,
a17: Int, a18: Int, a19: Int, a20: Int,
a21: Int, a22: Int, a23: Int, a24: Int)
defined class Foo
Tons of other languages have limitations like this too. I wonder why people are obsessed with it only when comparing Scala.
C#: 16 for Func/Action http://msdn.microsoft.com/de-de/library/dd402862%28v=vs.110%...
Java: 2 (BiFunction<T,U,R>) http://docs.oracle.com/javase/8/docs/api/java/util/function/..., 255 for methods
Plus, it's on the roadmap to get fixed, unlike in most other languages.
> 7 minutes and 33 seconds
You setup is definitely broken.
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.
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?