20 ms·

Using Scala Will Make You Less Productive

87 points by bartonfink 13y ago

auggierose 13y ago
I've seen that post previously here. It did not become better.
penland 13y ago
Man that's a bad post about Scala. Scala has a lot to love and a bunch to hate within the language itself, but writer doesn't appear to have the ability to actually discuss it.
- pekk 13y ago
  Why?
- stewbrew 13y ago
  I found it quite interesting how the Scala community reacted to such rants in the past -- mature & civilized, actually discussing pros & cons.
- mcherm 13y ago
  I completely disagree. The blog entry contains enough details to make me think that Graham actually understands Scala. And he raises valid complaints: * Compile-time is slow * IDE support is more poor than Java * Overuse of operator overloading is confusing * Implicit confusing I don't necessarily agree with all of these criticisms, but it's a very valid piece of "feedback" to the Scala community.
  - saryant 13y ago
    Fortunately it's feedback that the community has taken to heart. 2.11 should improve compile times, as will new incremental compilation features in SBT 0.13. IntelliJ's Scala support has gotten much better recently and the official Scala plugin for Eclipse has also made major strides. (Though I still use vim) Odersky has taken an official stance against symbolic method names, especially in libraries, and many of the most famous offenders (Dispatch's absurd periodic table) are rightly ridiculed within the Scala community. I don't have anything to add on implicits. They've certainly tripped me up a few times but generally it's just a matter of finding the right import, though I have been cursing Play's implicit JsValueWrapper the last few days.
    - adriaanm 13y ago
      Thanks. I should add that dispatch has long abandoned their periodic table (before they got called on it last Scala Days, actually).
      - saryant 13y ago
        That's good to know. I haven't used Dispatch since 2011 when I first started using Scala (that was a rough introduction). I'm looking forward to Play moving their WS package out of the core though—right now we've basically written a few wrappers around AHC in their style for the pure Akka parts of our stack but we'd love to standardize.
    - deleted 13y ago
      [deleted]
  - hashtree 13y ago
    Agreed, his terse ~5000 word post to describe what you did in ~120 characters was well thought out.
  - hp 13y ago
    Scala doesn't have operator overloading btw. It just doesn't restrict method names very much. This is very different from how C++ treats operators as special cases. If you give your methods bad names, it really is not the language's fault. You can probably find a way to make a bad API even if you are limited to a-zA-Z0-9 ... If a library has an inscrutable set of method names blame the lib not the language.
    - hapless 13y ago
      Operators are treated specially in scala. Methods with certain names have wildly different precedence rules. The special operator rules allow library authors to create a "DSL" without using the (difficult) macro system. This almost never ends well.
    - mcherm 13y ago
      I know that, and I use the term only because the author did. I agree that it's the fault of library designers not on the core language, but it is still a legitimate issue to raise.
- Rotten194 13y ago
  Feel like actually discussing the article instead of attacking the author?
camus2 13y ago
Well the problem with Scala is at first it looks like a concise java but it's not. Truth is it's closer to Lisp with a C syntax. If you dont understand some idioms like lazy evaluation, everything is a method or pattern matching you probably should use it. I think scala rocks. The only downside is the slow compiler. But SBT , worksheets , stuff like that are just awesome to toy with stuffs in an interactive manner.
- akbar501 13y ago
  I totally agree on the slow compile times. It's simply painful.
- penland 13y ago
  Scala is much closer in spirit to ML / OCaml / Haskell than a LISP dialect, but I do agree w/ you that Scala rocks. It's my favorite language I've picked up since O-Caml.
- chimeracoder 13y ago
  > Truth is it's closer to Lisp with a C syntax. The only similarity that Lisp and Scala have are that they are both functional programming languages[0]. Scala is a heteroiconic language. At least until recently, Scala didn't even have macros (I think they may have added that recently). Scala is a nice language, but saying that Scala is somehow like Lisp is doing a disservice to both languages. [0] Even the statement that Scala is functional is itself debatable - one can make the argument that it is "just" more purely object-oriented than Java, but that's a whole separate discussion.
  - adrianm 13y ago
    Why do people think Lisp is a functional programming language? If anything, traditional Lisp is the antithesis of a functional programming language. What Lisps are you referring to? Maybe we're just defining our terms differently, but the closest Lisp comes to a functional programming language is Clojure and before that Scheme. This is not meant to deride Lisp in any way (Clojure is my language of choice, after all) - I think all Lisps enable a fundamentally unique way to reason about programs, but that's a characteristic of Lisp and not of functional programming languages.
hhm 13y ago
My main impression after using Scala a little bit (admittedly some time ago): it has some very cool functional features, but they are too slow when compared with the non-functional features. When working on a program for which performance matters, this means that you end up working on a Java-like subset of the language in most of the program.
- kasey_junk 13y ago
  Well I would argue that when you are working on something where performance matters on the JVM you end up working on a very C-like subset of your language. Java makes the translation to that subset easier than Scala, but you can certainly do the same translation from Scala.
mcv 13y ago
Scala has a couple of features that make it by far the best programming language ever conceived by mankind. But it has a couple of other features that utterly ruin it with total unrecoverable brain damage. I would really, really appreciate a Scala without all the crazy, but with all the brilliance. Or, you know, just a community that doesn't go out of its way to overuse all of that crazy. Just drop the incomprehensible type declarations and the incomprehensible operators. Maybe add dynamic typing, even. Then you'd have a really nice language.
- pathikrit 13y ago
  Scala [has][1] dynamic types. [1]: https://github.com/pathikrit/dijon https://github.com/pathikrit/dijon
- hapless 13y ago
  I keep hoping that the operator abuse is just a growing pain. The language community has been given a new toy, and they're going to chew on it. Eventually libraries that will come along that were intended to be used by humans. Sbt will disappear. Flowers will bloom, and the lion will lay with the lamb.
- anonymoushn 13y ago
  Moving to a simpler type system is not the only option. If you want to avoid the incomprehensible type declarations while increasing the strength of the guarantees the language makes at compile time, you might consider OCaml.
  - bad_user 13y ago
    Personally I find Scala to be more elegant than OCaml. In OCaml OOP is a strange add-on, whereas in Scala it's an elegant mix.
Aqueous 13y ago
I really disagree with this article. Type safety combined with Play's refresh-recompile trigger means it is not meaningfully less productive than PHP, and maybe moreso because compiling is usually an indication of your program's correctness, so you don't waste time tweaking-reloading-tweaking-reloading. Compiling is slow, yes, but it saves you more time than it costs you because static typing means a whole class of bugs just never happen for you. I know that the IDE support is lacking but this doesn't really bother me since I don't use an IDE with Play apps. I always use a text editor, since I find that IDEs tend to do a bunch of things badly, whereas a text editor and a terminal each do a single thing very well. There's nothing you said about the features of an IDE that I couldn't do just as well with a well-defined find-replace (besides variable extraction - not familiar with variable extraction.) You can be productive in any language - Java, Scala. But I find that Scala's conciseness - the fact that I can do an operation on a whole collection of case classes using pattern matching and the collection API functions that would take 30 lines using classic Java - ends up making me more productive than I have been in those other languages. Maybe it's just me.
- mason55 13y ago
  > Not even sure why people need an IDE. For someone learning Play & scala in general I find the IDE to be immensely helpful in showing my type information and valid auto-completes. Rather than constantly digging through documentation I can see that, for example, some flatMap will give me a list of (Id, User) tuples, so then I can call map( case(id, user) => user) ) (or just map(_._2)) and pull out the user objects to get my list of users from my list of tuples. This lets me focus on the business logic and not spend all my brain power tracking types. I don't think I would have survived my first foray into building complicated composite ResultSet parsers in anorm without the IDE. I'm sure that as I gain more experience and all the functions become second nature I'll be able to track it in a text editor but for now I love my IDE.
  - Aqueous 13y ago
    Yes, I edited that statement out - I'm sure people have good reasons for using IDEs, immediate type evaluation being one of them.
