26 ms·

Scala – 1 Star – Would Not Program Again

• JulianMorrison 13y ago
  Problem: author is pining for Go, and doesn't know it. Solution: author should abandon the JVM ecosystem and use Go. - Fast compiles. - Ultra simple, non extensible syntax, yet not verbose in practise. - The code you see is 100% of the code. - A culture of implementing the simple algorithm. - Stable, with version compatibility guarantees. - Nobody is trying to make the types jump through hoops, so the type inference works.
  • goldenkey 13y ago
    It's hard to take your comment with impartiality when 90% of your comments mention Go.
    • politician 13y ago
      I agree with the parent that the author should investigate Go, but add that the author will get all of those benefits plus a dependency management headache.
  • retrogradeorbit 13y ago
    Maybe the author needs Java Interop.
  • kvtrew76557 13y ago
    I happen to like Go, but the excessive marketing of Go on HN as a solution to every "problem" is tiresome.
    • eropple 13y ago
      Agreed; I like a lot of what I see in Go (though admittedly I liked it about as much when I saw it before Go was released) but the hype is getting to the point where it's impossible to take the general Go advocacy on HN seriously. I'm starting to wonder when, when I mention C++, I'm going to be told that Go will fix all my problems. (Rust might; Go won't.)
  • danieldk 13y ago
    If you hadn't mentioned Go, you could have described Java with these bullet points (with the exception of the last). Why throw away all the proven libraries, extremely good garbage collector, IDEs, intrumentation? Java is a perfectly fine language and if you think it is too verbose, there are good other options such as Kotlin, Groovy (which offers static typing nowadays), Ceylon etc.
    • vorg 13y ago
      > Groovy (which offers static typing nowadays Groovy's static typing is quite recent, written by one person only, and not actually used in many codebases. Neither Grails nor Gradle uses it. There's only really 2 or 3 use cases for Groovy: * quick & dirty scripts for Java class testing and manip * Grails * more recently, Gradle (which still ships with Groovy 1.x) If you want static typing on the JVM, best use a language designed from the ground up to be staticly typed, e.g. Java, Scala, Kotlin, Ceylon.
  • cryptos 13y ago
    I tried Go for the same reasons. It looked to me like a statically typed Java, but in practice it was not the best experience. The Code is not more expressive than Java, but you lose all the good libs and tools from Java. Most annoying was the in ability to create concise mocks, because you cannot implement interfaces at runtime with Go.
    • cryptos 13y ago
      I wanted to say: "it looked to me like a statically typed Python"
  • threeseed 13y ago
    You forgot to mention go-routines. I don't think I could survive another day without hearing about how amazing they are and will completely reinvent concurrency as we know it.
  • asdasf 13y ago
    People think I am pining for go too, for similar reasons. Yet I tried very hard to like go, and was unable to put up with such a primitive language just for the nice tooling. Not everything is a "you just need to use go" in disguise.
• weddpros 13y ago
  I like Scala. It's a JVM language, it's extremely powerful, but maybe it's too powerful for us mere mortals. Eclipse allows very fast compilation times, but when I tried sbt, I gave up because I CAN'T wait for compilation: we're in 2013, I'm using a quad core at 3.4GHz, 12GB of RAM and SSD, so I'm not ready to wait. Eclipse allows fast incremental compilation. Scala's type system is very rich. I don't know if there exists any type that can't be expressed in Scala. Since I don't know if such a type exists, I don't miss it. But that's probably too much, and in the end, idiomatic Scala emerges: some libraries use the type system in an idiomatic way. It's working, but understanding method signatures turns into a nightmare. Then you must learn the arcane of Scala to understand how the library works. However, if YOUR Scala is simple enough, then the language can be cool, cooler than Java, and productive. Can be mixed with Java, runs fine for J2EE...
  • chrismonsanto 13y ago
    > I don't know if there exists any type that can't be expressed in Scala. Scala has a very rich type system, but let us not get ahead of ourselves--Scala, being non-dependently typed, cannot type many useful programs. For an example of a useful dependent type, consider giving division the type Number -> {x : Number | x != 0} -> Number. Giving division the type Number -> Number -> Number is similar to how older Javas would type List<String> as List and require all get operations to cast from Object--in both cases, the type system is unable to guarantee that your program won't crash. If you want a glimpse of the state of the art of programming with dependent types, try Agda[0]. [0]: http://wiki.portal.chalmers.se/agda/pmwiki.php http://wiki.portal.chalmers.se/agda/pmwiki.php
    • TylerE 13y ago
      How does that actually work? Does that "type" basically compile down to an added n != 0 check at runtime, or is there more sophisticated dataflow analysis/theorem proving going on?
      • tel 13y ago
        Usually it enforces statically that you cannot create an Integer that violates its preconditions. If you even do so dynamically it'll make sure there's a dynamic check before the dynamic value can substantiate the more specific type.
• bootily 13y ago
  As a java Dev I have been watching Scala to see what people make of it. It seems like Scala is generally perceived as an academic exercise. We all want more powerful tools and infinite expression but at what point are we bikeshedding languages instead of building transparently clear solutions? Scala seems to be solving problems i dont have.
  • jfb 13y ago
    It seems more to me to be an academic exercise in compiler complexity that has been wrapped in a shell of "lookit! Java++" as a play for industry acceptance. I haven't been working with it for long, but I feel that there's a lot of interesting stuff that has become unusably complex because of the design decision to support toll-free Java interop. That makes me nervous.
  • kenbot 13y ago
    There's a lot of "seems" going around from people who haven't used the language, or dynamic-typing folk who obviously aren't going to pick a language that bets the farm on static types. As a long-time Java dev myself, Scala is solving problems you don't even realise you have, because you don't know to look for them. Powerful types, immutable state and FP make a world of difference for writing clear solutions, with better abstractions, less code, less bugs and less bullshit than the horrendous status quo of corporate Java development.
    • bootily 13y ago
      Actually I just want to reiterate, regardless of typing problems that CAN exist and be prevented by a compiler, I do t ha e those problems in my codebase and neither do most people.
    • dbcfd 13y ago
      > less code, less bugs and less bullshit than the horrendous status quo of corporate Java development. It may take some getting used to syntax and design wise, but being able to code things up in 1/10 the size of other languages completely blows away the disadvantages of Scala.
  • 13y ago
• andrewcooke 13y ago
  something weird with attaching anonymous functions to method calls that's still a thing? i thought i was just being dumb back in the day.
• elchief 13y ago
  Just shut up and use Java. It's fine.
  • smegel 13y ago
    And with Groovy as a scripting layer, it's more than fine. Quite good in fact.
    • Keyframe 13y ago
      Is Grails as good as they say it is?
      • fat0wl 13y ago
        I think it may be but I came to the Java ecosystem to escape RoR.... it seems we should be able to do better than emulating Rails minus the existing gem community, no? I have much more faith in the JVM but would like to see it provide a step beyond Rails rather than catching up. Play is nice because it is trying to accomplish this with Akka, though yes I see there are other issues. As mentioned in another comment, I'm kindof just wishing there was a cool Clojure framework. Maybe I will try one even there is not so much of a consensus as there are around these other emerging JVM frameworks...
        • wging 13y ago
          Have you tried Pedestal or Luminus?
        • Keyframe 13y ago
          I'm trying to escape PHP, but terminal velocity is hard to achieve since now I have Laravel to work with. I'm looking to venture off either into JVM space or Go.
          • girvo 13y ago
            I tried the same thing. I now play with C and Nimrod... And just doubled down on PHP. You'd be amazed at how powerful it can be in the right hands... Or not, as you're using Laravel ;)
