Scala – The good, the bad and the very ugly

http://www.slideshare.net/Bozho/scala-the-good-the-bad-and-the-very-ugly

by bilalhusain • 12 years ago

137 174 12 years ago

BozeWolf2• 12 years ago

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.

moomin4• 12 years ago

When the businesses are Twitter, The Guardian, The Daily Mail and Netflix, I wouldn't really worry about it.

And seriously, the web story for Clojure is just fine. It's just componentized, it's not missing.

bilalhusain5• 12 years ago

Your way of educating people about Clojure isn't particularly helpful. Don't make sure that people miss out a really good language, instead take this opportunity to share [personal experiences or impressive writeups about] how awesome web frameworks are on this side of the grass.

turar• 12 years ago

> Twitter, The Guardian, The Daily Mail and Netflix

Are you talking about Scala or Clojure? I've only seen those names mentioned with their Scala use, what are some of their Clojure projects?

simi_• 12 years ago

I don't want to be that guy, but why don't you try Go? It's the perfect server side language IMHO.

lmm17• 12 years ago

With a type system that's weaker than Java's? Look at e.g. the way spray handles HTTP headers; it eliminates a bunch of errors that are in some sense trivial, but almost all bugs are trivial when looked at in the right way. You just couldn't do something like that in Go.

rkrzr2• 12 years ago

Well, if you want to do functional programming, as the OP indicated, then Go is not the way to go. Scala seems like a fine choice then, or e.g. Haskell if you want to go all the way.

megalomanu• 12 years ago

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.

BozeWolf2• 12 years ago

I actually might give Luminus a go if I give up on scala sometime. Thanks. I did have some fun with clojure, it's much easier to get started with.

I know i'm kind of spoiled with features because I do a lot of projects which involve django. I do not expect a framework to be as rich as Django. But i prefer having some things integrated. Some might prefer choosing every component in a framework (ORM, url routing system, form validation etc), but when you work in a team or with freelancers, it comes in handy if theres just a way of doing things.

nickik7• 12 years ago

Pedestal client has been retired. Pedestal server is a high performance server framework that most people probebly want have to use. Pedestal gives you much more power offer use of threads and how you do controll flows between middlewares and such.

somehnreader2• 12 years ago

Whats Syntax diabetes referring to by the way? I didn't get it from the presentation, and googling yields, well, diabetes information.

moomin4• 12 years ago

It's a phrase for too much syntactic sugar.

rkrzr2• 12 years ago

It's a play on the term "syntactic sugar": Too much syntactic sugar leads to syntactic diabetes. And syntactic sugar generally refers to language features that allow you to write things in neater ways. It is always possible to "de-sugar" such constructs by writing them in a more basic way, which is usually less neat. Examples would be e.g. list comprehensions, for .. in syntax, x += 1 etc.

gamache2• 12 years ago

It refers to the fact that there are many syntactically-equivalent ways to express the same code. Slide 11 shows expressions that evaluate to the same thing.

Yuioup• 12 years ago

Excellent quote:

  "Concise" doesn't necessarily mean fast to write or easy to read

weego3• 12 years ago

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.

mercurial5• 12 years ago

Maybe, but it's just a generic statement about programming, it has no real value in a critique of Scala specifically.

About Scala specifically? No, indeed. About languages which make it possible to create custom ASCII operators? Certainly. I don't know how the Scala culture about this is, but my experience with Haskell is that once people run with it, you get awful ASCII DSLs with cryptic operators all over the place.

I think all companies working with Scala end up settling on a sub-set of the language that they are happy with.

So, pretty much like C++, a language that people love to hate. The problem is that, out in the wild, you're going to end up with legacy code made by people who picked a different sub-set.

oelang5• 12 years ago

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.

dragonwriter2• 12 years ago

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.)

nrinaudo2• 12 years ago

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).

bilalhusain5• 12 years 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.

oelang5• 12 years ago

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.

pjmlp4• 12 years ago

Programming 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.

thescrewdriver3• 12 years ago

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.

Aqueous• 12 years ago

I've been using Sublime as my Scala "IDE" for a while now - what it loses in certain 'critical' IDE features like code completion and variable extraction it gains in speed, ease of use and lack of bloat.

I agree that as far as real IDEs go, IntelliJ is the best - but that's not saying much. The rest are pretty awful. They all do many things poorly, whereas Sublime does a few things very well.

dreamweapon• 12 years ago

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.

pea• 12 years ago

