M'eh. Yes, Scala has flaws but I feel like this talk makes too much of minor annoyances. Ultimately you make an engineering decision about platform. Do you want decent performance, lotsa libraries, and a modern statically typed language? Scala is arguably your best option at present (yes this can be argued with; no that isn't an interesting argument to have). Maybe we'll all be using Rust/Haskell/whatever in 5 years, but in the meantime I got code to write and products to build and I'm using Scala for better or worse.
Specifically:
- Code on slide 3 has typos. (Yeah, that's minor)
- Lambdas are slower than Java 8 -- that's because Scala currently supports Java 6+. Java 8 has been released for 6 months. This is a ridiculous complaint.
- Heavy in terms of concepts -- another ridiculous complaint. If you want to keep on writing Java, keep writing Java. If Scala didn't bring new stuff to the table it wouldn't be interesting.
- Implicits -- agreed they can be misused. Type classes are the way forward.
- I don't understand many of the "very ugly" complaints. Yes, collections have lots of methods. Is this surprising? Yes, library code may be written in an abstract way. So what? Yes, DSLs look like DSLs. Yes, abstracting over arity is a problem in all statically typed languages. etc.
There are valid complaints to be made about Scala. I feel this talk demonstrates a lack of understanding of the language, and many of its complaints are in fact misunderstandings.
To me the biggest issue this talk reveals is that if you come from an OO background (which I assume the author does) then learning Scala will require a change of mindset. I don't think it is fair to make this a language complaint though. Scala makes it fairly obvious what you're getting yourself into and, as I said above, if you wanted to keep on writing code the way you have in the past it's not clear why you are using Scala in the first place.
Scala gives you an excellent way to go about changing your mindset though. I feel like functional logic at a granular level wrapped in OO structures is a very logical way to go about building the kinds of software that Scala is being used for.
> If you want to keep on writing Java, keep writing Java.
Ah! But that’s the point, because Scala is pulling a bait-and-switch. If it were only a modern statically typed language I wouldn’t complain so much about it (and I really do complain a lot about Scala, I guess). Yes, I find its gaudy indiscrimination aesthetically unpleasing[1], but that’s a matter of personal taste. The problem is that Scala still markets itself as “a better Java”, and people are drawn to it so they wouldn't have to write getters and constructors. And at first, Scala does seem to be that. Only after a while you realize that it’s a whole other beast altogether — not necessarily the one you bought into. If Scala were marketed as “a JVM language Haskellers can learn to live with”, I’d have no issue with it (except the aesthetics, that is :)).
[1]: Yet, with its near-infinite list of features it can't even type immutability, which even Java 8 can through its pluggable type systems.
There is a point in my presentation that says that some of these annoyances are easy to overcome in a real project. But some of them aren't.
As for the misunderstandings - the "bad" parts are ..bad. The ugly parts may not be bad, but are ugly (which is subjective, and I think it's implied it's subjective)
"I don't understand many of the "very ugly" complaints. Yes, collections have lots of methods. Is this surprising?"
Perhaps "very ugly" refers to method names like "/:". (Example on slide 22. There are many more examples of "very ugly" in that slide, too.)
This reflects on the culture, not the language, but it means in practice you will need to read lots of code with random punctuation used for method and function names. Unless you never use any libraries and never work with other Scala developers who write code like this.
I feel that most of (not all) the criticisms are fair, but superficial.
True, the IDEs are poor, for a certain definition of poor. Had I not used IntelliJ for Java, for example, I'd find IntelliJ for Scala amazing. Knowing how much better it can be spoiled me, but frankly, IntelliJ for Scala is not bad. It just could be better.
Also, Emacs has a very robust Scala mode.
True, there's a lot to learn before you can consider yourself fully fluent. You do not need to know everything, however. And once you've started on the path, things tend to flow naturally. For example, implicit conversions are easy to grasp. Once you understand them, implicit parameters and type classes are not much more complicated. Once you know type classes, it opens the door to a lot of functional "design patterns" - functors, applicatives, monads... these are not strictly necessary, but they're fun to learn about. And they teach you algebraic data types, which in Scala means case classes, sealed traits, ... it all sort of flows naturally.
True, it's easy to write absolutely un-maintainable code. While that's true of any language, Scala makes it rather easier than most. It's also very easy to write highly maintainable, legible code, and to avoid complex, ascii art based operators (or at the very least to offer wordy equivalences at 0 cost through `@inline`). I feel that saying "it can be hard to read, if you don't follow basic guidelines" is a bad reason not to use a language. A good reason to be careful, though.
My personal experience is that, once you start feeling comfortable with the language, you get much more productive than with Java. It does require some initial work, though: if all you know is OO, learning how to design your code for composition rather than inheritance takes a while - it takes a while just to realise that it's not a bad idea, let alone embrace it!
Also, ScalaCheck. Man, do I wish there was a good Java equivalent for some of my legacy code (that would not require me to rewrite all of my tests).
Scala does take more work to learn than Java, but I never choose Java over Scala for a new project. Scala is just so much more modern and expressive.
You can write perfectly readable Scala. It just takes some taste and common sense, or alternatively follow guidelines such as: http://twitter.github.io/effectivescala/
We've found IntellJ + Scala to be an excellent combo for our purposes.
I agree that the criticism is fair. It does seem to come from someone with relatively little experience, but if anything, that makes it more valuable. Languages need adoption and new adopters by definition have no experience.
Regarding IDE support, which inevitably comes up when discussing Scala, an honest question: what are good IDEs for Ruby, Python, Clojure, JavaScript, Haskell, OCaml? Is there a good IDE for C++ besides Windows-only Visual Studio? For C?
It seems that Scala always get compared to Java in that domain, but in my experience Java is the exception, not the norm.
(Edit: I assume support for CLR languages is great too?)
Once you know type classes, it opens the door to a lot of functional "design patterns" - functors, applicatives, monads... these are not strictly necessary, but they're fun to learn about.
For a certain value of "fun", I guess.
Generally I find in engineering that it's best not to add abstraction (or other forms of complexity) to a system unless there are strong, clear benefits to doing so. The more we learn about Scala, it's just not clear that it delivers those benefits (in proportion to the time investment it demands).
It's not that I don't "dig" abstraction. It's just that I have an infinite list of things to learn about (some fun, some not so fun) in any given development environment. (In general, most of these are in the non-fun category: dealing with dependencies,build tools, and legacy quirks that can never be fixed).
And another infinite list in my own problem domain -- you know, that thing I'm supposed to be, theoretically, directly working on (in the service of which all of these fancy software tools were supposed to be a means, not an end). Plenty of very real and juicy abstractions. More than I can ever hope to get to the bottom of, in fact.
But don't get me wrong. If applicatives and such are your bag, then that's great. Maybe Scala is the right language for you, then.
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.
The IDE story has vastly improved in Scala, certainly nowhere near that of Java but decent nonetheless. The best way to shoot yourself in the foot is to have automatic build turned on in your IDE and to run SBT in a separate terminal; with that approach you get dog slow compilations, blocked UI, and other hair pulling madness. When SBT is boss (i.e. IDE auto build turned off and compile target shared between the two) then you'll have a far saner development experience.
The OP hasn't been using Scala for long so many of his gripes boil down to lack of experience. You have to learn the ropes, the (myriad) corner cases, etc. of the language before things start to click.
It's like starting out in Haskell, where on earth do you even begin to understand this utterly new paradigm, much less go into production with large scala projects in it? The answer is: you don't, you learn, learn, learn until you're well grounded in the language and its frameworks; then you bet the bank on it because you're sold on its clear-as-day powers.
I'll go out on a limb and say that the only viable type safe alternatives to Scala and its ecosystem are C#/F# on .NET, and Haskell. In other words, yes, Scala has its warts, but overall is pretty much unmatched in terms of expressivity, power, and performance.
I like Scala, but it gets me that the official IDE, Scala IDE, is so utterly broken. If you let the IDE handle the build, you'll constantly get spurious compilation errors, which in a statically typed language are unacceptable.
Letting SBT do the build may work, but come on. This is the official IDE! Is there any acknowledgement in scala-ide.org that you should let SBT to do the build? Do Odersky and the guys at Typesafe use that setup, or do they suffer their IDE silently?
Saw some Scala at a conference recently. The guy was demonstrating using it to do TDD.
I lost track somewhere in the first ten minutes or so, but it looked like he was importing/using multiple DSLs and helper libraries. After I lost track of the exact details, I started scanning for the gist of what he was doing.
After an hour, he had what looked like the most massive clusterfuck I've ever seen in a project file -- all to do something that would take a dozen lines or so of simple FP script. Seemed like every functional thing he used was either also an object or had to be bolted into an object graph for it to work. The project file had scores of things in it.
This did not leave a good impression. It reminded me of when I saw my first C/Win32 app and realized you needed a couple hundred lines of code and several files just to say "hello world" -- except this was a couple orders of magnitude more complex. It was a god-awful abomination.
Not all Scala projects are like this. There's a sect that wants to write tests in "human readable" fashion, e.g. the people who like Cucumber in Ruby; in Scala those same people write their DSLs within the language, something Scala is good at and that I'd argue provides real advantages over an "external" DSL. But you don't have to do that; I write Scala professionally and all my tests are just ordinary JUnit test methods.
Here is some actual test code, based on scalacheck:
property("to and from file") = forAllNoShrink(genArrayForSeries)( data => {
withTempDir(f => {
val (stagingDir, dataDir) = mkdirs(f)
val s = SequentialBinaryV1Storage(dataDir, stagingDir)
val id = SeriesIdent(UUID.randomUUID().toString)
val oldSeries = BufferedSeries(id, data._1, data._2)
s.write(oldSeries)
val newSeries = s.read(id).get
((oldSeries.ident == newSeries.ident) :| "identities do not match") &&
((oldSeries.data == newSeries.data) :| "data series do not match")
})
})
Not much DSL, though there are a few helper functions handling stuff like creating a tempdir for the test and deleting when finished.
Scala is going to be generally more concise than Ruby (which I think most consider fairly concise).
So the impression I get from your comment is that this was a fairly large and/or complex project he was attempting to demonstrate. Maybe it just wasn't real appropriate.
Does the syntactic diabetes really bother people? Like, yes, these are different sequences of characters that mean the same thing, but visually it's very clear that they are the same thing; it's not the perl "there is more than one way to do it" where the ways of doing it are conceptually very different. It seems no different from complaining that I can write f(a, b) or f((a), (b)), which is a choice you get in almost every language.
Implicits are dangerous, sure. Typeclasses are vital and extension methods are nice, but it might be better to cover these use cases with something more specific. That said, these days the IDEs flag up implicits so it's not really a problem day-to-day.
Concise really helps readability at the function/module level - there's a huge drop in readability when a function reaches the point that you can't fit it on one screen. It may well be that the 1-line scala version of a method takes exactly the same time to read as the 10-line java version - but if it means you can fit your whole class on one screen, that's still a win.
Symbolic method names are bad and I wish the community would move away from them.
The definition of ++ is perfectly sensible once you stop panicking and start actually reading it. As is the parser; sure, it's a DSL, it uses some short symbols, but I defy you to find a better way to express the parser given. When you're building up a complex parser, it's well worth having a concise notation.
jsonFormatX are legacy cruft. In a modern json library you can avoid them by using Shapeless instead; hopefully spray-json will do this too.
The .toSet() example is deprecated and will give a warning if you actually try and run it.
Java-8 style lambda compilation is already available under an experimental flag, and the next release will have full support.
> Does the syntactic diabetes really bother people? Like, yes, these are different sequences of characters that mean the same thing, but visually it's very clear that they are the same thing; it's not the perl "there is more than one way to do it" where the ways of doing it are conceptually very different.
Oh yes, this is one of the things that bother me the most about Scala, actually. I don't mind if there are conceptually different ways of achieving the same goal, as you put it, because those different ways usually have different trade-offs; if you're doing things one way instead of the other, you know why you're doing it, there's a certain benefit in doing it this way.
But syntactic diabetes is bad because it ultimately provides no real benefit. Different people will write different code based simply on their tastes and preferences and pretty soon you'll have a mess in your project codebase, unless you enforce strict rules and conventions about writing code. Furthermore, people who work in a team that enforces one set of conventions may have trouble when joining another team that uses a different set of conventions.
In Java, for example, this is not the case. Yes, there are things that the language itself doesn't enforce, and conventions are used, but these conventions are well known, and there's probably no Java developer on Earth who wouldn't adhere to them. When a totally new Java developer joins the team, she can usually read code right away, because there are no surprises with regards to the syntax. Sure, she'll need to spend some time perhaps to really get what's going on, because the code might be complex, but the syntax itself won't stand in her way.
Syntactic diabetes is to me the best warning sign.
It means the focus on orthogonality has been lost somewhere in the evolution of the language.
There should be only one way to express a given language operation, and this way should be the simplest and most elegant. Not just because of aesthetic (which is crucial when speaking about readability), but also because it would combine the most harmoniously with other parts of the language.
It seems to me that at this point scala should deprecate all non-essential syntactic sugar and features and reduce the language to its "core". Or, at the very least, people should
start a fork with that goal.
Hell, it could even be just a compilation option.
The author seems to think that java 8 lambdas are faster than scala lambdas. This isn't strictly true. Java 8 spins the inner classes for lambdas at first use, this gives them a performance boost at startup (loading tons of tiny classes from a jar is painfull for the jvm) but at runtime they perform the same (it's just invokevirtual). Another optimization that java 8 has is that lambdas that don't capture are cached & reused, scala does the same if you use the -optimize flag.
Maybe, but it's just a generic statement about programming, it has no real value in a critique of Scala specifically. Part of the beauty of any flexible language is you can go back and refactor it down to a more elegant solution as you learn more. That doesn't mean you have to boil the code down to a point where it is largely impossible to read any more in Scala than any other language.
There are real pain points in Scala when you try and scale it from single developers to teams working on a project and most of them are to do with the flexibility of the language.
I think all companies working with Scala end up settling on a sub-set of the language that they are happy with. In that sense, the bad is irrelevant: you are never put in a situation where, say, you are forced into using implicits (apart from light use in external libraries like lift-json) so if you don't use them you never suffer their downsides. If you obsess over parts of a language you don't even have to use... then well I'm afraid I have nothing but scorn for people like that.
At team-scale then your main pain point is trying to get style of writing that everyone can get behind. Code reviews can be painful when developers with different ideas on how to solve a problem butt heads and pull requests turn into "That's not how I would have written it" instead of critiquing the actual code presented.
The tooling and compiling I completely agree with. SBT is a horrific mess. I don't have a single good word to say about it.
Well, except the difference in definition between between "terse" and "concise" is that "concise" does mean easy to comprehend (and, in the context of a written medium, easy to read.)
The first thing that I actually thought about when I read this was junit hamcrest matchers, sure it's concise but I don't consider it readable at all. The limited expressivity of java really gets in your way.
With scala you can write test that are concise and readable with ScalaTest or ScalaCheck. The readability largely depends on the quality of the library that you use but also the user.
Yes, scala. I'm having some fun with it... but i'm also having a lot of arguments with it. I especially recognise the parts of "there is no best/single way of doing things". I can overcome the syntax diabetes.
I'd like to do functional programming, I'm doing server/web based stuff mostly. I'd like the language to have a big(large) ecosystem. Clojure is fun and all, but it's more or less a hackernews language. There are only a few serious businesses using it. It also lacks a web framework like Play!. Same goes for Haskell. So besides all the bad stuff of scala, having play and quite a large ecosystem is why i wanted to try it.
You should try Luminus, which concentrates all the basic libraries for web development.
Not as rich as Play! or Django but sufficient for doing a lot of things. It's also a great way to learn Clojure smoothly, it's far more accessible than Pedestal for a beginner.
I use scala a lot and it did become my go to general purpose language (as well as my workplace adopted it as a first class citizen and used for many new projects)
I do have issues with it, but mostly with developers using (abusing) it. (And library authors that are a bit religious about the functional paradigm and simply love their operators...
With great power comes great responsibility, the is no better description to this language.
Also, I was looking at the CanBuildFrom hell with fear, but Odersky et al's book on Scala surprisingly did a good job getting the pieces in place for me. It even makes sense of the madness.
Finally, Bozho is one of my most respected contributors on stackoverflow. And I can say that his slides actually do justice to Scala, I might disagree on the conclusions, but the facts are absolutely right.
I kinda agree with this. Scala has good bits. Very good bits. Gorgeously beautiful bits, even. But the ugly bits are so terrifyingly ugly that I dare not touch it.
Give me the Scala pattern matchers (that can also match by type and even by content of case classes, I believe), with the case classes and the actor concurrency model, but keep the horrendous type system and the confused parts of the syntax.
Odersky's Coursera is excellent. For me, it was vital to jumping the gap from "Here is a language that gives you a million ways to solve problems" to "I want to express this particular concept, so I designed a language well suited for expressing it".
From the looks of it, the author of these slides has written very little Scala. Take slide #7, for example, where he writes def bar() = { "1" } when def bar = "1" is perfectly sufficient. Ironically, I may very well be pointing out the bad parts of scala (i.e. that () is simply a convention for indicating Unit or side-effecting functions, but its just convention and not enforced by the type system in any way). Notwithstanding that, I don't think someone who has written very little Scala is in a great position to offer a reasonable critique.
This is a longer discussion, but in the very first slide he points to the object-orientation as a plus. In my opinion, he's already wrong. "There is no such thing as Object-Oriented programming." See: http://blog.higher-order.com/blog/2008/12/04/no-such-thing/
[+] [-] noelwelsh|11 years ago|reply
Specifically:
- Code on slide 3 has typos. (Yeah, that's minor)
- Lambdas are slower than Java 8 -- that's because Scala currently supports Java 6+. Java 8 has been released for 6 months. This is a ridiculous complaint.
- Heavy in terms of concepts -- another ridiculous complaint. If you want to keep on writing Java, keep writing Java. If Scala didn't bring new stuff to the table it wouldn't be interesting.
- Implicits -- agreed they can be misused. Type classes are the way forward.
- I don't understand many of the "very ugly" complaints. Yes, collections have lots of methods. Is this surprising? Yes, library code may be written in an abstract way. So what? Yes, DSLs look like DSLs. Yes, abstracting over arity is a problem in all statically typed languages. etc.
There are valid complaints to be made about Scala. I feel this talk demonstrates a lack of understanding of the language, and many of its complaints are in fact misunderstandings.
To me the biggest issue this talk reveals is that if you come from an OO background (which I assume the author does) then learning Scala will require a change of mindset. I don't think it is fair to make this a language complaint though. Scala makes it fairly obvious what you're getting yourself into and, as I said above, if you wanted to keep on writing code the way you have in the past it's not clear why you are using Scala in the first place.
[+] [-] weego|11 years ago|reply
[+] [-] pron|11 years ago|reply
Ah! But that’s the point, because Scala is pulling a bait-and-switch. If it were only a modern statically typed language I wouldn’t complain so much about it (and I really do complain a lot about Scala, I guess). Yes, I find its gaudy indiscrimination aesthetically unpleasing[1], but that’s a matter of personal taste. The problem is that Scala still markets itself as “a better Java”, and people are drawn to it so they wouldn't have to write getters and constructors. And at first, Scala does seem to be that. Only after a while you realize that it’s a whole other beast altogether — not necessarily the one you bought into. If Scala were marketed as “a JVM language Haskellers can learn to live with”, I’d have no issue with it (except the aesthetics, that is :)).
[1]: Yet, with its near-infinite list of features it can't even type immutability, which even Java 8 can through its pluggable type systems.
[+] [-] bozho|11 years ago|reply
As for the misunderstandings - the "bad" parts are ..bad. The ugly parts may not be bad, but are ugly (which is subjective, and I think it's implied it's subjective)
[+] [-] jimbokun|11 years ago|reply
Perhaps "very ugly" refers to method names like "/:". (Example on slide 22. There are many more examples of "very ugly" in that slide, too.)
This reflects on the culture, not the language, but it means in practice you will need to read lots of code with random punctuation used for method and function names. Unless you never use any libraries and never work with other Scala developers who write code like this.
[+] [-] GeoffKnauth|11 years ago|reply
[+] [-] nrinaudo|11 years ago|reply
True, the IDEs are poor, for a certain definition of poor. Had I not used IntelliJ for Java, for example, I'd find IntelliJ for Scala amazing. Knowing how much better it can be spoiled me, but frankly, IntelliJ for Scala is not bad. It just could be better. Also, Emacs has a very robust Scala mode.
True, there's a lot to learn before you can consider yourself fully fluent. You do not need to know everything, however. And once you've started on the path, things tend to flow naturally. For example, implicit conversions are easy to grasp. Once you understand them, implicit parameters and type classes are not much more complicated. Once you know type classes, it opens the door to a lot of functional "design patterns" - functors, applicatives, monads... these are not strictly necessary, but they're fun to learn about. And they teach you algebraic data types, which in Scala means case classes, sealed traits, ... it all sort of flows naturally.
True, it's easy to write absolutely un-maintainable code. While that's true of any language, Scala makes it rather easier than most. It's also very easy to write highly maintainable, legible code, and to avoid complex, ascii art based operators (or at the very least to offer wordy equivalences at 0 cost through `@inline`). I feel that saying "it can be hard to read, if you don't follow basic guidelines" is a bad reason not to use a language. A good reason to be careful, though.
My personal experience is that, once you start feeling comfortable with the language, you get much more productive than with Java. It does require some initial work, though: if all you know is OO, learning how to design your code for composition rather than inheritance takes a while - it takes a while just to realise that it's not a bad idea, let alone embrace it!
Also, ScalaCheck. Man, do I wish there was a good Java equivalent for some of my legacy code (that would not require me to rewrite all of my tests).
[+] [-] thescrewdriver|11 years ago|reply
You can write perfectly readable Scala. It just takes some taste and common sense, or alternatively follow guidelines such as: http://twitter.github.io/effectivescala/
We've found IntellJ + Scala to be an excellent combo for our purposes.
[+] [-] psuter|11 years ago|reply
Regarding IDE support, which inevitably comes up when discussing Scala, an honest question: what are good IDEs for Ruby, Python, Clojure, JavaScript, Haskell, OCaml? Is there a good IDE for C++ besides Windows-only Visual Studio? For C? It seems that Scala always get compared to Java in that domain, but in my experience Java is the exception, not the norm.
(Edit: I assume support for CLR languages is great too?)
[+] [-] dreamweapon|11 years ago|reply
For a certain value of "fun", I guess.
Generally I find in engineering that it's best not to add abstraction (or other forms of complexity) to a system unless there are strong, clear benefits to doing so. The more we learn about Scala, it's just not clear that it delivers those benefits (in proportion to the time investment it demands).
It's not that I don't "dig" abstraction. It's just that I have an infinite list of things to learn about (some fun, some not so fun) in any given development environment. (In general, most of these are in the non-fun category: dealing with dependencies,build tools, and legacy quirks that can never be fixed).
And another infinite list in my own problem domain -- you know, that thing I'm supposed to be, theoretically, directly working on (in the service of which all of these fancy software tools were supposed to be a means, not an end). Plenty of very real and juicy abstractions. More than I can ever hope to get to the bottom of, in fact.
But don't get me wrong. If applicatives and such are your bag, then that's great. Maybe Scala is the right language for you, then.
[+] [-] bilalhusain|11 years ago|reply
[+] [-] virtualwhys|11 years ago|reply
The OP hasn't been using Scala for long so many of his gripes boil down to lack of experience. You have to learn the ropes, the (myriad) corner cases, etc. of the language before things start to click.
It's like starting out in Haskell, where on earth do you even begin to understand this utterly new paradigm, much less go into production with large scala projects in it? The answer is: you don't, you learn, learn, learn until you're well grounded in the language and its frameworks; then you bet the bank on it because you're sold on its clear-as-day powers.
I'll go out on a limb and say that the only viable type safe alternatives to Scala and its ecosystem are C#/F# on .NET, and Haskell. In other words, yes, Scala has its warts, but overall is pretty much unmatched in terms of expressivity, power, and performance.
[+] [-] the_af|11 years ago|reply
Letting SBT do the build may work, but come on. This is the official IDE! Is there any acknowledgement in scala-ide.org that you should let SBT to do the build? Do Odersky and the guys at Typesafe use that setup, or do they suffer their IDE silently?
I haven't had much luck with IntelliJ either.
[+] [-] CmonDev|11 years ago|reply
[+] [-] DanielBMarkham|11 years ago|reply
I lost track somewhere in the first ten minutes or so, but it looked like he was importing/using multiple DSLs and helper libraries. After I lost track of the exact details, I started scanning for the gist of what he was doing.
After an hour, he had what looked like the most massive clusterfuck I've ever seen in a project file -- all to do something that would take a dozen lines or so of simple FP script. Seemed like every functional thing he used was either also an object or had to be bolted into an object graph for it to work. The project file had scores of things in it.
This did not leave a good impression. It reminded me of when I saw my first C/Win32 app and realized you needed a couple hundred lines of code and several files just to say "hello world" -- except this was a couple orders of magnitude more complex. It was a god-awful abomination.
Hopefully Scala projects are not like this.
[+] [-] lmm|11 years ago|reply
[+] [-] yummyfajitas|11 years ago|reply
[+] [-] ssmoot|11 years ago|reply
So the impression I get from your comment is that this was a fairly large and/or complex project he was attempting to demonstrate. Maybe it just wasn't real appropriate.
[+] [-] lmm|11 years ago|reply
Implicits are dangerous, sure. Typeclasses are vital and extension methods are nice, but it might be better to cover these use cases with something more specific. That said, these days the IDEs flag up implicits so it's not really a problem day-to-day.
Concise really helps readability at the function/module level - there's a huge drop in readability when a function reaches the point that you can't fit it on one screen. It may well be that the 1-line scala version of a method takes exactly the same time to read as the 10-line java version - but if it means you can fit your whole class on one screen, that's still a win.
Symbolic method names are bad and I wish the community would move away from them.
The definition of ++ is perfectly sensible once you stop panicking and start actually reading it. As is the parser; sure, it's a DSL, it uses some short symbols, but I defy you to find a better way to express the parser given. When you're building up a complex parser, it's well worth having a concise notation.
jsonFormatX are legacy cruft. In a modern json library you can avoid them by using Shapeless instead; hopefully spray-json will do this too.
The .toSet() example is deprecated and will give a warning if you actually try and run it.
Java-8 style lambda compilation is already available under an experimental flag, and the next release will have full support.
[+] [-] Sandman|11 years ago|reply
Oh yes, this is one of the things that bother me the most about Scala, actually. I don't mind if there are conceptually different ways of achieving the same goal, as you put it, because those different ways usually have different trade-offs; if you're doing things one way instead of the other, you know why you're doing it, there's a certain benefit in doing it this way.
But syntactic diabetes is bad because it ultimately provides no real benefit. Different people will write different code based simply on their tastes and preferences and pretty soon you'll have a mess in your project codebase, unless you enforce strict rules and conventions about writing code. Furthermore, people who work in a team that enforces one set of conventions may have trouble when joining another team that uses a different set of conventions. In Java, for example, this is not the case. Yes, there are things that the language itself doesn't enforce, and conventions are used, but these conventions are well known, and there's probably no Java developer on Earth who wouldn't adhere to them. When a totally new Java developer joins the team, she can usually read code right away, because there are no surprises with regards to the syntax. Sure, she'll need to spend some time perhaps to really get what's going on, because the code might be complex, but the syntax itself won't stand in her way.
[+] [-] bsaul|11 years ago|reply
There should be only one way to express a given language operation, and this way should be the simplest and most elegant. Not just because of aesthetic (which is crucial when speaking about readability), but also because it would combine the most harmoniously with other parts of the language.
It seems to me that at this point scala should deprecate all non-essential syntactic sugar and features and reduce the language to its "core". Or, at the very least, people should start a fork with that goal. Hell, it could even be just a compilation option.
[+] [-] oelang|11 years ago|reply
[+] [-] Yuioup|11 years ago|reply
[+] [-] weego|11 years ago|reply
There are real pain points in Scala when you try and scale it from single developers to teams working on a project and most of them are to do with the flexibility of the language.
I think all companies working with Scala end up settling on a sub-set of the language that they are happy with. In that sense, the bad is irrelevant: you are never put in a situation where, say, you are forced into using implicits (apart from light use in external libraries like lift-json) so if you don't use them you never suffer their downsides. If you obsess over parts of a language you don't even have to use... then well I'm afraid I have nothing but scorn for people like that.
At team-scale then your main pain point is trying to get style of writing that everyone can get behind. Code reviews can be painful when developers with different ideas on how to solve a problem butt heads and pull requests turn into "That's not how I would have written it" instead of critiquing the actual code presented.
The tooling and compiling I completely agree with. SBT is a horrific mess. I don't have a single good word to say about it.
[+] [-] dragonwriter|11 years ago|reply
[+] [-] oelang|11 years ago|reply
With scala you can write test that are concise and readable with ScalaTest or ScalaCheck. The readability largely depends on the quality of the library that you use but also the user.
[+] [-] BozeWolf|11 years ago|reply
I'd like to do functional programming, I'm doing server/web based stuff mostly. I'd like the language to have a big(large) ecosystem. Clojure is fun and all, but it's more or less a hackernews language. There are only a few serious businesses using it. It also lacks a web framework like Play!. Same goes for Haskell. So besides all the bad stuff of scala, having play and quite a large ecosystem is why i wanted to try it.
[+] [-] moomin|11 years ago|reply
And seriously, the web story for Clojure is just fine. It's just componentized, it's not missing.
[+] [-] megalomanu|11 years ago|reply
[+] [-] simi_|11 years ago|reply
[+] [-] somehnreader|11 years ago|reply
[+] [-] wiradikusuma|11 years ago|reply
[+] [-] eranation|11 years ago|reply
I do have issues with it, but mostly with developers using (abusing) it. (And library authors that are a bit religious about the functional paradigm and simply love their operators...
With great power comes great responsibility, the is no better description to this language.
Also, I was looking at the CanBuildFrom hell with fear, but Odersky et al's book on Scala surprisingly did a good job getting the pieces in place for me. It even makes sense of the madness.
http://www.artima.com/shop/programming_in_scala_2ed
Finally, Bozho is one of my most respected contributors on stackoverflow. And I can say that his slides actually do justice to Scala, I might disagree on the conclusions, but the facts are absolutely right.
[+] [-] mcv|11 years ago|reply
Give me the Scala pattern matchers (that can also match by type and even by content of case classes, I believe), with the case classes and the actor concurrency model, but keep the horrendous type system and the confused parts of the syntax.
[+] [-] fideloper|11 years ago|reply
[+] [-] jowiar|11 years ago|reply
[+] [-] ssmoot|11 years ago|reply
"The Neophyte's Guide to Scala" (http://danielwestheide.com/scala/neophytes.html) is hands down the best language introduction I've ever read though.
[+] [-] noelwelsh|11 years ago|reply
[+] [-] huehue|11 years ago|reply
[+] [-] taf2|11 years ago|reply
[+] [-] thescrewdriver|11 years ago|reply
[+] [-] xwowsersx|11 years ago|reply
This is a longer discussion, but in the very first slide he points to the object-orientation as a plus. In my opinion, he's already wrong. "There is no such thing as Object-Oriented programming." See: http://blog.higher-order.com/blog/2008/12/04/no-such-thing/