In Defense of Scala. Response to “I Don’t Like Scala”
blog.gridgainsystems.com
blog.gridgainsystems.com
Besides this, Scala has way too much Java in it to really be "algebraically elegant" or even simple! Scala is a compromise. It has the legacy of Java compatibility dragging it down. That's one of the main reasons it's caught on, but it's also the reason it isn't actually particularly simple or elegant. It's one of the most complex (but not necessarily difficult) languages in common use.
It is nowhere near as elegant or simple as OCaml or Haskell as they can afford to be much closer to the λ-calculus. Which is also why they can afford such incredible things like tail call elimination and type inference!
Also, while Scala is a multiparadigm language, it is not the best of both worlds. In embracing Java and OO, it throws away many of the advantages of functional programming. In fact, any non-trivial functional programming quickly becomes unbearable. Especially compared to Haskell.
Edward Kmett wrote a nice Reddit post[1] about how Scala falls short from a functional standpoint. This is from an entirely practical commercial standpoint based on his experiences at S&P Capital IQ. Here is what he had to say about functional programming in Scala: "If scala was the only language I had to think in, I'd think functional programming was a bad idea that didn't scale, too." A pretty strong image!
Their story is interesting: they took a Java project to Scala. It was an incredible improvement. Then Scala became a pain on its own, so they designed their own functional language for the JVM[2] and moved to that. It was the same sort of incredible improvement. The same thing that happened to Java happened to Scala!
Ermine, their new programming language, is basically like the core of Haskell adopted to the JVM along with some interesting new features. One thing that really stood out for me is that they have customizable type error messages: they can have type errors that are domain-specific! That by itself probably has a fair amount of value.
[1]: http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...
He ends his semi-rant with a concession: there's a lot of good in Scala, and that's absolutely true, there is _so much good_ in Scala that only when you leave it's confines do you realize, shit, I miss:
immutability
lazy vals
case classes
pattern matching
named parameters
implicits
import aliases
partial functions
Option, Either (wish latter was biased)
map/flatMap/fold & collections FP friends
Ok, compile times and IDE support leave something to be desired, but things have improved by leaps and bounds in the past 3 years, and more goodness to come with Scala 2.11 in (hopefully) March.
Really? Could you point me to some of his evangelizing? Or did you mean "he uses haskell and is quite happy with it"? Because that isn't the same thing.
>inconsistencies that the average programmer will never even realize exist.
Do you honestly believe that? http://www.youtube.com/watch?v=TS1lpKBMkgg
>Scala that only when you leave it's confines do you realize, shit, I miss
But the very point Edward makes is that you don't give up those things when you leave scala. You only give up those things if you leave scala for something worse. You could leave for something better, keep all those things, and get tons of important things that you also won't realize you are missing until you get used to them and then try to live without them.
Kmett has, I believe, taken on a larger role in Haskell, perhaps officially with FP Complete. At any rate he does mention in one his videos (maybe on www.haskellcast.com) that he is coding less now due to his new obligations, which includes [completely from fallible memory] promoting [read: evangelizing] the language.
>inconsistencies that the average programmer will never even realize exist.
Referring to a presentation by Paul Phillips, an absolute Scala giant, and equating that with what the average Scala programmer encounters in their daily work does not negate my argument...in the slightest.
When you leave Scala and remain on the JVM there is no better statically typed alternative, IMHO. When you leave the JVM, then yes, you can dive into Haskell and experience (compared to Scala) longer compile times, yelp o_O, poor to non-existent (IDE) tooling (just type :t in the REPL to see the inferred type, AKA beginner's joy), lack of an enterprise ecosystem, and yes, purity in all its glory, with a superior type system and quite a friendly community of mostly brilliant minds.
In the end I'd say there's some degree of PITA everywhere, even in Haskell. Just getting my feet wet, maybe I'll learn to love it, but for now, to get shit done in the real world, it's Scala and the JVM.
He says, after suggesting you can't trust what someone says because they are an evangelist.
>Kmett has, I believe, taken on a larger role in Haskell, perhaps officially with FP Complete
FP complete is an independent company and has no official involvement in GHC or any other haskell implementation. Edward is not involved with FP complete. Edward is involved in the haskell community and the scala community. In neither case is he anything like an evangelist (which would make no sense anyways, you can't convert the converted). It seems odd that you are so adamant about inventing a fictional promotional context for him after claiming there's nothing wrong with that.
>Referring to a presentation by Paul Phillips, an absolute Scala giant, and equating that with what the average Scala programmer encounters in their daily work does not negate my argument...in the slightest.
Perhaps you should actually take the time to listen to it. A significant part of what he was saying was "this stuff matters". Just because the person doing the presentation knows scala very well, does not mean the problems he points out do not effect people who know scala less well.
>When you leave Scala and remain on the JVM there is no better statically typed alternative, IMHO
I am not sure how that is relevant. I don't care about the JVM.
>Just getting my feet wet, maybe I'll learn to love it, but for now, to get shit done in the real world, it's Scala and the JVM.
Or this. Do you remember the part where I tried to convince you to use haskell? Neither do I.
What the hell are you talking about? I provided a counterpoint to Kmett's detailing all that is wrong with Scala, by providing some of the good. Kmett is a living legend, I'm not questioning the guy's integrity; he went off in that reddit thread based on his [deep] experience of the language, which is entirely non-average.
re: Paul Phillips, he's knows Scala probably better than anyone else on the planet; yes, the soundness of the compiler affects everyone, but those who are most bitten and bothered by it are library authors (read: advanced users), not end users who remain, for the most part, unaware of whatever issues may lie under the hood.
> Or this. Do you remember the part where I tried to convince you to use haskell? Neither do I.
Other than Haskell, given the context of the thread, which language might you be referring to as the better alternative to Scala?
> You could leave for something better, keep all those things, and get tons of important things that you also won't realize you are missing until you get used to them and then try to live without them.
That sounds great! I am curious about leaving Scala for something better -- please name this better alternative that is presumably not Haskell.
> I am curious about leaving Scala for something better -- please name this better alternative that is presumably not Haskell.
With apologies if you think this is too OT and/or if you are uninterested in immature languages/ecosystems, let me mention Rakudo and its increasingly capable JVM backend.
Today's Rakudo Star release (Star means "batteries included") is expected to be the last to ship without Rakudo's JVM backend. Almost certainly there'll be a February Rakudo Star release and it is expected to support the JVM backend out of the box.
I would be happy to say more about why I think P6 is going to become relevant again one day, perhaps this year, to folk at least interested in Scala.
Exactly what I said. You can go read your post if you have forgotten its contents.
>not end users who remain, for the most part, unaware of whatever issues may lie under the hood.
You are simply repeating yourself. Paul Phillips contradicts you, and I find him to be much more credible.
>Other than Haskell, given the context of the thread, which language might you be referring to as the better alternative to Scala?
Ocaml, F#, SML and clean.
>please name this better alternative that is presumably not Haskell.
Why would it not be haskell? Haskell is pretty obviously the best option.
Scala is far from perfect, to be sure; even ten years in the future I'd expect/hope there will be a better option, whether that's Ceylon, Fantom, Ermine or something else. But right now Scala is in the sweet spot: it's a huge step up from most popular languages, and at the same time it's mature, popular, and java-compatible enough to be a practical choice for many projects.
And as someone who does FP in Scala all the time, I'd be interested to hear what you're talking about with your "pretty strong image".
(Also I think Scala's @implicitNotFound covers the interesting cases for customizable type error messages, no?)
The reason most people use Scala is because of JVM support and Java interop. Those are exactly the reasons that typeful programming can be a pain in Scala. Multi-arg functions don't compose as easily as curried functions. No TCO. Subtyping breaks extensive type inference. The JVM is Scala's blessing and its curse. I wish more people realised this. It would save us from a lot of frothing-at-the-mouth blog posts, if nothing else.
It isn't functional, but that's fine, it's based on the JVM after all so things like tail-call optimization are going to be tough anyway. It has non-nullable by default variables. It supports immutable data (and encourages you to use it as much as possible). The way you instantiate an instance of an object is very much like the way types are instantiated in Haskell. It has mixin inheritance which is very similar to an OO version of the class system in Haskell.
In other words, it isn't Haskell, isn't trying to be Haskell, and isn't functional, but it does have a lot of the things I love from Haskell, and it feels very elegant to boot. Scala I feel is what happens when you literally try to copy chunks of Haskell on top of Java, and it's a mess. Ceylon I think is what happens when you take the best features of Haskell, and where it makes sense to do so apply them to a traditional OO system.
I'd still rather do something in Haskell, but if I absolutely must use a JVM based language, I think Ceylon is a very strong contender that would make a lot of people who are familiar with Haskell feel right at home.
No, it doesn't try to be Haskell. It tries to be something very different from Haskell which happens to share some features with Haskell.
You, presumably, don't like what it actually tries to be, and that's fine, but its just incorrect to say that it is trying to be Haskell but doing it poorly.
Is this a joke? The Scala collections library are terrible. They are inconsistent, hard to reason about, suffer from scope creep, and have terrible performance characteristics.
Do you have a code sample for this?
def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value }
From HashMap.scala
def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) }
The problem is that the incoherent design of the collections library means that it is not clear to the programmers of the default mutable hash map lookup what they are striving for.
If they were striving for performance they would use a model that allowed for NPE against safety, that had allocation semantics that were sensible. Conversely, if safety was the overriding concern they wouldn't allow for the NPE.
Instead, in one of the most central data structures of the language we get unreasonable behavior. This is clearly a sign of bad design, thus reputing the original assertion that the Scala collections library were a good example of type programming.
PS: To trivially answer your question, they should have inverted the implementation here. A NPE throwing method for lookup wrapped with option sugar would make way more sense than the inverse.
http://docs.scala-lang.org/resources/images/collections.muta...
AbstractCollection
AbstractList
AbstractMap
AbstractMap.SimpleEntry
AbstractMap.SimpleImmutableEntry
AbstractQueue
AbstractSequentialList
AbstractSet
ArrayDeque
ArrayList
Arrays
BitSet
Collections
Dictionary
EnumMap
EnumSet
HashMap
HashSet
Hashtable
IdentityHashMap
LinkedHashMap
LinkedHashSet
LinkedList
PriorityQueue
Stack
TreeMap
TreeSet
Vector
WeakHashMap
ArrayBlockingQueue
ConcurrentHashMap
ConcurrentLinkedDeque
ConcurrentLinkedQueue
ConcurrentSkipListMap
ConcurrentSkipListSet
CopyOnWriteArrayList
CopyOnWriteArraySet
DelayQueue
LinkedBlockingDeque
LinkedBlockingQueue
LinkedTransferQueue
PriorityBlockingQueue
SynchronousQueue
BlockingDeque
BlockingQueue
ConcurrentMap
ConcurrentNavigableMap
TransferQueue
Collection
Deque
Iterator
List
ListIterator
Map
Map.Entry
NavigableMap
NavigableSet
Queue
RandomAccess
Set
SortedMap
SortedSet
If you are using the collections library as example of how to structure your own code, you are in for a bad time. The abstractions are not right, and things like the silly ParSeqViewLike trait are an expression of that.
I really liked the look of the language and I started trying to develop my solution in it. I knew exactly what I wanted to do, and had a reasonable idea of what to write to get there.
Holly molly, compilation times were absolutely horrible. I tried to persevere but a tiny change would mean 2 minutes waiting for a recompile. In the end I just switched to python where I could develop a solution from scratch (remember, the Scala solution was 90% finished) in no time at all.
Would like to look closer at the language one day but I have better things to do with time than waiting for a machine to churn through code.
incremental compilation: sbt> ~run
in most cases code changes should take one second. Note: SBT sub projects are God's gift to Scala devs (or Mark Harrah's gift at any rate).
You have to get your feet wet in the language, trying something last week for a day or two is not going to result in you flying to the moon on the productivity spaceship of delight.
Programming in Scala 2nd edition is a great intro to the language.
Otherwise, a book or 2 on Scala goes a long way.
I've found Scala to be very expressive and well suited to large-scale systems. It takes some effort to learn the language, but once you have put in the effort coding in Scala is a pleasure (esp. compared to Java).
What a claim! What an absurdity!
Dynamically type checked memory safe languages (eg. Python, Ruby, Javascript, etc...) enable styles of programming impossible in non-dynamically checked languages. So it certainly isn't the users who are being "intellectually lazy." Nor are the creators, who have focused on productivity and usability instead of waiting for proof systems (static type checkers) to catch up with their ideas. Laziness doesn't factor in on either side.
and you're done with it (assumes a valid object of course, which can be a rather large assumption on the dynamic side of the fence ;-)).
It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result.
I basically render everything server-side and use JSON sparingly (e.g. AJAX responses). Until Scala pickling or other cutting edge lib allows me to convert an arbitrarily complex object graph from A to B without the boilerplate, I'll keep to the server-side and leave client-side templating...off to the side.
The popular scala libraries only require one line of boilerplate per class for that, e.g. in spray-json I do jsonFormat3(MyClass) and then I can do myObject.toJson. With scala 2.11's implicit macros this will go down to 0 lines and work exactly like in ruby/groovy/etc.
(Whether the scala ecosystem will want it to be 0 lines or prefer to keep the 1 line as a "flag" for which objects should be convertible to json is an open question, but scala-the-language certainly supports doing it the 0-boilerplate way)
> It's a total PITA in Scala to query your DBMS; marshall a tuple result to a collection of case class(es) and then have to go down boilerplate road again in order to create a a typesafe JSON result.
Huh? Squeryl just gives me the results as my case classes (I have to define the schema somewhere, but I have to do that with e.g. Django as well). I don't even need to do the json conversion explicitly - as long as it's the only serializer for that type in scope, spray will pick it up implicitly.
The example I gave was for objects of arbitrary complexity; it's a trivial operation in dynamic languages because there are no types (or 1 type if you like). In Scala, this is not (yet) the case, beyond a certain point you have to roll up your sleeves and do the marshelling yourself.
Even when there's no simple 1-to-1 mappings. I don't see why you think unityping makes this serialization easier?
If you can marshall objects of arbitrary complexity to JSON in Haskell with a single line of code that covers all possible cases (e.g. your entire database model), consider me beyond impressed.
And also, deserialization is going to be more concise in Haskell because type inference decides which type to deserialize to.
A few months ago I took a stroll through available Haskell libraries for web dev., found Yesod, HaskellDB, and a couple of other glue items.
What's the state of the art on the web framework front in Haskell? Snap looks interesting but incomplete, and HaskellDB is fairly ancient (LINQ-to-SQL lib would probably get me very interested in Haskell sooner rather than later). Assume email, PDF generation and other web must-haves exist in Haskell ecosystem.
I know the Yesod ecosystem is well-developed and should have good solutions for most problems. I think the downside of Yesod is that it is not as principled/based-on-sound-theory as most of the Haskell ecosystem is, so it gets a lot of negative sentiment. But it solves a real problem now -- at least until a principled approach is proven.
Yesod also has "persistent", which can persist over SQL and IIUC, nosql DB's as well.
Snap is more minimalist, and solves a smaller part of the problem for you -- but is much simpler (and perhaps more elegant) than Yesod.
Happstack is another web framework, like Yesod (all 3 are under active development). Its main problem (perhaps this was fixed already) was prevalent use of "lazy I/O" which is very controversial. I personally despise lazy I/O and think it violates the basic principles that make Haskell great. I heard something about Happstack immigrating to an alternative to lazy I/O though.
Email is a solved problem in the Haskell ecosystem, as far as I can tell.
PDF libraries exist: http://hackage.haskell.org/packages/#cat:PDF but I haven't used them, so I don't know how good they are.
I don't know about other must-haves. I know an automatic "admin webpage" didn't exist until recently even in the Yesod ecosystem. A friend who encountered this missing piece contributed one, but it was pretty barebones/preliminary. This was a couple years ago though.
In other words, a simple web project is in order. Snap looks like a good call, along with Yesod's Persistent. PDF, email, etc. can come later, just trying to explore the language.
Thanks again.
So, just like you would in a statically typed language like scala or haskell?
Really? How does this kind of shit not get downvoted to oblivion?
2. This is a well written about issue.
3. I do not consider my claim absurd if I did I would not have made it.
4. If you do not have experience writing significant amounts of code in a dynamic language I don't expect you to agree with me nor do I think that I could convince you with some half baked micro examples. It is the type of opinion which emerges out of years of writing code in both dynamic and statically checked languages.
2. It is not a well written about issue at all. If it was you would show some support for it rather than try to deflect.
3. Of course not. But your claim is still absurd, being ignorant of this fact does not change it.
4. I have likely been programming in untyped languages longer than you have been alive. Your claim was not an opinion, you stated a (completely incorrect) factual thing. "I like untyped languages" is an opinion. "Dynamically typed languages let you do things that are impossible in statically typed languages" is a factual claim, one which is complete nonsense, and you have totally failed to support.
You made a completely baseless claim, and then when asked to support it said "no, you support my argument for me". That is what I said deserves to be downvoted to oblivion, not your original bullshit claim, which is just typical ignorance.
Common collections lack both of these things.
[1] The notion of configuring your build tool in a full programming language is alluring but ultimately a bad idea IMO; builds should be simpler and more declarative than that.
Scalaz is a library that I wish I grokked better, but in all I think it has hurt as much readability as it ever hoped to help. That is, learning the concepts I fully want to do. Using the opaque names, not so much. I'd rather have that level of understanding on my target domain, not category theory. (Were I only smart enough to do both...)
I also agree regarding Akka. I want to like it, but I also feel it purposefully makes things complicated. It was hilarious to read the quote from Torvalds saying that "distributed algorithms are really hard" in context of why microkernels are hard to do, and then see Akka basically say that they make it so that all algorithms are written in a distributed way. Or sad. Not sure which.
Don't get me wrong, if what you are doing is already a distributed algorithm, then it doesn't hurt. But turning all algorithms into distributed algorithms just seems crazy. Unless, I suppose, you don't care about such things as speed and memory consumption.
On Akka home page, in bold "Build powerful concurrent & distributed applications more easily."
I can't deal with Maven's position of "Oh, you want to have some tiny bit of intelligence in your build? Guess what, a) fuck you, b) write a crappy plugin for it." anymore after seeing that simple things can be indeed simple and straightforward with SBT.
I think this is actually an astute criticism of Scala as a language, and not just the SBT library; it holds true for many of its more unconventional features.
Scala is probably not a good language choice if you/your team are prone to shooting themselves in the foot.
and I like it that way
We use the latter but we have a very complex build—multi-JVM testing, half-dozen subprojects.
Ouch. So if I choose to use python, ruby, javascript, lisp, - I am 'intellectually lazy'?
As for using them... eh. My subjective view is that scala is much better than all those languages, outside certain small domains. But that's not exactly objective fact. I will say that if you don't know scala then you're being intellectually lazy - even compared to ocaml, it's different enough to be worth knowing, and it's a language you'll learn something from, whether you ultimately find yourself using it or not.
Also, as you probably know, it's possible to program static typed projects in a Lisp.
>every thought I don't have to think about static types is a thought I can instead think about something I actually care about.
Static types do not add something to think about. You already have to think about what things are. Static types just let the compiler ensure that you didn't make any mistakes. Passing a user object into a function that wants a string isn't suddenly useful because there is no type system giving you an error.
Perl 5 that is. Perl 6 has a (gradual) type system.
Q to the op is what is the turn over of your dev team? Please provide a defense of Scala in terms of economics of development (from a business pov). Items to address are maintaining the codebase after the whiz kids have left for more exciting pastures.
I've seen the same thing said about Common Lisp.
As for Scalaz elitism, the canonical example would be the T-hole himself, _ Morris (who has more or less been expelled from the main Scala user groups). I think the general POV the OP is trying to convey is that Scalaz is an incomprehensible cluster fuck of symbols to everyone but those in the know; in other words, the learning curve is steep and historically the response to beginner questions has been something along the lines of, "go read this paper" a la Haskell.
SBT suffers a similar problem but that's, IMO, more due to lack of IDE support for the project/ build than anything else (i.e. it's difficult to discover [for me] the library without being able to click through method calls and experientially explore the code [Scala docs only get me so far]).
In other news the last milestone of Scala 2.11 was just released; 2014 should be a good year for Scala on many fronts (faster compilations and improved IDE support particularly)
There's a lot of tutorials in Haskell that are papers, but if you go to #haskell or ask on stack overflow, the answer to questions are rarely "go read this paper", at least in my experience (even for some pretty deep type-level programming stuff).
Right, I get that there are lots of scala people who are very anti-intellectual and are vehemently opposed to learning anything. But what I don't get is how "if I don't learn this stuff, I don't understand it" is "snobbism" on the part of people providing the library you didn't learn.
>and historically the response to beginner questions has been something along the lines of, "go read this paper" a la Haskell.
I have not seen that response in either scalaz or haskell. It sounds an awful lot like the common strawman used to dismiss haskell as "academic" from people who have never bothered to try it. Practical experience with haskell in particular has been that people are ridiculously accommodating and helpful.