• fat0wl 13y ago
  I've been using Scala just to learn Play framework (I know I could use Java but I thought I'd be adventurous). I think in truth, though, if there were a web framework in Clojure as well received as Play I would be bounding down that path instead. Clojure seems to be where a lot of the JVM interested is heading yet we're not there yet for some reason.
  • jadyoyster 13y ago
    I've been wondering - having never used a web framework except for some RoR - what people miss in the idiomatic Clojure way of doing web (composing libraries like Ring, Compojure, Enlive etc). Care to share?
    • fat0wl 13y ago
      Honestly I haven't used Ring/Compojure/Enlive beyond tutorials so at this point I'm very intrigued but don't have much to say yet. My belief though is that there is some peace of mind that comes from the idea of what you might call "page composition" -- that this piece of data sits in this template, that it rides on top of this simple model, that it is in ORM from database. There is a huge amount of linearity and convention throughout the stack and because of the dynamic nature of Ruby lots of gems can be sprinkled throughout without one really understanding what they do. Now, I'm certain this level of abstraction and functional/mixin kindof stuff can be achieved in a Clojure framework but I think it is generally perceived as being a bit more non-linear and DIY (libraries not necessarily playing nicely together). As in "yes I can get all of these pieces together but then if down the line I have to change this piece, how will I accomplish it without breaking everything". Essentially, I think the perception of OO is more alluring in terms of project cohesion, whereas functional programming is seen more of a supposedly incorrect assumption that an HTML document is simply an assembled mass of text. I'm really just trying to convey that RoR and the like seem to be making a COMPLETE ("in a few lines I can do anything short of my business's custom domain logic") framework out of the box and perhaps there is some stigma attached to the nature of Lisp that makes it seem as though framework developers are not striving to cross these bridges and there is less of a community to keep them in check. Eh, I wish that made more sense but this is a lot of conjecture based on perceptions -- it's clear that a lot of these communities emerge from hype & reactionary values moreso than anything else. People wanted to shift away from PHP and be more productive without getting radically far away conceptually. I just got dizzy thinking about this lol... but yeah I think Java developers are a bit more open-minded when it comes to application development, seeing things more matter-of-factly than the languages with only MVC/Model2 kind of frameworks. I think if an attractively-packaged Clojure library were to emerge and get the right publicity (sad but thats how the web dev world is...) it could steal the hearts of many Java devs. In my limited experience with Clojure it seems fun AND powerful. Yes there is a learning curve but that is to take it above and beyond. The simple functionality of most web apps could probably be achieved without writing anything too mind-bending. Please do respond even if that response involves completely ignoring my rambling... I'm very curious to understand the Clojure community better :)
• NickPollard 13y ago
  I started learning Scala almost a year ago at my latest job - we use it for production systems at a large multinational investment bank. Coming to Scala from experience including C, Java and Haskell, I intially found Scala quite difficult. It is true that there are some things in Scala that are not obvious to newcomers, and that are difficult to discover for yourself - such as the use of Implicits, and the strange precedence and binding rules for operator syntax. That said, it doesn't take long to learn, and once you do, it all makes sense. There are other great languages out there (I'd say Haskell is one), but compared to for example Java, or one of the dynamically typed languages, Scala is superb. Types, whilst not having the full H-M inference, are brilliant. That the author complains about having types rather than a simple map for keys shows a misunderstanding of what they are there for - the idea is to allow the compiler to prove at run-time what is valid code and what isn't. He comments that tests run too slowly in Scala (they don't - for our production systems building in SBT, a typical test run is significantly less than 10 seconds) but a lot of the time I don't even need to go that far - my IDE already highlights errors in the code as I type, where I have passed in incorrect or insufficient data. Also, the author makes a strange comment that H-M 'enabled' Monads, and the comment is written in a way that implies that Scala does not have Monads. This is incorrect. Scala has monads, and the Scalaz library has huge support for Monadic programming. We use Monads and Applicative Functors (a close relative) daily to build high level abstractions, and we couldn't live without them. In Scala we say flatMap rather than bind (or >>=), but we mean the same thing. Although thanks to the same flexible method naming that the author complains about, you can in fact say >>= if you wish. If you've only got a couple of days to use a language, and you're using it for a tiny project, then Scala is not for you. If want to learn a language that can make you vastly more productive whilst at the same time making your code safer and more robust, Scala is a very effective candidate. It's not the only candidate, but you should at least consider it.
  • saryant 13y ago
    I'll echo all of this (minus scalaz, we don't use that). I'll give an example of the power of Scala's type system. When I first convinced one of our founders to give Scala a try, he used it to write the first pass of our analytics service. He'd never written Scala before but once it compiled, it ran correctly on the first try, that's the power of its type system.
• wiradikusuma 13y ago
  To be honest with you, I use Scala as a better Java. Which means I still code imperatively (and use null instead of None) but with less noise (semi colons etc). But, esp when working with collections, I take advantage of Scala's features. It's not perfect, but it works wonderfully. I can always revisit/refactor my code again later.
  • solomatov 13y ago
    None vs null has nothing to do with imperative/declarative programming.
    • svachalek 13y ago
      I believe that is implied by the conjunction 'and'.
  • ffk 13y ago
    Using null instead of None means you are more at risk of hitting a NPE. Here are a couple examples: myVar match { case Some(val) => doSomething(val) case None => handleNone() } myVar.getOrElse("else") In both of these cases, we eliminated the possibility of a NPE through the use of a language feature. :) (edited for formatting)
    • gclaramunt 13y ago
      or myVar.map({ val => doSomething(val) }).getOrElse(handleNone())
    • EdwardDiego 13y ago
      > Using null instead of None means you are more at risk of hitting a NPE. I think he's aware of that - he said he's using Scala as a better Java, what would Java be without the odd NPE?
  • fizx 13y ago
    You might be better off using a pre-release snapshot of Java 8 as a better Java. You'll get closures, functional collections, and better type inference. I bet Eclipse and Intellij support it better too.