ryanobjc 13y ago
Interesting post, a little random, ultimately it's really hard to 'prove' something like this in a single article. Studies maybe, but there'll always be someone saying something contrary. I can only really offer my experience, which is architecting and building out a 25kloc app and team to go along with. Mostly, because we avoided the 'clever' scala stuff as much as possible, things went well. Maven instead of sbt. Jetty instead of play. The only scala DSL we used was squeryl. If I was doing it again, I'd probably rethink the use of scala. As helpful as it was, it was also a pain in places. Having to rewrite all our for loops was not cool. Case classes saves on boilerplate, but frankly you only write that stuff once, so it didnt really save us on a lot. Intellij elides most of the junky boilerplate (import statements, generating setters/getters, etc) in Java, so ... Now a days with the advent of Java8, we have access to lambdas, function pointers/interfaces, and the functional stream system, I am interested to see how far one can get in just pure java. Java is the new scala it seems.
- kasey_junk 13y ago
  Honest question that I haven't taken the time to figure out. Do I still have to have only 1 file per class/interface in Java 8?
  - ryanobjc 13y ago
    you've never had to only have 1 class per file. You can only have 1 public class per file however. You can also nest classes in other classes for quick little data types you need locally. So the notion that every single last tiny class has it's own file hasn't ever been true (even if thats the coding style in a lot of code).
    - kasey_junk 13y ago
      But if I have an interface and a couple of implementations I'm back to multiple files right?
      - mason55 13y ago
playing_colours 13y ago
A very important point for me in Scala is that now I can consider building the company stack with it. The libraries and infrastructure are really getting better. We have Play for web applications, Spray, Scalatra and more for APIs, actors / futures / STM / Akka for concurrency, and you can easily intergrate Akka with Play and Spray, use the same patterns at different parts of your infrastructure. We have Scala.js for frontend work. Growing numbers of frameworks for Big Data. Those are maturing and being developed for industry needs, tested in production at some known companies. Don't forget it's based on solid JVM with huge amount of Java libs available. I have confidence to advise building real businesses with Scala stack and not looking like an irresponsible guy who just wants to play with the latest and shiniest stuff hazarding a company's business. I also see how Typesafe is focusing on solving bad parts: compiling time, stability, etc. You can also stay away from advanced / theoretical / crazy parts of Scala most of time. You don't need to use Scalaz, advanced type system features etc. There are also immature libraries, toys and proof-on-concepts, but you cannot blame Scala for your choice.
- mason55 13y ago
  I'm curious about the fact that you're using both Play & Spray. Are you using them in the same app? It seems like there's a lot of overlap between the two and that by switching to Spray as your backend you'd just be generating static HTML with Play.
  - playing_colours 13y ago
    Spray (or Unfiltered at my previous project) is used for a different part of the project. It's basically used on parts where you can expect high load, lots of requests / responses and tight integration with Akka system for processing large amounts of data. Play framework was used to provide UI for our data team or end users to see statistics, do some operations and it's not bombarded by large amound of requests.
    - mason55 13y ago
      Makes sense. I'm building out on Play right now but given that my long-term goal is to have a JS view + REST endpoints I'm still not decided on whether I want to stay on the Play UI/template model or switch to something like Backbone.js + Spray.
