16 ms·

Scala – 1 Star Would Not Program Again

83 points by theotown 13y ago

michaelwww 13y ago
The Co-Founder of Typesafe, Paul Phillips, hates Scala too. Working on the compiler seems to have driven him mad (he says this, not me, but I don't disagree based on this performance.) http://parleys.com/play/528cbfc3e4b084eb60ac78f2/about http://parleys.com/play/528cbfc3e4b084eb60ac78f2/about
- johnmurray_io 13y ago
  He also claims at the end that he's going to keep using Scala on his new venture because it's the best tool he has, at the moment.
  - michaelwww 13y ago
    There's some dispute over who said "the definition of insanity is to keep doing the same thing over and over again expecting different results."
    - johnmurray_io 13y ago
      He may be a bit interesting, but based on your assumption that he "hates" Scala seems to indicate that he is a very angry person (given that he still prefers Scala to other alternatives). I think he is emotionally invested in Scala and upset that it didn't turn out exactly how he would have like to see it, but "hate" seems like a strong (possibly incorrect) word to use.
      - michaelwww 13y ago
        I agree, hate is too strong a word. I was reacting to his very emotional presentation. I could feel his pain.
- lmm 13y ago
  This is proper constructive criticism. The presentation is terrible, but everything he says is right. Including the part where Scala is still the best tool available today, even though it could be so much better than it is.
- melling 13y ago
  He says you need to be a "rocket scientist" to change the compiler. We have computers that are thousands of times faster than the 1980's but Turbo Pascal, then, could compile tens of thousands of lines per second on that hardware. Scala is so complicated it takes minutes to compile large code bases. Anyone remember what the claims were for Turbo Pascal? http://en.wikipedia.org/wiki/Turbo_Pascal http://en.wikipedia.org/wiki/Turbo_Pascal
  - Mikeb85 13y ago
    They need to take a lesson from the OCaml or Haxe devs. Both have blazing fast compilers that create efficient code for every platform known to man... And both are very feature-rich languages.
    - yapcguy 13y ago
      He says the Scala compiler will never be fast...
  - pjmlp 13y ago
    > Anyone remember what the claims were for Turbo Pascal? According to Embarcadero Turbo Pascal memorial page, Turbo Pascal 5.5 was compiling 34,000 lines/minute! http://edn.embarcadero.com/article/20803 http://edn.embarcadero.com/article/20803 Having been introduced to Turbo Pascal line of compilers, spoiled my expectations in regard to C and C++ when I got to learn them afterwards. :)
- jfager 13y ago
  Him switching from being neck-deep in compiler issues to actually using the language in anger on whatever it is he's doing now might end up being really good for the language. His twitter stream has started filling up with wtf's and really good bug reports.
- yapcguy 13y ago
  It does look like he's about to have a breakdown. Hopefully giving the talk was cathartic and helped him relieve his frustrations.
- agentultra 13y ago
  Much of what he desires out of his ideal programming environment sounds eerily like CL or SmallTalk (though possibly closer to CL). The textual representation of CL code IS the AST. You can change it to be whatever you want. You can programmatically manipulate the code objects represented by that tree using the same forms and idioms you use on plain old data. There's very little magic that happens "under the hood." I can't even imagine how awesome the CL ecosystem could be with someone like Paul on its side. sigh I've been putting in some time to learn Scala but he elucidates much of what bugs me about the language in this talk. I'm hoping to see a, "Good Parts" book but I'm not sure if that's a good sign.
- joeblau 13y ago
  Interesting talk. A lot of things he's talking about are just general good programming practices.
yummyfajitas 13y ago
Blogspam, original is here: http://overwatering.org/blog/2013/12/scala-1-star-would-not-program-again/ http://overwatering.org/blog/2013/12/scala-1-star-would-not-... Some thoughts: I've worked on several large scala projects, and I've found that long incremental compile times are often a sign of bad encapsulation. If you change the type signature of a public method then any file using that class needs to be recompiled. I've found that explicit type annotations on method return types help a lot here: def getBandit(ref: BanditRef)= { ... ConcreteSimpleBandit(...) } This has type `BanditRef => ConcreteSimpleBandit`. If I change the implementation and return a ConcreteNonSimpleBandit, the inferred type signature changes to `BanditRef => ConcreteNonSimpleBandit`. If I use an if-statement and return one or the other, the return type will be the nearest superclass of both (say a ConcreteBandit). However, if I explicitly annotate it to return a BanditLike def getBandit(ref: BanditRef): BanditLike = { ... ConcreteSimpleBandit(...) } then only the class in question needs to be recompiled. The author is spot on about the use of infix methods. These are nearly always evil. What would be great if Scala gave you a way to explicitly declare certain functions as infix, and everything else uses the java-style calling convention. For a monoid, a |+| b |+| c makes perfect sense. However, consider: optionalResult map (x => x*x) filter (_ % 2 == 1) getOrElse -1 Yeah, you need to do work to figure out what's going on. Compare to: optionalResult.map(x => x*x).filter(_ % 2 == 1).getOrElse(-1) But I suppose the former will save some bits ('.' and '(' take more bytes than ' ', right?).
- ryanobjc 13y ago
  This comment reminded me of a book called "Large Scale C++ Software Design" which is essentially about techniques to speed up your build time. My short handed criticism about Scala is this: It's the C++ of the JVM. Specifically it has many features of C++ we thought we left behind: - slow compile times - complex language features and syntax The language features have a benefit, and a cost. I just personally believe the cost outweighs the benefits for me.
  - bad_user 13y ago
    Having worked with both Scala and C++, I actually think that people saying this don't know what they are talking about. I encourage you to take another look, as we often jump to criticisms with only a superficial understanding, often based on comments made on forums by other people. In particular, the idea of writing the code in a certain way to avoid recompilation is rather silly and I never, ever did it in the last 2 years since I worked with Scala. On syntax and complex language features - having trained rookies unfamiliar with Scala myself, I can tell you - it's neither the syntax or the language features that are problematic, but rather the concepts involved. The Scala ecosystem is chock-full of paradigms coming from static FP languages such as Haskell. Scala's features are actually very elegant and orthogonal. It does have ugly corners that are a result of its interoperability with its host, the JVM, but that's a tradeoff I like, because people that don't like the JVM, haven't seen what it can do. On compilation speed, it's not much of a problem though I understand why people don't like it. But the type system is very static - and in comparison with Java in which the type system does nothing else but to stay in your way - in Scala it actually helps you to write code that is sometimes provably correct or to design safe and user-friendly APIs. For me it's not a problem if my code takes an extra couple of seconds to compile, because the compiler does help me in the case of Scala. In terms of recent developments, both SBT and Maven are doing incremental compilation. Plus, SBT makes it really, really easy to break your project into multiple sub-projects that depend on each other, to keep them small, something which helps with compilation speed though personally I do it for keeping the code base cleaner.
adricnet 13y ago
I somehow misread this as Scalia (Supreme Court Justice) and thought this was about one of the recent announcements from SCOTUS...
- kleiba 13y ago
  This means you're browsing the wrong site.
  - adricnet 13y ago
    I'm not making an argument about that but there were two or three SCOTUS stories on the frontpage of HN today. Taking my downvotes and moving on, I am.
blakesmith 13y ago
More of these "This language sucks" blog posts need to focus on the problem domains actually being solved and less on the aesthetics of the tools. My team uses Scala as one of our primary backend languages and have been extremely productive with it. We're building large distributed systems that store and manage large quantities of sensor data and push Scala pretty hard. Are there warts? Yes, just as with any other tool. But the important part is that we create value quickly for our customers, and Scala has fit our problem domain quite well. I've also seen too many consultants who get caught up in technology for its own sake, because that's what many of them sell (We use this new development methodology, with this hot new framework, hire us!). Let's all spend less time worrying about what tools we're using and more time worrying about whether we're solving the right problems.
mortyseinfeld 13y ago
With Scala you feel smart having just got something to work in a beautiful way but when you look around the room to tell your clojure colleague how clever you are, you notice he left 3 hours ago and there is a post-it saying use a Map So he was making reference to Clojure here. That's fine, but you don't have to make things complicated in Scala if you don't want to. I love the semantics of Clojure, but until you get some optional typing and possibly another syntax baked in forget about it for a whole class of devs.
- lkrubner 13y ago
  About this: "until you get some optional typing" There is work being done on an optional type system: https://github.com/clojure/core.typed https://github.com/clojure/core.typed There are also some interesting experiments in enforcing specific data structures: https://github.com/prismatic/schema https://github.com/prismatic/schema Much effort has been made to make contract programming easy in Clojure: https://github.com/clojure/core.contracts https://github.com/clojure/core.contracts And if you would feel the urge to respond with something like "why is such important functionality in a library", I'll point out enforcing pre and post conditions (on a function) has a nice syntax that is part of the language: http://blog.fogus.me/2009/12/21/clojures-pre-and-post/ http://blog.fogus.me/2009/12/21/clojures-pre-and-post/ I find that every time I read an article about Scala I am left wondering "Why don't these people just use Clojure?"
  - michaelochurch 13y ago
    This is why I'm really happy with the Clojure community. People in Clojure get that types are useful and important. You don't have the "I don't understand that, so I'm going to call it unimportant" attitude. Instead, you have people using Clojure as a lens to explore and, one hopes, solve the problem-- even when it seems so difficult as to be almost infeasible (such as static typing on a Lisp). Clojure is a dynamically typed, JVM language-- now. (However, ClojureScript is also pretty far along.) It might not always be that way. It will evolve according to the needs of computer science over the next 20+ years.
    - 13y ago
talles 13y ago
thats a creative title
Pxtl 13y ago
I think the key-value pairs vs typed objects for something like an HTTP header is a holy war we'll never hear the end of.
quantumpotato_ 13y ago
I'm learning Scala (coursera, twitter) to write game servers that can handle lots of request simultaneously. What's another good language for this? So far, Scala seems rather powerful.
- ivanplenty 13y ago
  I love Scala as a language and would encourage you to learn it on the way to becoming a more rounded programmer. It does have its warts, and compile times kill me. On HN the two common recommendations are: * Go * Node.JS (with Promises while we wait for generators!) I personally use node for large-scale stuff since more people know JS, but a lot of this comes down to personal preference.
  - quantumpotato_ 13y ago
    Thank you for your response. Node seems promising (it's not techncially multi-threaded though?) I wrote a little command-line RPS game playable over a local network in node: https://github.com/quantumpotato/node-rps https://github.com/quantumpotato/node-rps Didn't realize Go was good for many-connections, will have to check that out. TY
    - nickik 13y ago
      Node only runs on one core, you can start it more then once. This only works if the request well don't have to coordinate over the hole address space. You need to care all the shared state in a database, witch you don't really want to do. Go, is pretty good for that and it helps to think about it. You can start on thread of control per request, like with Scala where you might start one actor per request but the difference is that you have first class channels to communicate. Witch is pretty powerful. One the JVM you can do this CSP style where well with Clojure (https://github.com/clojure/core.async https://github.com/clojure/core.async). Interesting video why CSP is best: > http://www.infoq.com/presentations/clojure-core-async http://www.infoq.com/presentations/clojure-core-async
  - nickik 13y ago
tenpoundhammer 13y ago
I have written Scala on several large projects( and Play framework) One of the problems with Scala is that there are a thousand ways to do everything, which is often insanely confusing to a lot of people. And another I think is that people try to teach scala like they teach other OO languages and it just doesn't work. Scala is not that hard once you boil it down the set of features that your team wants to use. After learning Scala and then teaching it to several java developers, I believe I could get someone productive in Scala in 5-10 hours. There are a couple of cognitive hurdles, and a few difficult to implement features in the super deep realm of coding, but it's really not that hard.
- hackerboos 13y ago
  >I believe I could get someone productive in Scala in 5-10 hours. Write an book on leanpub. You'll make a fortune...
  - tenpoundhammer 13y ago
    I don't think I could do it with a book. I think I could do it with a combination of lecture, exercises, and a little Q&A. At least that has worked in the past.
- kodablah 13y ago
  I agree that it's hard to trim down the feature set you want a team to use, but for individual development it is really nice. I like building a solution to my problem and whittling it down to clear and concise code. The resulting can be information dense if you let it, but I like it. I find myself spending lots of time reading Akka and Spray docs just to output a few characters. I can understand why highly volatile software can be tough in Scala. But I appreciate the concept of expending a lot of thought on a minimal amount code that is easy to read.
  - tenpoundhammer 13y ago
    I love me some matchers with cases and gaurds. You can make some normally gnarly looking and hard to read decision trees into really concise easy to read cases.
farginay 13y ago
This post reinforces my sense that Scala is the new C++.
lemmsjid 13y ago
It's sad that this particular blog post is getting double the attention because it's not a strong critique of Scala, which, like any good technology, is imminently critique-able. The extant HN thread got much more interesting Scala critiques than the blog post: https://news.ycombinator.com/item?id=6829725 https://news.ycombinator.com/item?id=6829725 That said, I would add the following meta-commentary, which has nothing to do with Scala in particular: Don't be scared away from Scala by the negativity. In fact, use said commentary as evidence that Scala has hit a maturity point that makes it worth exploring. When Rails first could come out, it could do no wrong, and I would get regular queries from less experienced techies as to why we weren't rewriting our code to use Rails, as though the hype made it a given that any web application should be in Rails from now on. Now that Rails is more mature, it gets regular negative articles. Using negativity around a mature technology has some underlying theme that is valid (performance for Rails, overly complex libraries for Scala), but not something that would or should scare someone away if they are eyes-open assessing the needs of their final product against the capabilities of the technology. Really, we are in the infancy of software development. All languages are incredibly oblique to their runtime environments, especially in distributed scenarios. Any language that gets little but praise is simply not sufficiently understood by enough people to be critiqued, or for said critiques to get up-voted on news sites. I am not, by the way, arguing that all languages are therefore equal in quality. What I am arguing against is this: often when there's a vote-up negative article about technology X, there's people who respond, "Aww shucks, I was about to use X for my next project, what should I use instead?" And the responses are, "Well, use Y instead", where Y is currently on the zenith of its hype machine. This is a bad strategy for assessing technology, because it's simply inevitable that Y will eventually receive a hailstorm of similarly valid critiques. Consider it a given that any technology in use today will look stodgy in forty years. Instead, use the existence of critiques as a marker that a language is fairly well known and mature. It's rather like the appropriate way to use Yelp reviews: assume most of them are fake, assume nothing but positivity or negativity is wrong, and instead look for volume and breadth of tone.
icedchai 13y ago
I was at a job where I programmed in Scala for about 6 months. This was almost 3 years ago: immature tools (awful IDE support), slow compilers, long build times (this was partially due to Maven project with literally 50+ modules and too many unit tests), and inexperienced developers. Scala is too complicated a language. I'm sure it's a little better now... but, it's not for me.
frowaway001 13y ago
I also work in the same company as the poster. We are currently running a huge Scala/Play project where the team is a mix of many young developers (< 5 yrs) and a few seniors. Overall it is a very pleasant experience. There are multiple other projects using Scala which share this positive feeling. It is difficult to explain these reactions, but they are common among my colleagues. These are senior programmers who are generally very good with any programming language/task. They will pickup something new and be productive in just a few days. They usually end up liking Ruby, Javascript, Clojure and for good reasons. Scala on the other hand requires a lot of attention and work to get mastery. One can get started in days but to exploit the real power and appreciate design choices takes months if not years. In my opinion this is an important factor why these smart developers react so badly to Scala which for them is just another tool which takes too much time to grasp. There is little Scala can do. Maybe it should become less ambitious. No macros, no compiler plugins, do not challenge FP etc. But then it will not be the Scala we all loved :) Also, it is important to note the blog post does not criticise Scala in isolation. It used Spray DSL for routes and Gradle as a build tool, maybe that particular combination increases the pain. https://groups.google.com/d/msg/scala-internals/153H3Ya4Nxk/AngkiUE7VUIJ https://groups.google.com/d/msg/scala-internals/153H3Ya4Nxk/...

83 points by theotown 13y ago

The Co-Founder of Typesafe, Paul Phillips, hates Scala too. Working on the compiler seems to have driven him mad (he says this, not me, but I don't disagree based on this performance.) http://parleys.com/play/528cbfc3e4b084eb60ac78f2/about http://parleys.com/play/528cbfc3e4b084eb60ac78f2/about

johnmurray_io 13y ago
He also claims at the end that he's going to keep using Scala on his new venture because it's the best tool he has, at the moment.
- michaelwww 13y ago
  There's some dispute over who said "the definition of insanity is to keep doing the same thing over and over again expecting different results."
  - johnmurray_io 13y ago
    He may be a bit interesting, but based on your assumption that he "hates" Scala seems to indicate that he is a very angry person (given that he still prefers Scala to other alternatives). I think he is emotionally invested in Scala and upset that it didn't turn out exactly how he would have like to see it, but "hate" seems like a strong (possibly incorrect) word to use.
    - michaelwww 13y ago
      I agree, hate is too strong a word. I was reacting to his very emotional presentation. I could feel his pain.
lmm 13y ago
This is proper constructive criticism. The presentation is terrible, but everything he says is right. Including the part where Scala is still the best tool available today, even though it could be so much better than it is.
melling 13y ago
He says you need to be a "rocket scientist" to change the compiler. We have computers that are thousands of times faster than the 1980's but Turbo Pascal, then, could compile tens of thousands of lines per second on that hardware. Scala is so complicated it takes minutes to compile large code bases. Anyone remember what the claims were for Turbo Pascal? http://en.wikipedia.org/wiki/Turbo_Pascal http://en.wikipedia.org/wiki/Turbo_Pascal
- Mikeb85 13y ago
  They need to take a lesson from the OCaml or Haxe devs. Both have blazing fast compilers that create efficient code for every platform known to man... And both are very feature-rich languages.
  - yapcguy 13y ago
    He says the Scala compiler will never be fast...
- pjmlp 13y ago
  > Anyone remember what the claims were for Turbo Pascal? According to Embarcadero Turbo Pascal memorial page, Turbo Pascal 5.5 was compiling 34,000 lines/minute! http://edn.embarcadero.com/article/20803 http://edn.embarcadero.com/article/20803 Having been introduced to Turbo Pascal line of compilers, spoiled my expectations in regard to C and C++ when I got to learn them afterwards. :)
jfager 13y ago
Him switching from being neck-deep in compiler issues to actually using the language in anger on whatever it is he's doing now might end up being really good for the language. His twitter stream has started filling up with wtf's and really good bug reports.
yapcguy 13y ago
It does look like he's about to have a breakdown. Hopefully giving the talk was cathartic and helped him relieve his frustrations.
agentultra 13y ago
Much of what he desires out of his ideal programming environment sounds eerily like CL or SmallTalk (though possibly closer to CL). The textual representation of CL code IS the AST. You can change it to be whatever you want. You can programmatically manipulate the code objects represented by that tree using the same forms and idioms you use on plain old data. There's very little magic that happens "under the hood." I can't even imagine how awesome the CL ecosystem could be with someone like Paul on its side. sigh I've been putting in some time to learn Scala but he elucidates much of what bugs me about the language in this talk. I'm hoping to see a, "Good Parts" book but I'm not sure if that's a good sign.
joeblau 13y ago
Interesting talk. A lot of things he's talking about are just general good programming practices.

yummyfajitas 13y ago

Blogspam, original is here: http://overwatering.org/blog/2013/12/scala-1-star-would-not-program-again/ http://overwatering.org/blog/2013/12/scala-1-star-would-not-... Some thoughts: I've worked on several large scala projects, and I've found that long incremental compile times are often a sign of bad encapsulation. If you change the type signature of a public method then any file using that class needs to be recompiled. I've found that explicit type annotations on method return types help a lot here: def getBandit(ref: BanditRef)= { ... ConcreteSimpleBandit(...) } This has type `BanditRef => ConcreteSimpleBandit`. If I change the implementation and return a ConcreteNonSimpleBandit, the inferred type signature changes to `BanditRef => ConcreteNonSimpleBandit`. If I use an if-statement and return one or the other, the return type will be the nearest superclass of both (say a ConcreteBandit). However, if I explicitly annotate it to return a BanditLike def getBandit(ref: BanditRef): BanditLike = { ... ConcreteSimpleBandit(...) } then only the class in question needs to be recompiled. The author is spot on about the use of infix methods. These are nearly always evil. What would be great if Scala gave you a way to explicitly declare certain functions as infix, and everything else uses the java-style calling convention. For a monoid, a |+| b |+| c makes perfect sense. However, consider: optionalResult map (x => x*x) filter (_ % 2 == 1) getOrElse -1 Yeah, you need to do work to figure out what's going on. Compare to: optionalResult.map(x => x*x).filter(_ % 2 == 1).getOrElse(-1) But I suppose the former will save some bits ('.' and '(' take more bytes than ' ', right?).

ryanobjc 13y ago
This comment reminded me of a book called "Large Scale C++ Software Design" which is essentially about techniques to speed up your build time. My short handed criticism about Scala is this: It's the C++ of the JVM. Specifically it has many features of C++ we thought we left behind: - slow compile times - complex language features and syntax The language features have a benefit, and a cost. I just personally believe the cost outweighs the benefits for me.
- bad_user 13y ago
  Having worked with both Scala and C++, I actually think that people saying this don't know what they are talking about. I encourage you to take another look, as we often jump to criticisms with only a superficial understanding, often based on comments made on forums by other people. In particular, the idea of writing the code in a certain way to avoid recompilation is rather silly and I never, ever did it in the last 2 years since I worked with Scala. On syntax and complex language features - having trained rookies unfamiliar with Scala myself, I can tell you - it's neither the syntax or the language features that are problematic, but rather the concepts involved. The Scala ecosystem is chock-full of paradigms coming from static FP languages such as Haskell. Scala's features are actually very elegant and orthogonal. It does have ugly corners that are a result of its interoperability with its host, the JVM, but that's a tradeoff I like, because people that don't like the JVM, haven't seen what it can do. On compilation speed, it's not much of a problem though I understand why people don't like it. But the type system is very static - and in comparison with Java in which the type system does nothing else but to stay in your way - in Scala it actually helps you to write code that is sometimes provably correct or to design safe and user-friendly APIs. For me it's not a problem if my code takes an extra couple of seconds to compile, because the compiler does help me in the case of Scala. In terms of recent developments, both SBT and Maven are doing incremental compilation. Plus, SBT makes it really, really easy to break your project into multiple sub-projects that depend on each other, to keep them small, something which helps with compilation speed though personally I do it for keeping the code base cleaner.

adricnet 13y ago

I somehow misread this as Scalia (Supreme Court Justice) and thought this was about one of the recent announcements from SCOTUS...

kleiba 13y ago
This means you're browsing the wrong site.
- adricnet 13y ago
  I'm not making an argument about that but there were two or three SCOTUS stories on the frontpage of HN today. Taking my downvotes and moving on, I am.

blakesmith 13y ago

More of these "This language sucks" blog posts need to focus on the problem domains actually being solved and less on the aesthetics of the tools. My team uses Scala as one of our primary backend languages and have been extremely productive with it. We're building large distributed systems that store and manage large quantities of sensor data and push Scala pretty hard. Are there warts? Yes, just as with any other tool. But the important part is that we create value quickly for our customers, and Scala has fit our problem domain quite well. I've also seen too many consultants who get caught up in technology for its own sake, because that's what many of them sell (We use this new development methodology, with this hot new framework, hire us!). Let's all spend less time worrying about what tools we're using and more time worrying about whether we're solving the right problems.

mortyseinfeld 13y ago

With Scala you feel smart having just got something to work in a beautiful way but when you look around the room to tell your clojure colleague how clever you are, you notice he left 3 hours ago and there is a post-it saying use a Map So he was making reference to Clojure here. That's fine, but you don't have to make things complicated in Scala if you don't want to. I love the semantics of Clojure, but until you get some optional typing and possibly another syntax baked in forget about it for a whole class of devs.

lkrubner 13y ago
About this: "until you get some optional typing" There is work being done on an optional type system: https://github.com/clojure/core.typed https://github.com/clojure/core.typed There are also some interesting experiments in enforcing specific data structures: https://github.com/prismatic/schema https://github.com/prismatic/schema Much effort has been made to make contract programming easy in Clojure: https://github.com/clojure/core.contracts https://github.com/clojure/core.contracts And if you would feel the urge to respond with something like "why is such important functionality in a library", I'll point out enforcing pre and post conditions (on a function) has a nice syntax that is part of the language: http://blog.fogus.me/2009/12/21/clojures-pre-and-post/ http://blog.fogus.me/2009/12/21/clojures-pre-and-post/ I find that every time I read an article about Scala I am left wondering "Why don't these people just use Clojure?"
- michaelochurch 13y ago
  This is why I'm really happy with the Clojure community. People in Clojure get that types are useful and important. You don't have the "I don't understand that, so I'm going to call it unimportant" attitude. Instead, you have people using Clojure as a lens to explore and, one hopes, solve the problem-- even when it seems so difficult as to be almost infeasible (such as static typing on a Lisp). Clojure is a dynamically typed, JVM language-- now. (However, ClojureScript is also pretty far along.) It might not always be that way. It will evolve according to the needs of computer science over the next 20+ years.
  - 13y ago

talles 13y ago

thats a creative title

Pxtl 13y ago

I think the key-value pairs vs typed objects for something like an HTTP header is a holy war we'll never hear the end of.

quantumpotato_ 13y ago

I'm learning Scala (coursera, twitter) to write game servers that can handle lots of request simultaneously. What's another good language for this? So far, Scala seems rather powerful.

ivanplenty 13y ago
I love Scala as a language and would encourage you to learn it on the way to becoming a more rounded programmer. It does have its warts, and compile times kill me. On HN the two common recommendations are: * Go * Node.JS (with Promises while we wait for generators!) I personally use node for large-scale stuff since more people know JS, but a lot of this comes down to personal preference.
- quantumpotato_ 13y ago
  Thank you for your response. Node seems promising (it's not techncially multi-threaded though?) I wrote a little command-line RPS game playable over a local network in node: https://github.com/quantumpotato/node-rps https://github.com/quantumpotato/node-rps Didn't realize Go was good for many-connections, will have to check that out. TY
  - nickik 13y ago
    Node only runs on one core, you can start it more then once. This only works if the request well don't have to coordinate over the hole address space. You need to care all the shared state in a database, witch you don't really want to do. Go, is pretty good for that and it helps to think about it. You can start on thread of control per request, like with Scala where you might start one actor per request but the difference is that you have first class channels to communicate. Witch is pretty powerful. One the JVM you can do this CSP style where well with Clojure (https://github.com/clojure/core.async https://github.com/clojure/core.async). Interesting video why CSP is best: > http://www.infoq.com/presentations/clojure-core-async http://www.infoq.com/presentations/clojure-core-async
- nickik 13y ago

tenpoundhammer 13y ago

I have written Scala on several large projects( and Play framework) One of the problems with Scala is that there are a thousand ways to do everything, which is often insanely confusing to a lot of people. And another I think is that people try to teach scala like they teach other OO languages and it just doesn't work. Scala is not that hard once you boil it down the set of features that your team wants to use. After learning Scala and then teaching it to several java developers, I believe I could get someone productive in Scala in 5-10 hours. There are a couple of cognitive hurdles, and a few difficult to implement features in the super deep realm of coding, but it's really not that hard.

hackerboos 13y ago
>I believe I could get someone productive in Scala in 5-10 hours. Write an book on leanpub. You'll make a fortune...
- tenpoundhammer 13y ago
  I don't think I could do it with a book. I think I could do it with a combination of lecture, exercises, and a little Q&A. At least that has worked in the past.
kodablah 13y ago
I agree that it's hard to trim down the feature set you want a team to use, but for individual development it is really nice. I like building a solution to my problem and whittling it down to clear and concise code. The resulting can be information dense if you let it, but I like it. I find myself spending lots of time reading Akka and Spray docs just to output a few characters. I can understand why highly volatile software can be tough in Scala. But I appreciate the concept of expending a lot of thought on a minimal amount code that is easy to read.
- tenpoundhammer 13y ago
  I love me some matchers with cases and gaurds. You can make some normally gnarly looking and hard to read decision trees into really concise easy to read cases.

farginay 13y ago

This post reinforces my sense that Scala is the new C++.

lemmsjid 13y ago

It's sad that this particular blog post is getting double the attention because it's not a strong critique of Scala, which, like any good technology, is imminently critique-able. The extant HN thread got much more interesting Scala critiques than the blog post: https://news.ycombinator.com/item?id=6829725 https://news.ycombinator.com/item?id=6829725 That said, I would add the following meta-commentary, which has nothing to do with Scala in particular: Don't be scared away from Scala by the negativity. In fact, use said commentary as evidence that Scala has hit a maturity point that makes it worth exploring. When Rails first could come out, it could do no wrong, and I would get regular queries from less experienced techies as to why we weren't rewriting our code to use Rails, as though the hype made it a given that any web application should be in Rails from now on. Now that Rails is more mature, it gets regular negative articles. Using negativity around a mature technology has some underlying theme that is valid (performance for Rails, overly complex libraries for Scala), but not something that would or should scare someone away if they are eyes-open assessing the needs of their final product against the capabilities of the technology. Really, we are in the infancy of software development. All languages are incredibly oblique to their runtime environments, especially in distributed scenarios. Any language that gets little but praise is simply not sufficiently understood by enough people to be critiqued, or for said critiques to get up-voted on news sites. I am not, by the way, arguing that all languages are therefore equal in quality. What I am arguing against is this: often when there's a vote-up negative article about technology X, there's people who respond, "Aww shucks, I was about to use X for my next project, what should I use instead?" And the responses are, "Well, use Y instead", where Y is currently on the zenith of its hype machine. This is a bad strategy for assessing technology, because it's simply inevitable that Y will eventually receive a hailstorm of similarly valid critiques. Consider it a given that any technology in use today will look stodgy in forty years. Instead, use the existence of critiques as a marker that a language is fairly well known and mature. It's rather like the appropriate way to use Yelp reviews: assume most of them are fake, assume nothing but positivity or negativity is wrong, and instead look for volume and breadth of tone.

icedchai 13y ago

I was at a job where I programmed in Scala for about 6 months. This was almost 3 years ago: immature tools (awful IDE support), slow compilers, long build times (this was partially due to Maven project with literally 50+ modules and too many unit tests), and inexperienced developers. Scala is too complicated a language. I'm sure it's a little better now... but, it's not for me.

frowaway001 13y ago

I also work in the same company as the poster. We are currently running a huge Scala/Play project where the team is a mix of many young developers (< 5 yrs) and a few seniors. Overall it is a very pleasant experience. There are multiple other projects using Scala which share this positive feeling. It is difficult to explain these reactions, but they are common among my colleagues. These are senior programmers who are generally very good with any programming language/task. They will pickup something new and be productive in just a few days. They usually end up liking Ruby, Javascript, Clojure and for good reasons. Scala on the other hand requires a lot of attention and work to get mastery. One can get started in days but to exploit the real power and appreciate design choices takes months if not years. In my opinion this is an important factor why these smart developers react so badly to Scala which for them is just another tool which takes too much time to grasp. There is little Scala can do. Maybe it should become less ambitious. No macros, no compiler plugins, do not challenge FP etc. But then it will not be the Scala we all loved :) Also, it is important to note the blog post does not criticise Scala in isolation. It used Spray DSL for routes and Gradle as a build tool, maybe that particular combination increases the pain. https://groups.google.com/d/msg/scala-internals/153H3Ya4Nxk/AngkiUE7VUIJ https://groups.google.com/d/msg/scala-internals/153H3Ya4Nxk/...