• mikkelewis 13y ago
  I think Scala is great as long as you stay on the road and not end up in the deep depths of academic hell (i.e. http://blogs.atlassian.com/2013/01/covariance-and-contravariance-in-scala/ http://blogs.atlassian.com/2013/01/covariance-and-contravari...). I should say one thing however: I'm using Scala because of Akka. An extremely powerful library that does a good job of hiding the complexities while still allowing you to be flexible.
  • bcoates 13y ago
    That's a gratuitously category-theoretic explanation, all you need to explain covariance and contravariance is is-a. An immutable List of Foos is a List of Bars if a Foo is a Bar. A function taking X and returning Y is a function taking A and returning B if A is a X and Y is a B. It's just answering the question "Can I use type relationships to guarantee that I will have no run-time conversion failures?"
    • deleted 13y ago
      [deleted]
    • evincarofautumn 13y ago
      T is covariant (positive) if A ≤: B ⇒ T<A> ≤: T<B>. T is contravariant (negative) if A ≤: B ⇒ T<B> ≤: T<A> (i.e., the other way around). Pretty simple stuff.
      • pkolaczk 13y ago
        It is easy to remember if you think of it: + (covariant): the type can be cast to some broader (more general) type - (contravariant): the type can be cast to some narrower (more concrete) type
• runT1ME 13y ago
  I'm always interested to see intelligent criticisms of one of my choice languages. Let's take a look at what he has to say: Slow build times complaint > It is essentially impossible to practice TDD in Scala simply due to the time it takes to compile. Hrmm, that's interesting, because it sure seems like other people are able to do this. I agree, the slow build times are annoying, but let's not exaggerate. SBT critiques >That punctuation-strewn build system I was forced to use was just taking advantage of Scala’s ridiculously flexible syntax. Yeah, I get it, everyone makes fun of SBT's syntax. Language is complicated This is where it just kind of descends into whining about how 'hard' the language is. He claims javascript is a "simple" language. Does he just not count the weird edge cases when thinking about complexity? Type inference complaint > And this is the real death knell for Scala. Hindley-Milner Type Inference is a fantastic thing.... It’s enabled monads, which you want to be able to understand and then use in a type-free language. WAT. I don't think those words mean what you think they mean. >In my mind, Hindley-Milner was always the promise and the pay-off for Scala...I know this is the fault of the JVM’s use of type erasure. I don’t care. O REALLY? Go on... Maybe if this guy had cared enough to do a five second google he'd realize that Scala doesn't use hindley-milner type inference. Bottom line is, I think I have a good understanding of the type of programmer this guy is, and it's exemplified nicely in this quote right here: >Sure, with another couple hours we would have been able to figure it out… [but] We ended up copying and pasting the same four lines into all our endpoints. A dark moment. For an intelligent critique of the scala langauge see here: http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...
  • plorkyeran 13y ago
    The "simple language" comment was about CoffeeScript, not Javascript. One of the common complaints about CS is that you absolutely need to know what JS every nontrivial CS contruct compiles to, but he doesn't consider this a big deal because there simply aren't very many of them. Scala, on the other hand, has more features that he considers "magic" than he can easily keep track of.
  • hp 13y ago
    the sbt point is really outdated; sbt 0.13 only ever requires you to use "foo := bar" (assign bar to foo), though one might choose to use convenience operators such as "foo += bar" (append bar to foo). sbt's syntax has been cleaned up nicely and now it has very clean syntax.
• Ygg2 13y ago
  What is my biggest gripe theoretical gripe about Scala is that Trait order is important! Because traits can override common function. A class that is e.g. Ball with traits Shiny and Red is NOT the same as e.g. Ball with traits Red and Shiny. Why? Why complicate testing to a point where you need not only test traits for correct behavior, and not just composing of Traits, but even the order in which they are composed? Why?! Why complicate it so much? Note: It's been a while since I've seen traits, this might have changed for better. To me Scala is essentially if Java, Haskell and C++ went to a wizard to have a child. The result is a magical mess. I seriously think that Scala has at least twice as many concepts as C++ and same if not greater number of really weird edge cases. I don't want to keep Scala in my mind, no more than I want to keep Necromicon.
  • pkolaczk 13y ago
    As long as your traits are independent, the order does not matter. Anyway, how do you imagine this could be done better? For order to not matter, the linearization could not be possible and we'd end up with something much more complex and ugly like multiple inheritance in C++ with all the diamond inheritance problems, etc.
    • Ygg2 13y ago
      Don't have an answer right this minute, but I think eschewing/forbidding variables in trait would prevent the most obvious such collisions. If you can't override variables, you can't silently change the structure to depend on trait order. You'd have to explicitly state order. PS. Of course if you have several same signature methods that call super, which is generated depending on order, same problem persist. So, forbidding variables and calling super elements should deal with most "magical" interactions.
      • pkolaczk 13y ago
        If you can't call super nor use variables then this takes quite a lot of power from traits. IMHO being able to stack many traits one on another is a nice pattern.
• dham 13y ago
  Scala can be summed up in one issue. http://play.lighthouseapp.com/projects/82401/tickets/98 http://play.lighthouseapp.com/projects/82401/tickets/98 I loved Play 1.x(early adopter also) but I have since moved on. I gave Play 2 a solid chance. Scala programmers seem to turn everything into some kind of academic paper.
  • eropple 13y ago
    I've been a critic of Play 2 on a number of occasions on HN but I don't understand the complaint. What is causing you to create URLs with trailing slashes?
    • dham 13y ago
      What is causing you to create URLs without trailing slashes? 99% of all web frameworks allow for optional trailing slash. Go to any website. A url with or without a trailing slash typically works, it either redirects to no trailing slash or just renders the same page.
      • eropple 13y ago
        What is causing me to create URLs without trailing slashes is the proper use of Play's route-to-URL mapping system. I don't emit trailing slashes because Play doesn't.
    • luos 13y ago
      It is not just about the trailing slashes. I wanted to create pretty urls but I couldn't do it in a simple way because the developers thought that in a path can not be optional parts, like: /article/1/article-slug and /article/1 So they removed a useful feature. And it was in a 2.x -> 2.x+1 release... Yesterday it worked, today not. I was not happy. :) http://stackoverflow.com/questions/14980952/routes-with-optional-parameter-play-2-1-scala http://stackoverflow.com/questions/14980952/routes-with-opti... My othern concern with scala, what is mentioned in the article, is the operator usage. How am I supposed to "invent" this <:< notation for adding headers? (dispatch lib) `val svc = url(object_url) <:< Map("User-Agent" -> "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)")` or in squeryl, converting a boolean into a "query boolean": ``` val fls = false fls.~.? ``` Other than these, I like it. When I am coding in JS or PHP I always praise the scala types/ compile time checks. I am almost afraid of dynamic typing since I tried scala. :)
• chrismorgan 13y ago
  The section on HTTP headers and typing is a little concerning to me. I've been making rust-http recently and (before I was aware of Spray) I felt strongly about the typing. So, I'd like to discuss this. Am I wrong after all? Here clearly is someone that disagrees with me. I think I should probably write up a long blog post on the topic explaining my reasoning and so forth. rust-http is, at present at least, rejecting the standard practice of stringly typed headers and is using strongly typed headers. > ... and even types for every ‘known’ HTTP header. > The known HTTP header part was particularly ridiculous. HTTP headers are defined as simple key/value pairs. You’re supposed to be allowed to add arbitrary headers. You’re not supposed to be constrained by the framework you’re using not having any support for CORS yet. He has taken a strong position against this strong typing; I take a similarly strong position for such strong typing. Yes, HTTP headers are defined as simple key/value pairs. But headers are not text; they are data. XML is defined as text. Should we use regular expressions to work with it? (True, it also has the DOM defined. But HTTP headers also have a grammar defined—it just happens to include the admissibility of extension headers.) HTTP is a serialisation format for messages; messages made up of computer-readable data, not text. I wrote a handful of paragraphs about this subject at https://github.com/chris-morgan/rust-http/issues/1 https://github.com/chris-morgan/rust-http/issues/1 where using a map instead of typed headers was suggested. As I also note there, I would not attempt such a scheme in a language like Python (my primary language for some years) because its type system is not well adjusted to something like this; I am certain it would cause many problems and feel it likely it would cause more than it solved. But in a language with a solid type system capable of expressing these things, taking advantage of it should lead to a faster, more correct program. In the end, I believe strongly typed headers are a good thing to have (it will actually make most code distinctly nicer—e.g. ``response.headers.date = Some(now())`` instead of ``response.headers.set("Date", now().to_http_header())``). The implementation of the scheme in rust-http is certainly not perfect yet; I'm not happy with it at present; I'm expecting to turn the extension headers into a trait object, and I've even considered crazy ideas like allowing users of the library to make their own header collection (request.headers and response.headers) types—that would allow custom headers to be made first-class citizens but could lead to compatibility problems. Still, I don't want to make something that I believe should be the best HTTP library around and find that people hate to use it. What do you think about this header matter?
• phazmatis 13y ago
  My problems with Scala: 1) src/main/scala/com/thingy/actualthingy JUST to get to the root of your code. 2) Recompiling/restarting is slow because liftweb and other frameworks are overly complex. 3) I'm 90% sure it would be possible to create a PRY-like debugging tool that runs your code in interpreted mode and drops you into the REPL at a certain point in your code. And yet, it'll never get built because Scala hackers are stuck in the halcyon java days of 1998. 4) Variable names first, types second = okay, now you're just being different for the sake of being different. That said, it seems like if you use scala as a more concise java with some handy functional syntax thrown in, you can make something that isn't terrible for future maintainers.
  • verticalpalette 13y ago
    As for number 4, this is because many of the type annotations are optional.
  • saryant 13y ago
    1) You don't have to do that, Scala doesn't enforce the folder/package hierarchy that Java does. Moreover, you can use any folder hierarchy you want. 2) Compiling Scala is slower than Java (sometimes much slower) but that's not the frameworks' fault. scalac is just slow, though getting better. 3) This does exist. In fact, it's built into the language. You can also use "sbt console" to load a REPL with your entire project in the classpath. 4) As the other reply said, type annotations aren't required. In that light, Scala's syntax for type annotations makes sense.
  • seanmcdirmid 13y ago
    Number 4 because...Pascal. This was actually a huge innovation over Algo's syntax back in...the late 1960s. I think Martin Odersky studied under Niklaus Wirth, so the lineage makes sense; I also think its better than the old early 60s Algo way of defining variables.
  • nogridbag 13y ago
    >> a more concise java with some handy functional syntax thrown in Sounds like Kotlin.