sramsay 13y ago
The OP jokingly names a law after himself at the end, but I move that we do name something after him. I'm going to call it Ahmdal's Condition. It goes like this: In this lengthy [post|comment], I’ll share my thoughts and opinions on [THING IN COMPUTING, TiG hereafter] . . . Using a cavalcade of flawed data; logical fallacies; biased opinion; startling lack of citations; and basic nonsense, I will convince you that using [TiG] will make you less productive. I will finish with an underwhelming and unexciting conclusion. You have been warned. Think of it! "I'm offering my thoughts here under Ahmdal's Condition, of course . . ." "Well, I think you're starting from Ahmdal's Condition . . ." "That works under Ahmdal's Condition, but assuming stricter conditions . . ." Honestly, it's genius. If I had a magic meme wand, this guy would be famous by the end of the day.
- NoodleIncident 13y ago
  Surely it would be Graham's condition?
- jamesaguilar 13y ago
  Is it necessary to provide randomly controlled trial/other scientific data to talk about things you don't like in a programming language? Do you have the same standard for talking about things you do like in a programming language? My only problem with the article is that the hyperbole/sarcasm (e.g. "I've given irrefutable scientific evidence...") is not so well done.
  - loup-vaillant 13y ago
    Rational evidence doesn't have to be scientific. But. Even first hand anecdotal evidence has its limits. It really needs to be blatant to be significant. Second hand anecdotal evidence is even worse. If the phenomenon you want to catch is subtle, you generally a good deal of reliable data. That generally means something "scientific".
    - jamesaguilar 13y ago
      My point is that people demanding scientific data for criticisms had better do the same when their favorite language gets praised. Of course, personal evidence is less strong than scientific evidence. That much should be obvious to anyone.
istvandobai 13y ago
> I’ve been developing software professionally for a whopping 3 years. So much experience! Scala isn't for the beginners. > I’ve given irrefutable scientific evidence on why Scala will make you less productive. Yeah, science! Those are just your opinions not scientific evidences. You're just don't know how to program in other languages(only in simple languages as java, javascript and python).
- sehr 13y ago
  I'm sure you have grounds for disagreement with the author, but please do so in a more civilized manner. http://paulgraham.com/disagree.html http://paulgraham.com/disagree.html
- primelens 13y ago
  While you might not agree with his account of Scala, saying that folks who only know "simple languages" like "Java, JavaScript and Python" are unqualified to comment on Scala is just bizarre. Pray tell what you consider to be a language that would make a programmer worthy of Scala.
  - istvandobai 13y ago
    Oh, sorry it seems like i had to say "basic" not simple. It's funny that some people can't understand a simple sentence.
sandGorgon 13y ago
Has someone learned Scala and Go simultaneously ? This may seem a strange question - but I underwent this when I solved the Stripe CTF gitcoin challenge. I think that particular challenge was the most interesting because it branched into the leaderboard challenge. I wrote the same code in Ruby-Celluloid, Python-subprocess, Scala-Akka and Go. When I did this, I came to an strange realization - I absolutely did not have fun writing Scala/Akka code as much as I did writing Go (minus the unused variable fascism). Again, I'm not at all arguing the ecosystem of the JVM vs Go, but I just had a much better time grokking Go code than Scala/Akka - especially the package manager (pulling deps directly from github, etc.) I even sent in a patch for a go package ("gocmd" on github) barely a couple of hours after I first touched go for the first time in my life. I dont have production worthy experience in either, so I dont have a strong opinion... but I really ended up wondering if Go makes Scala obsolete.
- namelezz 13y ago
  I was learning Scala and Go simultaneously. Hey, you forget to mention compiling time. Go is so fast that I just want to cry when I compile my Scala code.
- nutate 13y ago
  Trying to drink the scala kool aid here at work, but I had a similar situation with Go and a freelance job. Went from 0 real experience to working code in very little time w/ go. With scala I feel like I've spent more time waiting for it to compile than actually coding. Especially since we have been doing so much in Python, the switch back to compiled Java (with saccharine scala flavor) is like jumping back a decade in terms of productivity. Also, as you mentioned, the Go syntax is much easier to read, superficially just K&R C style with the types on the opposite side of the variable names.
- anentropic 13y ago
  Oh good it's not just me... found it very annoying that the Go compiler complains of unused variables!
  - sandGorgon 13y ago