I agree with you in terms of abstraction; I do believe Scala adds a lot to practical programming as well. I feel the community is tainted by a bunch of type-nerds trying to compile their Haskell, and don't care about writing simple, maintainable code.

We use Scala because it is speedier to push features. I work much quicker in it, and we don't have to worry about a lot of the stuff we would in Java. That said, we don't use a bunch of the most complex features of the language (I am just talking simple pattern matching, map/flatmap/filter/unzip). So far, it's actually the most productive language we've used.

Our dig is the community and things peripheral from the core language: documentation is generally awful (Play, SBT). Dependencies management is awful (SBT doesn't work). Libraries are overly complex (Dispatch). And compile times suck.

eropple• 12 years ago

I'm a pretty big Scala fan, but I think this post is spot on. A lot of the stuff that's fun is not terribly useful, and I see a lot of people in the Scala community going down that road. The most perfect codebase in the world doesn't mean much if it doesn't do anything.

This is why, despite feeling real weird about it, I'm writing my current personal project in Rails rather than Play. It's one case where worse-is-better kind of benefits me--it forces me to focus on my problem, rather than on all the cool bright-shiny-objects that are not my problem.

(There's also a discussion to be had about the Scala-should-be-Haskell crowd, who I think come from a good place but are led by some of the most overtly poisonous people I've ever had to deal with.)

nrinaudo2• 12 years ago

As I said, they're not necessary and I don't think I've written useful code that explicitely used monads, for example - well, aside from for-comprehensions, but you could argue that it's not explicit.

But they are fun in that, once you start understanding what the fuss is all about, they open your brain to new ways of thinking, which is always good - instead of learning how to be really really good with a hammer, I like to know about screwdrivers as well, for the odd case where that nail is kind of screwy.

I do understand your point about an infinite amount of things to learn in a finite amount of time. What I personally do is focus my study of tedium (build tools, say) and domain-specific concepts for work-hours. These things are required for me to be good at my job, and it seems fair that I improve on them while doing that job.

The other, more theoretical (type theory, functional abstractions, fun data structures...) or less directly applicable (odd languages, new concepts such as reactive programming or actors...) subjects I study on my own time, when I have it, when and if I feel like it.

It means that, for example, it took me a solid year before I felt I had some degree of fluency in Scala, which was frustrating. On the plus side, I now have some degree of fluency in Scala.

psuter• 12 years ago

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?)

bad_user• 12 years ago

If you compare IDE support with those languages, then Scala's IDEs are stellar. I would dare say that IntelliJ IDEA for Scala is better than Visual Studio.

akavel• 12 years ago

As to C++, Eclipse is good. (Not perfect, not certain if great, but it is good.)

lemming• 12 years ago

what are good IDEs for...

  Ruby: RedMine/IntelliJ
  Python: PyCharm/IntelliJ
  Clojure: Cursive/IntelliJ 
  JavaScript: IntelliJ + all JetBrains IDEs 
  Haskell: Dunno 
  OCaml: Dunno 
  Is there a good IDE for C++ besides Windows-only Visual Studio?: CIDR undoubtedly will be, but it's still in beta right now.
  For C: AppCode

Seriously, JetBrains just make fantastic IDEs.

noelwelsh7• 12 years ago

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.

bozho• 12 years ago

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)

noelwelsh7• 12 years ago

Perhaps the issue is that the slides don't really stand on their own. Without hearing what you have to say for many of the slides it is difficult to really get the point you're making. Let me just address the "bad" slides, and what I got from them.

Slide 8

- Compiler too slow. A common complaint. Agreed it could be faster.

- Ecosystem. Don't really get the point here. Yes, Scala has different idioms to Java, so naturally Java libraries don't make for idiomatic Scala code. There are many mature Scala libraries. Binary incompatibility has not been a problem for me in at least two years, and it is a necessary artifact of Scala compiling a language that is not Java to JVM bytecode.

- Lambdas I addressed above.

Slide 9

Don't know what point you're making here.

Slide 10

Mostly addressed above. Syntax doesn't bother me. There are regular rules and the alternatives are a consequence of those regular rules. Would consider removing eta-expansion. Never had an issue with any of the rules though.

Slide 11

See above.

Slide 12

See above on type classes.

Slide 13

This is very generic. Applies to all languages.

Slide 14-15

Don't really get it. You can write code in many different ways. Applies to all languages.

Slide 16

This is very generic. Applies to all languages.

Slide 17

Don't get the point you're trying to make with this code.

Slide 18

This is presumably a slide that summarises this section. Without hearing what you have to say here I can't really interpret this.