• lemmsjid 13y ago
  I'd say a lot of the critiques are fair but quite exaggerated. I work on a large Scala codebase and yes, the compile times for a fresh start across the codebase are very long, but TDD-type loops are very short, because you're generally waiting for two files (your test target and your test code). Still, the compiler performance in Scala is perhaps my chief criticism, though hardly a show-stopper. As codebases in any language grow, you tend to have increasing challenges in the time it takes to fire up your environment. The critique about excessive and opaque operator use in libraries is fair, though I think it actually exposes an interesting philosophical issue. Scala is unabashedly written to be a flexible language. This is in opposition to Java, which was written to be a very strict language in terms of expressiveness on the part of the developer (it's perhaps the most strict of the languages I've worked with, hence it being my example). I personally think a lot of criticisms leveled against Java's verbosity and inflexibility are unfair, by virtue of the following: Many incredibly successful and complex open source projects are written in Java. While you could say this stems from Java's enormous popularity, one interesting property of huge Java open-source projects is that I can usually crack open the code and quickly get a sense of how I could contribute to the system without breaking it. While other languages often do a better job of giving me a sense of how the system works, I generally have much trouble with extensibility unless it's Java. This I believe is because Java was designed from the ground up with the goal of limiting individual developer expressivity in favor of imagining large development teams with limited cross communication. So--I am far less anti-Java than most. But I am a big fan of Scala. Unlike Java, Scala was written to maximize developer expressivity. While writing Java can feel like putting together a legal contract, writing Scala can feel like creating a poem. I'm not making a value judgement in either direction there--I feel that poetry is a good metaphor, because things in Scala tend to fall apart in the reading department. One of the easiest things to do in poetry is to lose the reader--a great poet can put an incredibly complicated multilayered concept onto a small amount of paper--and require a graduate-level understanding from the reader to understand it. Similarly, one can very easily make Scala into an exercise in unpacking So isn't that a bad thing? Why am I a Scala fan? Going back to my initial praise of Java--Java is so simple and predictable that it's really easy to see how the plumbing works. But because the plumbing must be laid out so meticulously and in every situation, it is often hard to see how things work at a high level. You can't see an architectural sketch in Java, you can only see endless classes in endlessly nested subdirectories. This is a very low level of abstraction, and helps the layperson (such as someone approaching a new open source project) build up an understanding from the base elements. But what's lacking is the high level abstraction. Outside of programming languages, almost every knowledge discipline has a high level abstraction language--sometimes multiple languages. Usually the abstraction language is opaque to newcomers, and frustratingly so. Examples are the mathematical notations of various disciplines, the jargon-laden meta-language of historical theory/literary criticism, and what is popularly known as 'legalese'. But even less high falutin' fields have similar languages--listening to sports fans talking about what's happening can be quite mystifying to me, given all of the shorthand they're using. Similarly people talking about pop culture in areas I'm not familiar with. These ubiquitous high level languages usually share two important facets: first, in a few lines of text/speech, you can pack in many books' worth of concepts. Second, unless someone has read those books, they will have no idea what you're talking about (or in the case of pop culture jargon, having spent the requisite hundreds of hours watching movies). Scala is trying to provide a language that can express the low level plumbing as Java can, but also that can express the high level meta-language. In doing so, it opens itself to the same type of criticism that mathematical notation can receive--opacity. The pitfall, then, of Scala library developers is to create a high level meta-language (a DSL), that doesn't have industry acceptance. This is tantamount to mathematicians who create their own notation to establish proofs--such proofs can be completely unreadable to their colleagues. But this isn't a criticism that should be leveled at the idea of notation period--it's a matter of people learning to accept useful obfuscation (where jargon can reduce textual size and increase understanding) and reject useless obfuscation (inventing your own dialect of shorthand and forcing your readers to learn non-transferrable knowledge to understand what you wrote). Because they are working with such a flexible language, and one that is targeted at building high abstraction languages, Scala library developers need to think of their audience--terseness by itself is not useful, unless you're writing throwaway code. If you're going to unleash a DSL on your reader, make sure it's in a real dialogue with the reader's expected level of knowledge with regards to how such a DSL should be structured in terms of what the symbols should mean and how they fit together. I don't know how the Scala story will end, but I do believe that it is one of the few languages that reaches for an expressivity goal that needs to be achieved by at least some future language. Its reaching opens it to much criticism, and rightfully so, but I appreciate it for its ambition.
