6 ms·
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 co
by bilalhusain 12y ago
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.
- pjmlp 12y agoProgramming is like learning music. 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.
- deleted 12y ago[deleted]
- seanmcdirmid 12y agoAnyone can learn how to play piano. Few play it well. It is much easier to master the cowbell. Analogies are so OO.
- macmacbr 12y agoI've seen so many people having problems with the cowbell. I don't think it holds true. :)
- seanmcdirmid 12y agoThe existence of people who cannot master cowbell doesn't mean that it is as hard to master as the piano :)
- pron 12y ago... 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.
- Dewie 12y agoIt'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. It's a scalable language by design.
- VLM 12y ago"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.
- frowaway001 12y ago> case class has 22 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 > 22 airity limit 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%29.aspx 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/package-summary.html 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.
- oelang 12y agoIf 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.
- pjmlp 12y agoFully agree, the future is multi-paradigm.
- nickik 12y agoClojure 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.
- oelang 12y agoWe'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)