weego3• 12 years ago

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.

pron6• 12 years ago

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.

noelwelsh7• 12 years ago

Indeed, if Scala wasn't closely compatible with Java (in terms of both syntax and interop) it would not have so much traction. That's the deal with the devil that Scala made, and one reason it has an excess of cruft. For example, no language needs both traits and abstract classes, unless that language wants to interoperate easily with Java.

I am broadly agreed with you. Scala could do with trimming, and I'm optimistic that both Typelevel and Typesafe will accomplish this in the near future.

jimbokun• 12 years ago

"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.

buddhu• 12 years ago

"... in practice you will need to read lots of code with random punctuation used for method and function names."

In my two or so years of Scala I've yet to see anyone actually use /: or similarly named methods, and if they did I would make sure it never gets past a code review. Yes, the methods are still there, but in my experience people avoid them (even Odersky thinks they were a bad idea), and libraries with a lot of symbolic methods (Scalaz, and everyone's favorite whipping boy, Dispatch) are not particularly mainstream.

So my experience at least has been the opposite of what you assert. I would instead say that "... in practice you will NOT need to read lots of code with random punctuation used for method and function names."

GeoffKnauth• 12 years ago

Amen, brother.

DanielBMarkham2• 12 years ago

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.

Hopefully Scala projects are not like this.

lmm17• 12 years ago

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.

DanielBMarkham2• 12 years ago

Whew!