• gfodor 13y ago
  Several years ago I picked up Odersky's book. I got a few hundred pages in, considered the types of problems I had encountered in my career so far, and decided life is too short to be spending my time learning some hyper-complex programming language that seemed, like C++, to seem unable to say "no" to introducing complexity where it would provide minimal upside in Getting Shit Done. Instead, I learned Clojure. I use Ruby, the epitome of comfortable languages, for most things, and when the hard problems come up, I use clojure. My next major scientific computing problem, rare as they are, will be in Julia instead of Matlab for prototyping and java for production. Scala seems to be the hard language for easy problems. No thanks.
  • kvtrew76557 13y ago
    Unlike you I finished reading the Odersky book and am very easily "Getting Shit Done" much faster than I ever did in Ruby. It did take effort to learn the language, but it was worth it. Having apps running an order of magnitude faster with better response times is just icing on the cake. Perhaps consider getting a gentler introduction to the language, the Odersky book is rather long and goes into excessive detail about obscure corners of the language you will seldom ever see in a production system.
    • gfodor 13y ago
      I've been in enough code reviews of Scala that did simple things like string processing that inevitably got sidetracked into a navel gazing discussion about type theory, pattern matching, and functional programming to not go near the language again anytime soon. You simply couldn't understand the code without understanding tons of incidental complexity about the language. The Clojure community has its navel gazing of course, but every time I've been exposed to some crazy idea in that community it was always through the lens of providing real leverage for real problems. Most of the time when I've dealt with people trying to explain concepts to me for Scala code, I've walked away wondering what the point of it all was (beyond the fun Computer Science.)
      • pkolaczk 13y ago
• mortyseinfeld 13y ago
  Because of Clojure's dynamic typing and idiomatic use of lots of nested expressions it turns out to be a read-only language for me. Scala seems to have a huge image problem. I think part of the problem is that Odersky and crew have never written the treatise on how to use Scala's OO and FP effectively. I'm surprised that Typesafe didn't come up with their own web framework instead of using Play. One lesson to be learned is that these days you need good IDE integration and fast compiles (incremental) for rapid development. But Scala IDE support has come a long ways in the past year or so. The Eclipse Scala worksheets is awesome. I like it better than a standard REPL. Intellij support is still going strong too.
• eranation 13y ago
  I tried learning Clojure, I really did, and I have to agree, the syntax is simpler, but I can't really read Clojure or code in Clojure the way I do in Scala, I don't know why. Whenever I read articles about Scala, I keep finding it amusing, prehaps this is because I had experience with Java, but for me Scala is a life saver, can't go back to Java after this. And I won't go back to Ruby, Python or JavaScript. So I can't really understand what these articles try to achieve, it's like the "don't buy bitcoin" articles, not sure what is the goal. If you don't like Scala, thanks for sharing, but I don't see how it affects me, I will still continue using it as my go to language until I find something better (there are contenders, Kotlin, Ceylon, Dart, TypeScript, and my favorite now - Nimrod, but there is still a big gap for me to fully switch) So for someone like me who wants a statically typed language (there goes Ruby, Python JavaScript, Clojure), who thinks Haskell is too academic to be really productive (I have to think too much to get things done with it) and who don't get what is all the rage about Go (perhaps because I'm not a system programmer, in any case I still don't get it, sorry) This leaves me with no other options (except C#, which I would probably use if it was really portable) Scala is not perfect, but I feel more productive with it than with any other language, if anyone who never used Scala will decide not to even try it because of this article, I wish them luck, but I doubt this will be the case. for those who use it, they will still continue. So I really don't think I understand what is the point of such an article. Try the language for yourself, if you like it use it, if not, and you have a choice, don't. p.s. for all those poor bastards who are forced to use Java at work, Scala is by far a gift from the Gods, so it helps to keep things in proportions, one man's source for a rant article, is other's source of means to finish work at 5pm and go back to the SO and kids. (they would go back at 1pm but their Sun Certified Java EE team lead brain will explode if they will use Clojure, with Scala your EJBs or Spring code can still look recognizable, perhaps a bit more pretty) p.s. did I forgot to say I love Scala?
  • jaxytee 13y ago
    This times 1000. I have been using Scala for the past 3 months in a play framework app that serves json. Today I had to write some quick Java for an Android client, and was quickly reminded how much freedom Scala's expressiveness gives you vs Java old cruft. I mistakenly wrote a Java anonymous inner class that called a closed over variable from the outer scope like one would do with Scala closures. Of course the Java compiler threw an error because I didn't mark the variable as final. When programing in Scala, one never has to deal with such low level rigidness. It just let's you get shit done.
• dkhenry 13y ago
  So I am curious what npm gives you that sbt doesn't. I have heard it a few times how much better npm is but i haven't seen anything it does that sbt doesn't
• gesman 13y ago
  Scala looks sexy, sort of like weird haircut. But once haircut fascination is over - people expect you to do mundane tasks, like cook food or take out the garbage. Or they won't pay you. And then you realize that when Scala cannot do what you want - you can always revert to Java. And then you realize that you don't really need Scala-ing if you can do the same stuff in Java or any other strongly typed language.
  • lmm 13y ago
    >And then you realize that you don't really need Scala-ing if you can do the same stuff in Java or any other strongly typed language. That's the turing completeness fallacy. Why not just write everything in C? And java's types are inadequate for doing really generic methods - how would you go about writing scalaz's "sequence" in java?
• sechastain 13y ago
  In every critique of scala, there is this: http://i.imgur.com/KrNcIGt.jpg http://i.imgur.com/KrNcIGt.jpg
• deleted 13y ago
  [deleted]
• sandGorgon 13y ago
  Question - the job/hiring post on hen for November has many positions for clojure and one definitively for Scala. Here, I see references to investment banks using scala. Has scala become a readable alternative to java, while most of the future focus is on clojure? Does anyone know how real life performance compares between both. From my viewpoint, scala is in use at several banks and Twitter - clojure doesn't really have a big name advocate behind it. From a startup standpoint, isn't talent/hiring an issue?
  • adambard 13y ago
    Real life performance generally favors Scala over Clojure, but by a relatively small factor (2x). This is mostly due to the clojure implementation's use of reflection to achieve dynamism. Dynamism? You know what I mean. You can make this up with some really clever tools for parallelism though, if your problem fits.
    • puredanger 13y ago
      This is totally bogus. Clojure will only use reflection if calling into Java interop with ambiguous types and even those cases can be addressed with type hints (if they even matter).
  • korny 13y ago
    There are some big places using clojure - the Daily Mail uses clojure heavily for it's website, as do SoundCloud; also, like Scala, it's used internally at some financial institutions - CitiBank have some clojure, and we've been using clojure at IOOF (an Australian superannuation company). Performance is probably the last thing you need to care about when choosing a programming language for most businesses - unless you are doing hard-core analytics or handling huge scale, you just won't hit the sort of performance problems that are solved by a faster programming language (as opposed to a faster algorithm or architecture). It really frustrates me that people _still_ put such weight on low level performance. In 1997 I had people saying "don't use Java, it's performance is far worse than C++". It was mostly untrue for business problems then - and computers are many orders of magnitude faster now.
• tobyjsullivan 13y ago
  If anybody really wants to learn Scala, I'd recommend starting with the video lectures on Coursera for the course Functional Programming in Scala.
• leokun 13y ago
  > This issue reached its pinnacle for us when we were unable to figure out how to replicate the magic response composition syntax used by Spray to abstract away the addition of CORS headers to HTTP responses. I'd just put any kind of application, whether built in Scala, node.js or Go or ruby on rails behind a nginx proxy and use that for setting the headers. That simplifies a lot of things. I hope your HTTP headers aren't really so dynamic that you need to build software that changes them so much, especially not for a RESTful application.
  • nl 13y ago
    Say you are building a redistributable app with Javascript clients. People will deploy in behind Ngnix, Apache, IISm ad sometimes with nothing at all. The last thing you want is to make the deployment harder.