ninjakeyboard 13y ago
"I call bullshit. I rarely generate code. I rarely write getters and setters." You must be writing some crazy java.
- RyanZAG 13y ago
  Not at all. Getters and setters are a nasty code smell that generally arises when the author does not really understand OOP. You delegate to objects (tell, don't ask). Delegate to objects generally means person.goToWork() and not person.setIsAtWork(true). If your code is full of getters/setters you can probably refactor it to be far clearer. A more non-conventional Java (but very far from crazy) is to use property accessors (person.name) instead of methods (person.getName()) for "data objects" (structs, really). Some people are very much against it as they believe it stops you being able to modify your object later, but I'd say modifying the access behavior of a struct (eg, O(1) to O(n) access) is even worse than forcing users to update their use of the object. Anyway it's a far deeper topic than just "crazy java".
  - ninjakeyboard 13y ago
    Thanks - that's a great reply. There are lots of horrible code smells common in java like 'Impl' for names. Interesting rebuttle - nice one.
  - unclebucknasty 13y ago
    >A more non-conventional Java (but very far from crazy) is to use property accessors (person.name) instead of methods (person.getName()) for "data objects" (structs, really). Yeah, it's a bit of a fallacy that requiring getters and setters (especially as simple pass-thrus) for simple properties is required for "good" OO (particularly that it maintains encapsulation). The bottom line is that providing both getters and setters makes the property mutable just as it would be via direct property access. Except now there's a performance penalty, as you mentioned. And renaming a property typically means renaming the getters and setters anyway lest the property name no longer makes sense internally. Any good IDE will allow you to accommodate either refactoring (property name or accessor method names) with ease. Initially, setters were also intended to allow the object to fire an event in the case that it's Observable or otherwise participating in a listener-style event system, such as that prescribed by the JavaBeans spec. But, in practice, that pattern is followed so rarely that it hardly merits forcing all of that baggage on every value object ever written.
bad_user 13y ago
> If functional programming is what you want, you can do it in your language. This is a fallacy that gets repeated over and over, ad-nauseam. No, you can't do functional programming in any language. In Java it's more than just lack of syntactic sugar. Java's type system actively fights against functional programming. This is a bit like saying that you can do OOP in any language. Yes, you can have GObject in C. Yes, for Java there have been attempts like www.functionaljava.org ; but it sucks so badly that almost nobody does it, unless they are forced to do it. In fact I challenge the author of this article to show me a piece of FP code that he wrote in Java by himself. > What about all the wonderful things in the standard library? Yep, filter and map and fold operations on collections out of the box is nice. That the SDK uses Option instead of null is an improvement. These things are nice, but I generally get what I’m looking for by adding some libraries to core Java. I do know Java's ecosystem and he must be speaking about Guava, as there's no other stable library for Java that has persistent data-structures. And Guava kind of sucks, so if you're looking for persistent data-structures, might as well implement them yourself, it's fun and it might open your eyes to what functional programming is ;-) Speaking of Guava's Option, lets talk about how Guava's Option is not a Monad, or for those that don't know what that is, basically a context that implements map and flatMap with certain properties. Scala's Option also implements filter and fold, etc... which in regards to the purpose of a Monad, in the words of Erik Meijer, is to guide you through the happy path. Now that's a little closer to functional programming and speaking of Erik Meijer, people might be interested in what he thinks about Scala: https://twitter.com/headinthebox/status/438355100310831104 https://twitter.com/headinthebox/status/438355100310831104 On the bad things he lists: > Compile Time Scala's type-system is much more static, leaving much less room for accidental bugs. Scala's compiler does things that in other languages you'd need to run specialized tools to get the same results or to write more tests. A single sentence or paragraph can't do it justice, but the big compile times are perfectly justified and this is coming from a developer that prior to Scala preferred dynamic languages with instant edit/reload cycles. Besides, these times have been dropping as the core Scala devs have been making improvements, with another batch of optimizations coming in Scala 2.11. And incremental compilation in general works great. And I'm a developer, I have a good dev machine - if you don't have an SSD and at least 8 GB of RAM, then you've got no excuse. > The IDEs I've been using IntelliJ IDEA since a year ago and for people reading the rant exposed by the article - IntelliJ IDEA 13 for Scala is everything you'd expect an IDE to be and more. I never had problems with renaming things. I never had problems with finding all usages of a type. IntelliJ IDEA 13 works flawlessly for viewing the inheritance hierarchy and I'm doing the Cake Pattern which is freakishly heavy on the traits ;-) Other languages only dream about such awesome IDE support. > Overuse of Operator Overloading He complains about SBT, but I thought we were talking about the language and the standard library. Pity that he doesn't exemplify an instance in which "+" is overused. > Implicit He mentions implicit parameters, but exemplifies with implicit conversions. Implicit conversions are in fact considered experimental and starting with Scala 2.10 the compiler will issue warnings in case you're using them without allowing "language.implicitConversions", being replaced with extension methods by means of implicit classes. Yet, he doesn't mention Type Classes, the main use-case for implicit parameters. IMHO, I can't stand languages that do not have this form of ad-hoc polymorphism. > How much of your time, as a software developer, do you spend doing stuff that is language agnostic? That's setting up a straw-man. The problem we as software developers are trying to solve when picking new languages is one of gaining access to abstractions that are otherwise very difficult to express and use. Implement something like Iteratees in Java, a higher-level abstraction for safe asynchronous stream processing with back-pressure built in and you'll see what I mean.
virtualwhys 13y ago
"Not Knowing Scala Will Make You Less Productive", is the more appropriate title. Scala is not, in my experience, a hit the ground running type language. You have to learn the ropes, discover the various gotchas (of which there are many), etc. before you begin to blow away your former self in terms of productivity.
peterashford 13y ago
I've only ever poked a little at Scala so my opinion isn't worth much, but what the OP says about operator overloading gels with my C++ coding experience. Everyone LOVES operator overloading when it's their own code doing the overloading. When you start dealing with other people's abuses of OOL, then it gets downright evil.

87 points by bartonfink 13y ago

I've seen that post previously here. It did not become better.

Man that's a bad post about Scala. Scala has a lot to love and a bunch to hate within the language itself, but writer doesn't appear to have the ability to actually discuss it.

pekk 13y ago
Why?
stewbrew 13y ago
I found it quite interesting how the Scala community reacted to such rants in the past -- mature & civilized, actually discussing pros & cons.
mcherm 13y ago
I completely disagree. The blog entry contains enough details to make me think that Graham actually understands Scala. And he raises valid complaints: * Compile-time is slow * IDE support is more poor than Java * Overuse of operator overloading is confusing * Implicit confusing I don't necessarily agree with all of these criticisms, but it's a very valid piece of "feedback" to the Scala community.
- saryant 13y ago
  Fortunately it's feedback that the community has taken to heart. 2.11 should improve compile times, as will new incremental compilation features in SBT 0.13. IntelliJ's Scala support has gotten much better recently and the official Scala plugin for Eclipse has also made major strides. (Though I still use vim) Odersky has taken an official stance against symbolic method names, especially in libraries, and many of the most famous offenders (Dispatch's absurd periodic table) are rightly ridiculed within the Scala community. I don't have anything to add on implicits. They've certainly tripped me up a few times but generally it's just a matter of finding the right import, though I have been cursing Play's implicit JsValueWrapper the last few days.
  - adriaanm 13y ago
    Thanks. I should add that dispatch has long abandoned their periodic table (before they got called on it last Scala Days, actually).
    - saryant 13y ago
      That's good to know. I haven't used Dispatch since 2011 when I first started using Scala (that was a rough introduction). I'm looking forward to Play moving their WS package out of the core though—right now we've basically written a few wrappers around AHC in their style for the pure Akka parts of our stack but we'd love to standardize.
  - deleted 13y ago
    [deleted]
- hashtree 13y ago
  Agreed, his terse ~5000 word post to describe what you did in ~120 characters was well thought out.
- hp 13y ago
  Scala doesn't have operator overloading btw. It just doesn't restrict method names very much. This is very different from how C++ treats operators as special cases. If you give your methods bad names, it really is not the language's fault. You can probably find a way to make a bad API even if you are limited to a-zA-Z0-9 ... If a library has an inscrutable set of method names blame the lib not the language.
  - hapless 13y ago
    Operators are treated specially in scala. Methods with certain names have wildly different precedence rules. The special operator rules allow library authors to create a "DSL" without using the (difficult) macro system. This almost never ends well.
  - mcherm 13y ago
    I know that, and I use the term only because the author did. I agree that it's the fault of library designers not on the core language, but it is still a legitimate issue to raise.
Rotten194 13y ago
Feel like actually discussing the article instead of attacking the author?

camus2 13y ago

Well the problem with Scala is at first it looks like a concise java but it's not. Truth is it's closer to Lisp with a C syntax. If you dont understand some idioms like lazy evaluation, everything is a method or pattern matching you probably should use it. I think scala rocks. The only downside is the slow compiler. But SBT , worksheets , stuff like that are just awesome to toy with stuffs in an interactive manner.

akbar501 13y ago
I totally agree on the slow compile times. It's simply painful.
penland 13y ago
Scala is much closer in spirit to ML / OCaml / Haskell than a LISP dialect, but I do agree w/ you that Scala rocks. It's my favorite language I've picked up since O-Caml.
chimeracoder 13y ago
> Truth is it's closer to Lisp with a C syntax. The only similarity that Lisp and Scala have are that they are both functional programming languages[0]. Scala is a heteroiconic language. At least until recently, Scala didn't even have macros (I think they may have added that recently). Scala is a nice language, but saying that Scala is somehow like Lisp is doing a disservice to both languages. [0] Even the statement that Scala is functional is itself debatable - one can make the argument that it is "just" more purely object-oriented than Java, but that's a whole separate discussion.
- adrianm 13y ago
  Why do people think Lisp is a functional programming language? If anything, traditional Lisp is the antithesis of a functional programming language. What Lisps are you referring to? Maybe we're just defining our terms differently, but the closest Lisp comes to a functional programming language is Clojure and before that Scheme. This is not meant to deride Lisp in any way (Clojure is my language of choice, after all) - I think all Lisps enable a fundamentally unique way to reason about programs, but that's a characteristic of Lisp and not of functional programming languages.

hhm 13y ago

My main impression after using Scala a little bit (admittedly some time ago): it has some very cool functional features, but they are too slow when compared with the non-functional features. When working on a program for which performance matters, this means that you end up working on a Java-like subset of the language in most of the program.

kasey_junk 13y ago
Well I would argue that when you are working on something where performance matters on the JVM you end up working on a very C-like subset of your language. Java makes the translation to that subset easier than Scala, but you can certainly do the same translation from Scala.

mcv 13y ago

Scala has a couple of features that make it by far the best programming language ever conceived by mankind. But it has a couple of other features that utterly ruin it with total unrecoverable brain damage. I would really, really appreciate a Scala without all the crazy, but with all the brilliance. Or, you know, just a community that doesn't go out of its way to overuse all of that crazy. Just drop the incomprehensible type declarations and the incomprehensible operators. Maybe add dynamic typing, even. Then you'd have a really nice language.

pathikrit 13y ago
Scala [has][1] dynamic types. [1]: https://github.com/pathikrit/dijon https://github.com/pathikrit/dijon
hapless 13y ago
I keep hoping that the operator abuse is just a growing pain. The language community has been given a new toy, and they're going to chew on it. Eventually libraries that will come along that were intended to be used by humans. Sbt will disappear. Flowers will bloom, and the lion will lay with the lamb.
anonymoushn 13y ago
Moving to a simpler type system is not the only option. If you want to avoid the incomprehensible type declarations while increasing the strength of the guarantees the language makes at compile time, you might consider OCaml.
- bad_user 13y ago
  Personally I find Scala to be more elegant than OCaml. In OCaml OOP is a strange add-on, whereas in Scala it's an elegant mix.

Aqueous 13y ago

I really disagree with this article. Type safety combined with Play's refresh-recompile trigger means it is not meaningfully less productive than PHP, and maybe moreso because compiling is usually an indication of your program's correctness, so you don't waste time tweaking-reloading-tweaking-reloading. Compiling is slow, yes, but it saves you more time than it costs you because static typing means a whole class of bugs just never happen for you. I know that the IDE support is lacking but this doesn't really bother me since I don't use an IDE with Play apps. I always use a text editor, since I find that IDEs tend to do a bunch of things badly, whereas a text editor and a terminal each do a single thing very well. There's nothing you said about the features of an IDE that I couldn't do just as well with a well-defined find-replace (besides variable extraction - not familiar with variable extraction.) You can be productive in any language - Java, Scala. But I find that Scala's conciseness - the fact that I can do an operation on a whole collection of case classes using pattern matching and the collection API functions that would take 30 lines using classic Java - ends up making me more productive than I have been in those other languages. Maybe it's just me.

mason55 13y ago
> Not even sure why people need an IDE. For someone learning Play & scala in general I find the IDE to be immensely helpful in showing my type information and valid auto-completes. Rather than constantly digging through documentation I can see that, for example, some flatMap will give me a list of (Id, User) tuples, so then I can call map( case(id, user) => user) ) (or just map(_._2)) and pull out the user objects to get my list of users from my list of tuples. This lets me focus on the business logic and not spend all my brain power tracking types. I don't think I would have survived my first foray into building complicated composite ResultSet parsers in anorm without the IDE. I'm sure that as I gain more experience and all the functions become second nature I'll be able to track it in a text editor but for now I love my IDE.
- Aqueous 13y ago
  Yes, I edited that statement out - I'm sure people have good reasons for using IDEs, immediate type evaluation being one of them.

ryanobjc 13y ago

Interesting post, a little random, ultimately it's really hard to 'prove' something like this in a single article. Studies maybe, but there'll always be someone saying something contrary. I can only really offer my experience, which is architecting and building out a 25kloc app and team to go along with. Mostly, because we avoided the 'clever' scala stuff as much as possible, things went well. Maven instead of sbt. Jetty instead of play. The only scala DSL we used was squeryl. If I was doing it again, I'd probably rethink the use of scala. As helpful as it was, it was also a pain in places. Having to rewrite all our for loops was not cool. Case classes saves on boilerplate, but frankly you only write that stuff once, so it didnt really save us on a lot. Intellij elides most of the junky boilerplate (import statements, generating setters/getters, etc) in Java, so ... Now a days with the advent of Java8, we have access to lambdas, function pointers/interfaces, and the functional stream system, I am interested to see how far one can get in just pure java. Java is the new scala it seems.

kasey_junk 13y ago
Honest question that I haven't taken the time to figure out. Do I still have to have only 1 file per class/interface in Java 8?
- ryanobjc 13y ago
  you've never had to only have 1 class per file. You can only have 1 public class per file however. You can also nest classes in other classes for quick little data types you need locally. So the notion that every single last tiny class has it's own file hasn't ever been true (even if thats the coding style in a lot of code).
  - kasey_junk 13y ago
    But if I have an interface and a couple of implementations I'm back to multiple files right?
    - mason55 13y ago

playing_colours 13y ago

A very important point for me in Scala is that now I can consider building the company stack with it. The libraries and infrastructure are really getting better. We have Play for web applications, Spray, Scalatra and more for APIs, actors / futures / STM / Akka for concurrency, and you can easily intergrate Akka with Play and Spray, use the same patterns at different parts of your infrastructure. We have Scala.js for frontend work. Growing numbers of frameworks for Big Data. Those are maturing and being developed for industry needs, tested in production at some known companies. Don't forget it's based on solid JVM with huge amount of Java libs available. I have confidence to advise building real businesses with Scala stack and not looking like an irresponsible guy who just wants to play with the latest and shiniest stuff hazarding a company's business. I also see how Typesafe is focusing on solving bad parts: compiling time, stability, etc. You can also stay away from advanced / theoretical / crazy parts of Scala most of time. You don't need to use Scalaz, advanced type system features etc. There are also immature libraries, toys and proof-on-concepts, but you cannot blame Scala for your choice.

mason55 13y ago
I'm curious about the fact that you're using both Play & Spray. Are you using them in the same app? It seems like there's a lot of overlap between the two and that by switching to Spray as your backend you'd just be generating static HTML with Play.
- playing_colours 13y ago
  Spray (or Unfiltered at my previous project) is used for a different part of the project. It's basically used on parts where you can expect high load, lots of requests / responses and tight integration with Akka system for processing large amounts of data. Play framework was used to provide UI for our data team or end users to see statistics, do some operations and it's not bombarded by large amound of requests.
  - mason55 13y ago
    Makes sense. I'm building out on Play right now but given that my long-term goal is to have a JS view + REST endpoints I'm still not decided on whether I want to stay on the Play UI/template model or switch to something like Backbone.js + Spray.

sramsay 13y ago

The OP jokingly names a law after himself at the end, but I move that we do name something after him. I'm going to call it Ahmdal's Condition. It goes like this: In this lengthy [post|comment], I’ll share my thoughts and opinions on [THING IN COMPUTING, TiG hereafter] . . . Using a cavalcade of flawed data; logical fallacies; biased opinion; startling lack of citations; and basic nonsense, I will convince you that using [TiG] will make you less productive. I will finish with an underwhelming and unexciting conclusion. You have been warned. Think of it! "I'm offering my thoughts here under Ahmdal's Condition, of course . . ." "Well, I think you're starting from Ahmdal's Condition . . ." "That works under Ahmdal's Condition, but assuming stricter conditions . . ." Honestly, it's genius. If I had a magic meme wand, this guy would be famous by the end of the day.

NoodleIncident 13y ago
Surely it would be Graham's condition?
jamesaguilar 13y ago
Is it necessary to provide randomly controlled trial/other scientific data to talk about things you don't like in a programming language? Do you have the same standard for talking about things you do like in a programming language? My only problem with the article is that the hyperbole/sarcasm (e.g. "I've given irrefutable scientific evidence...") is not so well done.
- loup-vaillant 13y ago
  Rational evidence doesn't have to be scientific. But. Even first hand anecdotal evidence has its limits. It really needs to be blatant to be significant. Second hand anecdotal evidence is even worse. If the phenomenon you want to catch is subtle, you generally a good deal of reliable data. That generally means something "scientific".
  - jamesaguilar 13y ago
    My point is that people demanding scientific data for criticisms had better do the same when their favorite language gets praised. Of course, personal evidence is less strong than scientific evidence. That much should be obvious to anyone.

istvandobai 13y ago

> I’ve been developing software professionally for a whopping 3 years. So much experience! Scala isn't for the beginners. > I’ve given irrefutable scientific evidence on why Scala will make you less productive. Yeah, science! Those are just your opinions not scientific evidences. You're just don't know how to program in other languages(only in simple languages as java, javascript and python).

sehr 13y ago
I'm sure you have grounds for disagreement with the author, but please do so in a more civilized manner. http://paulgraham.com/disagree.html http://paulgraham.com/disagree.html
primelens 13y ago
While you might not agree with his account of Scala, saying that folks who only know "simple languages" like "Java, JavaScript and Python" are unqualified to comment on Scala is just bizarre. Pray tell what you consider to be a language that would make a programmer worthy of Scala.
- istvandobai 13y ago
  Oh, sorry it seems like i had to say "basic" not simple. It's funny that some people can't understand a simple sentence.

sandGorgon 13y ago

Has someone learned Scala and Go simultaneously ? This may seem a strange question - but I underwent this when I solved the Stripe CTF gitcoin challenge. I think that particular challenge was the most interesting because it branched into the leaderboard challenge. I wrote the same code in Ruby-Celluloid, Python-subprocess, Scala-Akka and Go. When I did this, I came to an strange realization - I absolutely did not have fun writing Scala/Akka code as much as I did writing Go (minus the unused variable fascism). Again, I'm not at all arguing the ecosystem of the JVM vs Go, but I just had a much better time grokking Go code than Scala/Akka - especially the package manager (pulling deps directly from github, etc.) I even sent in a patch for a go package ("gocmd" on github) barely a couple of hours after I first touched go for the first time in my life. I dont have production worthy experience in either, so I dont have a strong opinion... but I really ended up wondering if Go makes Scala obsolete.

namelezz 13y ago
I was learning Scala and Go simultaneously. Hey, you forget to mention compiling time. Go is so fast that I just want to cry when I compile my Scala code.
nutate 13y ago
Trying to drink the scala kool aid here at work, but I had a similar situation with Go and a freelance job. Went from 0 real experience to working code in very little time w/ go. With scala I feel like I've spent more time waiting for it to compile than actually coding. Especially since we have been doing so much in Python, the switch back to compiled Java (with saccharine scala flavor) is like jumping back a decade in terms of productivity. Also, as you mentioned, the Go syntax is much easier to read, superficially just K&R C style with the types on the opposite side of the variable names.
anentropic 13y ago
Oh good it's not just me... found it very annoying that the Go compiler complains of unused variables!
- sandGorgon 13y ago

ninjakeyboard 13y ago

"I call bullshit. I rarely generate code. I rarely write getters and setters." You must be writing some crazy java.

RyanZAG 13y ago
Not at all. Getters and setters are a nasty code smell that generally arises when the author does not really understand OOP. You delegate to objects (tell, don't ask). Delegate to objects generally means person.goToWork() and not person.setIsAtWork(true). If your code is full of getters/setters you can probably refactor it to be far clearer. A more non-conventional Java (but very far from crazy) is to use property accessors (person.name) instead of methods (person.getName()) for "data objects" (structs, really). Some people are very much against it as they believe it stops you being able to modify your object later, but I'd say modifying the access behavior of a struct (eg, O(1) to O(n) access) is even worse than forcing users to update their use of the object. Anyway it's a far deeper topic than just "crazy java".
- ninjakeyboard 13y ago
  Thanks - that's a great reply. There are lots of horrible code smells common in java like 'Impl' for names. Interesting rebuttle - nice one.
- unclebucknasty 13y ago
  >A more non-conventional Java (but very far from crazy) is to use property accessors (person.name) instead of methods (person.getName()) for "data objects" (structs, really). Yeah, it's a bit of a fallacy that requiring getters and setters (especially as simple pass-thrus) for simple properties is required for "good" OO (particularly that it maintains encapsulation). The bottom line is that providing both getters and setters makes the property mutable just as it would be via direct property access. Except now there's a performance penalty, as you mentioned. And renaming a property typically means renaming the getters and setters anyway lest the property name no longer makes sense internally. Any good IDE will allow you to accommodate either refactoring (property name or accessor method names) with ease. Initially, setters were also intended to allow the object to fire an event in the case that it's Observable or otherwise participating in a listener-style event system, such as that prescribed by the JavaBeans spec. But, in practice, that pattern is followed so rarely that it hardly merits forcing all of that baggage on every value object ever written.

bad_user 13y ago

> If functional programming is what you want, you can do it in your language. This is a fallacy that gets repeated over and over, ad-nauseam. No, you can't do functional programming in any language. In Java it's more than just lack of syntactic sugar. Java's type system actively fights against functional programming. This is a bit like saying that you can do OOP in any language. Yes, you can have GObject in C. Yes, for Java there have been attempts like www.functionaljava.org ; but it sucks so badly that almost nobody does it, unless they are forced to do it. In fact I challenge the author of this article to show me a piece of FP code that he wrote in Java by himself. > What about all the wonderful things in the standard library? Yep, filter and map and fold operations on collections out of the box is nice. That the SDK uses Option instead of null is an improvement. These things are nice, but I generally get what I’m looking for by adding some libraries to core Java. I do know Java's ecosystem and he must be speaking about Guava, as there's no other stable library for Java that has persistent data-structures. And Guava kind of sucks, so if you're looking for persistent data-structures, might as well implement them yourself, it's fun and it might open your eyes to what functional programming is ;-) Speaking of Guava's Option, lets talk about how Guava's Option is not a Monad, or for those that don't know what that is, basically a context that implements map and flatMap with certain properties. Scala's Option also implements filter and fold, etc... which in regards to the purpose of a Monad, in the words of Erik Meijer, is to guide you through the happy path. Now that's a little closer to functional programming and speaking of Erik Meijer, people might be interested in what he thinks about Scala: https://twitter.com/headinthebox/status/438355100310831104 https://twitter.com/headinthebox/status/438355100310831104 On the bad things he lists: > Compile Time Scala's type-system is much more static, leaving much less room for accidental bugs. Scala's compiler does things that in other languages you'd need to run specialized tools to get the same results or to write more tests. A single sentence or paragraph can't do it justice, but the big compile times are perfectly justified and this is coming from a developer that prior to Scala preferred dynamic languages with instant edit/reload cycles. Besides, these times have been dropping as the core Scala devs have been making improvements, with another batch of optimizations coming in Scala 2.11. And incremental compilation in general works great. And I'm a developer, I have a good dev machine - if you don't have an SSD and at least 8 GB of RAM, then you've got no excuse. > The IDEs I've been using IntelliJ IDEA since a year ago and for people reading the rant exposed by the article - IntelliJ IDEA 13 for Scala is everything you'd expect an IDE to be and more. I never had problems with renaming things. I never had problems with finding all usages of a type. IntelliJ IDEA 13 works flawlessly for viewing the inheritance hierarchy and I'm doing the Cake Pattern which is freakishly heavy on the traits ;-) Other languages only dream about such awesome IDE support. > Overuse of Operator Overloading He complains about SBT, but I thought we were talking about the language and the standard library. Pity that he doesn't exemplify an instance in which "+" is overused. > Implicit He mentions implicit parameters, but exemplifies with implicit conversions. Implicit conversions are in fact considered experimental and starting with Scala 2.10 the compiler will issue warnings in case you're using them without allowing "language.implicitConversions", being replaced with extension methods by means of implicit classes. Yet, he doesn't mention Type Classes, the main use-case for implicit parameters. IMHO, I can't stand languages that do not have this form of ad-hoc polymorphism. > How much of your time, as a software developer, do you spend doing stuff that is language agnostic? That's setting up a straw-man. The problem we as software developers are trying to solve when picking new languages is one of gaining access to abstractions that are otherwise very difficult to express and use. Implement something like Iteratees in Java, a higher-level abstraction for safe asynchronous stream processing with back-pressure built in and you'll see what I mean.

virtualwhys 13y ago

"Not Knowing Scala Will Make You Less Productive", is the more appropriate title. Scala is not, in my experience, a hit the ground running type language. You have to learn the ropes, discover the various gotchas (of which there are many), etc. before you begin to blow away your former self in terms of productivity.

peterashford 13y ago

I've only ever poked a little at Scala so my opinion isn't worth much, but what the OP says about operator overloading gels with my C++ coding experience. Everyone LOVES operator overloading when it's their own code doing the overloading. When you start dealing with other people's abuses of OOL, then it gets downright evil.