I'm okay with using DSLs. Hey, if you have good FP, flaunt it. My concern after watching this, however, was whether or not the JVM development environment itself encourages complicating things beyond the most minimum thing needed to solve a problem when you're using it in a functional manner. (I haven't done Java in a decade). So, for instance, could I have just written a simple 12-line script to solve the problem he was banging around? Or would I have to create some kind of object with a "main" method? Could I just add in a test file and write functional tests from there, aka JUnit, or do I have to bolt something in that then requires a separate project structure and so forth (aka JUnit)

There's no right or wrong answer for any of these types of project configurations. Heck, I like my tests in a separate project. It just looked like every time he had a new need, the project got 14 times more complex. The solution to one problem made the entire development environment more complicated for everything else. That's heading in the wrong direction, no?

Admittedly I only had a brief glance. Thanks for the answer!

ssmoot2• 12 years ago

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.

yummyfajitas2• 12 years ago

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.

lmm17• 12 years ago

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.

oelang5• 12 years ago

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.

bsaul• 12 years ago

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.

lmm17• 12 years ago

I don't see how it's a loss of orthogonality; just like a whitespace-insensitive language, it's saying that the choices of bracket and dot are syntactically equivalent. And that syntactic freedom means the precedence of a Scala line is often much clearer than the equivalent in other languages:

    a b {c d (e f g.h(i))}

In Haskell you'd have to write that as something like:

    a b (c d (e f (g h i)))
    //or alternatively
    a b $ c d $ e f $ g h $ i

rbehrends• 12 years ago

There should be only one way to express a given language operation

This is not possible in general, because concepts rarely coincide cleanly with syntax. For example, you can't have both currying and closures if you insist on this.

Most of the "syntactic diabetes" examples in the talk are of this kind: They are actually separate, general concepts that happen to overlap. And some don't even overlap, but the author does not seem to fully understand the language.

For example, that you can write both f(x) and f{x} is simply because f{x} is essentially the same as f({x}) and the parser allows you to drop the parentheses if they directly surround braces. But `{x}` and `x` are not the same: the first is a scoped block, the latter is a variable. You cannot use a variable to express a scoped block and you cannot use a scoped block to express a variable.

There IS unnecessary conceptual overlap in Scala, but you can find that elsewhere: For example, there's quite a bit of conceptual overlap between view bounds and type classes. But it's difficult to blame the language for it: much of this conceptual overlap exists to make the Java interoperability story less painful (of course, you could argue that Scala shouldn't try so hard to be interoperable with Java at the cost of language simplicity, but there are tradeoffs either way).

Sandman2• 12 years ago

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.

lmm17• 12 years ago

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.

But the brackets, braces and dots are just such a trivial part of the syntax. Is anyone really getting confused about the difference between

    opt.foreach{s => println(s)}
    opt.foreach(s => println(s))
    opt.foreach(println)
    opt foreach println

? I really can't imagine a developer who's learnt one having trouble reading the other.

virtualwhys2• 12 years ago

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.

the_af3• 12 years ago

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?

I haven't had much luck with IntelliJ either.

virtualwhys2• 12 years ago

Couple things to keep in mind: Java IDEs have had millions of man hours put into them; there's a reason they're rock solid reliable; that and Scala's power is a double edged sword: tooling becomes a more difficult proposition with greater language complexity.

As Scala users we're basically guinea pigs in the IDE department. Having suffered from the relative stone ages of 2010 era Scala tooling I can honestly say that if you're considering picking up the language, you've come at a great time ;-)

re: sbt running the show, not sure about IntelliJ but the core Scala IDE devs will drop that bit of knowledge when a user moans on the mailing lists about blocked UI, spurious syntax errors, and other bundles of joy.

Roboprog2• 12 years ago

I would never let any IDE run my build.

Builds are always scripted with explicit settings, which anyone can run, with the same results, regardless of what editor and preference settings they use. (so long as needed compilers are installed on server/workstation)

CmonDev2• 12 years ago

Yes, when thinking about a modern managed multi-paradigm, multi-typed, multi-platform language the choice is pretty much limited to Scala, C# and F#.

mercurial5• 12 years ago

OCaml?

nickik7• 12 years ago

Whats multi typed? Does this mean static? If not why is clojure, python or others not on your list?

fideloper• 12 years ago

Is there a book everyone recommends for learning Scala? In the beginner range, not someone coming from Java.

huehue• 12 years ago

`Scala for the Impatient` is really good.

thescrewdriver3• 12 years ago

Scala for the Impatient is really good, but not sure that it's designed entirely for beginners.

For more beginner-centric content perhaps check out:

Learning Scala:

http://shop.oreilly.com/product/0636920030287.do

http://chimera.labs.oreilly.com/books/1234000001798/index.ht...

...or Atomic Scala:

http://www.atomicscala.com/

noelwelsh7• 12 years ago

I'm writing one. It's almost ready. Drop me an email (noel at underscoreconsulting dot com) if you'd like to try it out.

ssmoot2• 12 years ago

I second "Scala for the Impatient", but if you don't have any statically typed background it might be a bit tough.

"The Neophyte's Guide to Scala" (http://danielwestheide.com/scala/neophytes.html) is hands down the best language introduction I've ever read though.

jowiar• 12 years ago

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".

mcv2• 12 years ago

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.

frowaway00111• 12 years ago

horrendous type system and the confused parts of the syntax

Could you expand on that a bit?

In my experience, Scala is one of the few languages which don't fight against everything you want to express in a typesafe way.

Also, I find the syntax extremely consistent. Easy to remember and almost no special rules.

mcv2• 12 years ago

The article shows some examples where you can choose between regular brackets or curly brackets. There's a lot of different ways to say the exact same thing. Why? Which is best? Are there any cases where one works but the other doesn't, and if so, why does the other exist? But maybe I'm too used to different brackets meaning different things. I'm used to Java and Groovy where brackets are used very consistently.

The type safety goes way overboard with extremely arcane, incomprehensible expressions. The excessive power of the type system makes compiling far too slow. And the pattern matchers mean you can easily get your type back when you need it. I really strongly prefer the more dynamic approach of Groovy. Total type safety is a trap.

wiradikusuma• 12 years ago

I submitted a YouTube video 165 days ago where Martin Odersky explains how to avoid coding the complicated way. https://news.ycombinator.com/item?id=7641626

xwowsersx• 12 years ago

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/

taf2• 12 years ago

golang

thescrewdriver3• 12 years ago

Perhaps you could elaborate on how naming a random language relates to this discussion...

throwaway1979• 12 years ago

Heh ... it is the other mainstream "hot" language.

I was looking for a language to move to post-python. I love python but the 2.7->3 jump has been annoying. More than that, I felt I needed static typing for the next big system I did ... too much pain debugging python.

I looked at Scala since it had the JVM behind it. While the language seems decent, it seems too easy to write unreadable code. Multiple ways of doing the same thing ... yada yada.

Friends at Google had been espousing Go for a long time and I didn't bother. Seemed like a proprietary language with little adoption. Two things changed for me. I got some exposure to erlang via elixir. This made me think about the whole channel concept. Second, I had to read code in Docker (which is awesome). I learned a bit of the language and was surprised how small the language was. Really reminded me of C, which I love. There seems to be more adoption of Go .. e.g. Cloud Foundry and others. I like Go enough that I will be spending more time learning and investing in it.

Just by 2 cents.

eranation• 12 years ago

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.

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.

Scala – The good, the bad and the very ugly

Related Stories