• kul_ 13y ago
  If nothing, at least i completely agree with complete disregard to compatibility point. Be it Scala itself or driving frameworks like Play.
• f7t7ft7 13y ago
  > The workflow I ended up with was to write a function without any type annotations. Ignore all the red lines of the IDE’s confusion. Compile the code. In the output look for a warning about (Long => Int) return value being ignored in a function returning Unit. Copy (Long => Int) into my code as the return type annotation of my function. Compile again. That sounds like the most stupid way you could do things.
• kvtrew76557 13y ago
  Overall this is a very weak and one-sided blog post. Even a simple search would have answered his questions about why Scala doesn't use Hindley Milner type inference: http://www.scala-lang.org/old/node/4654 http://www.scala-lang.org/old/node/4654 How this post got voted up to the front page really makes me wonder. "Clojure programmer gives Scala 1 star", what next "Ruby programmer gives Python 1 star"?
  • BackerHopez 13y ago
    get over it weakling
• cryptos 13y ago
  Method names like ~, %, %% or #> are terrible in Scala! This should be generally banned as bad practice. There are too many developers creating obscure and unreadable code with such method names. I even thought to create readable adapters for common APIs like SBT API.
• deleted 13y ago
  [deleted]
• thomasfl 13y ago
  I thought HyperTalk was killed by Apple, but a quick search reveals several open source implementations of the programming language. It has been the easiest programming language to learn in my experience.
• CmonDev 13y ago
  "serious JavaScript development" - best oxymoron I have seen in a while!
• tehwalrus 13y ago
  This is wonderfully written, thank you.
• virtualwhys 13y ago
  Agreed, SBT plain sucks _without IDE support_ to guide you. If you have IDE support for your /project/*.scala SBT file(s) then the various symbols and conventions make sense as you can click through to _discover_ the library -- huge difference between that and blindly typing away in a text editor; the latter is a recipe for insanity ;-)
• auggierose 13y ago
  The Scala code I write looks very similar to the Clojure code I write. But has the advantage of (optional) static type checks. What I care about is that a language lets me express easily the concepts that are in my head. Scala does that and because of its type systems makes it even possible to document these concepts in a mechanically verifiable way (only up to a certain extent, of course).
• virtualwhys 13y ago
  Scala after 2 weeks = 1 star Scala after 2 months = 3 star Scala after 6 months = 5 star Show me a statically typed language on the JVM that trumps Scala -- it doesn't exist. Show me an ecosystem in that statically JVM based language that trumps that of Scala (Akka, Play, Slick, sqltyped, Squeryl, Spray, Scalatra, Lift, Blue Eyes, Unfiltered, etc., etc.) Yes, compile times are a hassle (for deployment that is, incremental compilation combined with sub projects are plenty fast, usually around 1-3 seconds, it's a non-issue). Yes, IDE support is nowhere near that of Java's, but it has improved immensely during the past 2 years. Either IntelliJ or Eclipse + ScalaIDE do the trick, am happy on the latter here. There are only two kinds of languages: the ones people complain about and the ones nobody uses --Bjarne Stroustrup
  • asdasf 13y ago
    I had the opposite experience. I went into scala very optimistic, and initially would have rated it 4 star to stick with your rating approach. But after a month it was down to 3, then another month it was down to 2 and we were investigating alternatives.
• CmonDev 13y ago
  "My theory is that it was designed to experiment with advanced type and language features first, and only secondly became a language intended to be widely used." - I have same feeling about F# sometimes - OCAML is cool but too academic to be approachable.
  • asdasf 13y ago
    >OCAML is cool but too academic to be approachable. Can you give an example of what you mean? I used ocaml for a few years, and never encountered anything I would consider academic at all, much less unapproachable.
• joostdevries 13y ago
  Programming languages are very much a matter of de gustibus. So I respect the writers experiences. But I have a slightly different perspective. Let me first say where I'm coming from. I like: a static typing. b support for FP and OO c targeted for JVM. Compile times It is my experience that compile times are not that bad if you use the support by SBT for continuous compile-deploy-test. Have a look at Typesafe Activator to get a feel what they're moving towards. Libraries and community I do agree that some frameworks, like Spray f.i., tend to overdo the concise DSL aspect. This seems to be especially prevalent with Scala developers coming from the academic world of monads. Or with a strong tendency to show of how clever they are to the detriment of usability. Scalaz had a strong similar tendency. I have noticed that frameworks like SBT and Scalaz are de-emphasising unpronouncable ungoogleable unintuitive operators. So far I have hope that the Scalaz community will veer away from this. To a certain degree every language community develops a culture about good vs bad code. Twitters Effective Scala guidelines are a wonderful contribution. Magic syntax I've been using the Play framework for webapplications. And in my experience that is largely a pragmatic tool where I can just get things done. My main criticism would be that sometimes new features seem to be not very well tested. F.i. multi project support did not really work for quite a few versions. That shouldn't take up much time. I hope they address that. Type inference Coming from Java I like Scalas type inference. Although the compiler feedback can sometimes still be challenging. There has been great work in compiler messages giving advice on how to fix mistakes. F.i. the well known mistake of forgetting the = between a function declaration and implementation. But there are still hairy situations. If you've ever had the infinite recursion type error (being addressed in newer version of the language) you know what I mean. Or using the json parser combinators in the Play framework with classes with one attribute f.i. Other issues he mentions: - build tools. This has significantly improved since Typesafe started. I'd say that before that Scala wasn't suitable for non academic use. There are still improvements to be made like speed, usability of SBT, maturity of the Eclipse based Scala IDE... - repetition of case classes. I have no idea what is meant with that. I think that writing a model of your domain in scala is a truy joy compared to java. And pattern matching and standard marshalling/unmarshalling to json etc is great. - the language being inaccessible and experimental. This is not my experience at all. Like any language it takes learning. But if you're looking for a language that supports both FP and OO I find it very coherent and well thought out. I'd say beautiful even. For me the coursera courses on FP with Scala and Reactive programming with Scala have been the critical power boosts in becoming proficient enough to make the transition from hobby interest language to professional everyday tool. - 'if you want true strong type systems use Haskell'. To me the 'impurity' of FP in Scala is it's strong suit. On the one hand for getting stuff done and on the other for using the vast ecosystem of JVM libraries and frameworks. Also I think that the writer will encounter quite a few inscrutable operators and overwrought type systems (like his complaint about Spray) in the world of Haskell. To finish up I'd like to state what I like about Scala: - FP in the real world of web applications and mutable state. Accessibility to colleagues who come from OO & Java - Well thought out coherent language. Especially in combination with the Coursera courses I have just become a better programmer and system engineer. - Good interoperability with Java frameworks etc - good support for horizontal scaling, near realtime processing, non-blocking processing etc ie reactive programming. Some things I have mixed feelings about: - reinventing the whole Java stack. It is true that f.i. non-blocking support has a pervasive 'disruptive' influence. But for me there's great value in mature well know libraries, server, frameworks that just work. - sometimes there are very common use cases that need quite a bit of research. F.i. it's not easy to find out what the 'canonical' way of processing xml is. - stability and documentation MMDV (=My Mileage Did Vary)
• pkolaczk 13y ago
  I agree partially with the critiques. The things I don't like in Scala: 1. Compile times. It is a problem for big projects. SBT / FSC helps quite a lot, but IMHO it is still not enough. I hope they get them much better in Scala 2.11. Also performance and correctness of the IDE plugin typechecking could be better, so I don't have to compile that often. 2. Lack of backwards binary compatibility. Source compatibility is ok, but selecting the right version of all the libraries is pretty painful, especially if the authors of the library didn't make the packages (yet) or they haven't been deployed to maven repo, etc. 3. That some elegant code constructs come with sometimes huge runtime performance penalty. It got much better recently (e.g. for loops are as fast as while loops now in Scala 2.10), but I feel it could be better. Again - hope Scala 2.11 addresses those concerns at least partially. The things I don't agree with the OP: 1. Documentation - it is awesome. 2. Syntax flexibility - many times DSL is a better way of expressing things than just a bunch of methods, and easier to learn. 3. Tooling - good enough now, and improving fast. 4. Type inference - I consider it good enough, albeit not perfect. And types in method signatures add a lot to code readability. There may be some languages that have better IDE support, faster compile times, better type inference, richer type system etc. But none of them supports full feature set of Scala, particularly all the available libraries. So IMHO taking every single feature out from Scala and comparing it let's say to Haskell or ML is ridiculous.
• edem 13y ago
  I feel you. I tried Scala out and after several days I just uninstalled everything from my computer which was related to Scala. The main reason is that it feels like some extremely baroque java without any sensible syntax. It looks like the C sytax but in fact it is not. Return types are sometimes explicit sometimes implicit. If you try to learn Scala you have to forget anything you know and learn the over-engineered ways of Scala. And in the end you don't get anything back which is not accessible in other languaes in a significantly easier way. You want functional style and easy concurrency? Go clojure. You want scalability for your webapp with 999999999 visitors per day? Go node. You want scientific calculations with good library support? Go python. You want a sensible type system and monads? Go Haskell. Scala just does not have much to offer in exchange for the terrible pile of contraptions it forces you to use.
• taude 13y ago
  As someone looking into learning a different JVM language, and who has started reading Scala in Action, I find this article and thread very useful.
• eklavya 13y ago
  I am seeing just too much criticism for Scala and the coherent theme seems to be - "I didn't take time to understand the language well and then my pride got hurt as I couldn't understand it's constructs. So Scala is shit and too complex." I am not from CS background, but I took time to learn it and by far it's THE most natural and expressive language I have found AND I don't even know what functional programming and the theory is, all I know I learned through Scala. Please guys, let's not project our laziness as a fault of Scala.
• nimbix 13y ago
  They say that for a successful c++ project you need to first define which parts of the language you're not allowed to use. For Scala projects it's even more so. And you can only hope that all the libraries you'll be using provide some sane method names that map to all the insane operators they invented to do the same thing.
  • hopp_check 13y ago
    To this point, I've heard "Scala is the C++ of Java."
• knodi 13y ago
  This is my view on scala as well. I used it for one project and will not be using it again.
• donjigweed 13y ago
  Yegge said it best 5 years ago. [1] "The... the the the... the language spec... oh, my god. I've gotta blog about this. It's, like, ninety percent [about the type system]. It's the biggest type system you've ever seen in your life, by 5x. Not by an order of magnitude, but man! There are type types, and type type types; there's complexity... They have this concept called complexity complexity<T> Meaning it's not just complexity; it's not just complexity-complexity: it's parameterized complexity-complexity. (mild laughter) OK? Whoo! I mean, this thing has types on its types on its types. It's gnarly. I've got this Ph.D. languages intern whose a big Haskell fan, and [surprisingly] a big Scheme fan, and an ML fan. [But especially Haskell.] He knows functional programming, he knows type systems. I mean, he's an expert. He looked at Scala yesterday, and he told me: "I'm finding this rather intimidating."" [1] http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.ht...
• dgeorgiev 13y ago
  A disagreeing comment wrt OP. Hope it is useful to some. On the library criticism ... Well, pick better libraries, use java libraries, or roll your own. You have twice the choice you have in java. Is that bad, or good? Yes, there is immature stuff. Well for the lawyer rate you are charging, should be able to separate that from the good bunch? The complexity - In my experience, learning curve is gradual in that you can pick new features when you need them. You can pretty much get by writing javesque scala with a bit of closures in the begining. Then take mixins, then take the hardcore stuff when you feel comfortable. About the build system - here I was surprised. You seem pragmatic, why use it? To me SBT is totally useless because it solves nothing existing tools do not solve. The Scala support in Maven is perfect, and i feel so productive and mature in it these days, I would never trade unless there is a very strong selling point (meaning more free time for me to drink beer, whatever) If you don't like Maven, code in Ant. But using a build tool which is a general-purpose language? I agree with you. Baaaaad idea
• vpatryshev 13y ago
  So, you switched to which language exactly? Sure we can follow a good example.
• ARussell 13y ago
  I think that many of these criticisms, while perhaps valid in some ways, are unfair. Why single out Scala, when other, more popular languages have these same issues? The intent of this post seems to be to discourage using Scala on any project again, but it is difficult for me to discern the proposed alternative. Is it Haskell? A fine language, but seems to lack the tools that even Scala has, and it's not on the JVM. Is it JavaScript? Java? I'm not sure which comparisons to make. So to address each point: The compile times criticism is probably one of the more valid ones. Was incremental compilation enabled in Gradle, though? It was only specified that daemon mode was used. The libraries and community criticism, I think, is completely unfair. There are lemons in every community. Part of getting to know an ecosystem is learning the parts you don't like. For example, I don't think that anyone should attack the entire Java ecosystem simply because Java EE with its EJBs exists, or because Struts exists, or WebSphere. Is the magic syntax criticism specific to Spray and SBT? But I thought that Gradle was the build system, and that's in Groovy. I'm a bit confused, here. Again I think this is about picking libraries you find readable, and again I think it is not fair to judge an entire ecosystem because of one or two bad library choices. The HTTP header criticism...is this about Spray again? Not using Scala because it doesn't have Hindley-Milner type inference is not fair, either. This seems like an unusual standard for which to hold any language, really. Is it only ML languages like Haskell that have this? Really I'm not sure why any or all of these would make Scala an inaccessible language, or even what inaccessible means in this context. Is it simply that Scala has too many language features? So should we all go back to BASIC? Or is Java the answer? But wait, Java is adding more language features, too! Where do we draw the line? In the Java world, there are so many libraries that provide the functionality that Scala has baked in. Are using third-party libraries such as Guava, Project Lombok, and LambdaJ really preferable to using Scala? I definitely agree that you can make code unreadable by using too many language features or libraries, but it should be agreed upon what the best practices are for a project between its developers. For instance, on a Java project, everyone might be using JUnit and Mockito for unit testing. Then one day, a single developer decides he wants to introduce PowerMock or something, instead. His pairing partner could explain to him why this is a bad idea; or it could be rejected in a code review or similar. The same idea holds for Scala, I think. If not everyone understands something like implicit types, they should be avoided.
• geoka9 13y ago
  Having used Scala for over a year, I can say it is a mixed blessing for me. On the one hand it's an improvement over the verbosity and rigidity of Java. And often it is fun to write in (lots of clever tricks you can use and feel good about... until you have to come back to the code several months later). On the other hand, I absolutely hate to dig into Scala code written by others. To me it feels like C++ all over again. There are so many concepts in the language that more often than not you find your knowledge of the language lacking, and have to put the task at hand on hold to brush up on your Scala skills. If there are more than a couple of (Scala loving) codevelopers on the project, you end up spending more time learning about the language than actually using it. So, to sum it up: I would use Scala if I absolutely had to use JVM and I had control over the the subset of the language used in the codebase. Otherwise, I'd pick something else. Thankfully, there are saner alternatives to JVM these days when it comes to high level/static typing/high performance (e.g. Go).
• dancapo 13y ago
  There's a lot that could be criticized about Scala, but that article is a criticism of the author, for me who actually knows something about Scala. It starts with a criticism of a build system that is most likely SBT. Now, for all its strengths, you could not pick an easier target than SBT if you wanted to bad mouth a piece of Scala software, but what we get is: * It is slow to recompile the build definition (true, not the most complex build files I ever saw ever took anywhere near that time); * I didn't bother to learn the syntax (or what was going on). Is that it? If all you have to complain about SBT is this, then you never actually made even a passing attempt to learn to use it. That doesn't make me much confident about the author... Next, the author has been writing Scala code for the past two weeks. Scala is not, I argue, as complex as people make it to be, but it has enough different concepts than what most other languages offer that you simply don't pick it up in two weeks, just like you didn't learn your first programming language in two weeks. If you come from Java, two weeks of Scala let you use Scala like Java: you'll produce working software, though not in any idiomatic style. Well, we pick later on that the team is using Spray, and Spray is a very idiomatic library. You do have to unlearn many habits to pick it up, and the author doesn't seem interested in unlearning anything he "knows". He picks Scala because, hey, there were doing XSL and doing XML processing, so Scala must be good at it, right? Well, actually, no, but I can see why one would think that, and also why one would be disappointed that it actually isn't, but picking the wrong tool doesn't mean the tool is bad: it's just not the tool for that. So we go to TDD, where he comes up on Scala awful compile times (which troubled him with SBT before). That is a problem that Scala community has faced, and it has produced solutions to that problem. Specifically, it has adopted SBT, a build tool which can compile incrementally (and automatically on change), and even execute just the tests that are affected by a change (automatically as well). Of course, the author, having chosen Scala, decides to ignore the existing solutions and picks up Gradle, which supports none of this. Now, Gradle is a very nice build system, but, again, the author picks the wrong tool and proceeds to blame the wrong thing from it. Next, the author proceeds to have problems with libraries -- problems somehow not shared with the rest of the community (see comments by other Scala users). He mentioned stability problems, and then mentions two pieces of software with excellent documentation, extremely stable, and supported across a broad range of versions of their dependencies. Now, choosing Spray when you are not familiar with Scala was a terrible decision, and I can well see where the author had trouble using it -- while not agreeing there's any problem with Spray itself. Having trouble with Specs2, however, makes me seriously doubt his abilities -- if he truly had trouble with it. Next he proceeds to some discussion of simplicity, and I'd grant that Scala is not simple. However, he ties that to a lack of regularity, which is interesting in that Scala is highly regular, much more so than Ruby. It just allow different things than the languages he is used to, so it looks different. I can buy "looks different" -- yes, it does. But the author's inability to realize how regular it is just goes to show that he has a very, very poor knowledge of Scala. That's not a problem with Scala, it's just that he didn't learn Scala, and it keeps showing. So, having not learned Scala, he tries to accomplish something that required a specific Scala knowledge he lacked and fails. And somehow that's Scala's fault and Spray's fault, not his. Well, I admit it: if you don't learn Scala, it is very difficult to program in Scala. That's certainly not the case with PHP, for example, but I have certainly struggled with rather simple tasks in Ruby when trying to write code in Ruby without learning it. I just never blamed Ruby for it. Next, "everything is a type". I disagree that this is in any way a problem -- if you are going to complain about that, how about just writing "Scala is a statically typed language" and leave it at that? We all knew that, didn't we? So, having chosen a statically typed language, he dislikes the fact that it actually tries to use types? Weird, but at least he doesn't make it a problem of Scala itself. On the other hand, it took me thirty seconds to find RawHeader, which allows arbitrary headers, which indeed would be a weird thing to be missing. It's right there, among the other headers. Among, say, Origin and either Access-Control-* headers, which happen to be the CORS headers, all of which appear in the API docs, so what gives? Maybe they are new headers? Well, the CORS headers are new, if not that new, but maybe the article refers to something that happened months ago. The raw header is there for quite a while, as you can see for yourself here: https://github.com/spray/spray/blame/master/spray-http/src/main/scala/spray/http/HttpHeader.scala https://github.com/spray/spray/blame/master/spray-http/src/m... At this point, I don't even know where the author is coming from, that he failed to spot this. It is certainly not Spray's fault, much less Scala's. Next comes a rant on lack of H-M type inference. Well, we all would have liked to have more type inference (without making the compiler even slower!), but separate compilation, subtyping and full type inference is not a solved problem. Which doesn't mean we can't gripe about it. But there's a damning comment among it: the error message he describes in his "workflow". Hey, Scala infers the return type, so he doesn't need to add it, unless he's doing recursion of calling overloaded methods. If he were doing that, however, the error message would be different. What the error message says, however, is that he is using procedure syntax -- that is, a method returning void in C/Java parlance -- when he actually intended the method to return something. He doesn't need to add the type, he just needs to use the correct declaration: def method() { body } // procedure (unit-returning method) def method() = expr // function He spent two weeks programming in Scala, then went on to write a blog about it, but he still hasn't figured out a simple detail like this, despite the compiler telling him what the problem is? Yes, beginners might well struggle with this oddity, but for two weeks??? And despite having fixed it throughtout the program? Really? Now, detour briefly through long vs int, which I actually agree with, but saying he was "reminded" of it shows a complete lack of familiarity with statically typed languages. Again, fine that you don't like statically typed languages, though I think one ought to first learn one of them before criticizing, but you could start and end your post with "I don't like statically typed languages". Then there are other issues which he enumerates but don't describe, and which I can only disagree with. Horrible repetition required by case classes? Err, what repetition? So, in the end, it seems that what the author really wanted to say is: I don't like statically typed languages, and I tried to use one for the wrong reasons, in the wrong way, without learning it, and failed. No need to blame Scala for his bad decisions.
• jongraehl 13y ago
  Horribly misinformed. Author didn't learn basics of the language - "val" vs "def" is very fundamental - constant vs. function. Scala does not use Hindley-Milner. Legit issues: compile time (of course), library docs (maybe), bad HTTP header API (maybe), tooling (maybe). I thought the automatically generated (doxygen style) library docs were fine when I was playing with Scala two years ago.
• AKarimi 13y ago
  It's a little late to talk about Scala like that. There are very nice improvements on each of those topics you complain about. Of course still there are many works to do but for now there is no other language with such potential IMO.