<i>flatMap [B, That] (f: (A) ⇒ Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That<p>...<p>tell me that doesn't make you want to run screaming</i><p>It may not be great but I prefer this to a higher-order function in a dynamically typed language, where your only recourse may be to read the source code in depth to figure out valid arguments. I have run into this with some Scheme and JS libraries - better hope for good documentation! I really like Scala's type system.<p>In my brief foray with Scala a couple years back, the thing I remember being most frustrated by was that idiomatic Scala looks too much like idiomatic Perl in some cases. Sometimes blocks would be denoted by parens, sometimes by braces or nothing at all, and it was often hard to tell if you were inside a nested function or not. The underscore was also an unfortunate addition to the language. When I stepped away from it for a couple months and came back, the Scala I'd worked so hard to write "idiomatically" was no longer legible to me.
I don't know, what does a guy have to do to get a language accepted these days. Integrate it with one of the most popular platforms, base the syntax on the most popular syntax, make the type system sound and expressive at the same time... and then it's too complicated. Or too hard for the average developer. Really? It seems to me that scala can be seen as an extended version of java. Though it extends pretty far, sure.<p>I've used scala on and off for 5 years or so. It seems to me to be a very practical and flexible language. There are things that I don't like, but compared to the number of things I don't like about every other language I use, scala does ok.<p>And I kinda wonder about the too hard for the average developer thing anyway. Didn't the average developer use to program C++? Despite efforts to the contrary, I still program C++, and compared to that, scala's a stroll on a spring day.
David is spot on when it comes to the complexity of the documentation; it's great that it's exhaustive, but it would be nice to have the "here's how to use it" documentation near the "here's how to implement your own collection type" doc.<p>Another trend I see in Scala is the abuse of symbols-as-method names. I see a lot of Scala (and Lift) code that looks like<p><pre><code> val foo = bar ~-> 45 <~< "Fred" %% x
</code></pre>
with little commonality of convention.
[rant, for which I'd like to apologize]<p>I've tried to like Scala and it's just hard to do so. Once you've been spoiled by Ruby, Haskell, Python, Coffeescript, Clojure, etc, it's hard to see Scala as more than an obfuscated Java [and, yes, I've been coding for nearly 30 years, so this isn't new-language-cock-fight fanboism]. "case classes"? Really? I read Programming Scala and thought that we had learned better.<p>I'll take 3 languages that try to make my life easier rather than one language that tries to encompass every possible paradigm... Or perhaps Scala could have stepped the fuck up, worn the hair shirt for a while and done something interesting. By which I mean: see Mirah (<a href="http://www.mirah.org/" rel="nofollow">http://www.mirah.org/</a>) which is imperfect, beautiful and headed in an awesome, productive direction.<p>And I realize that I'm not in the sweetspot for Java.next, but I am certainly involved in languages du jour and Scala, even if it is Java.next, is not one of them. Some may point at C and C++ as an analogous set of languages and transitions, but I'd point out that we currently live in a world in which new languages are popping up constantly, are being marketed well and are being tried by large groups of coders. Merely extending an existing language is no longer a recipe for success.
I think his argument applies to most languages that are more powerful than what you see in the mainstream. You have to be in the 95 percentile of programmers to be able to use Common Lisp or Clojure correctly, or even to use some of C#'s newer and more advanced language features. In fact, for languages even more steeped in the academic world, like Racket or Haskell, I would pin that percentile more at 99.9.<p>Languages like Gosu and Kotlin are simpler, but just aren't bold enough to make a big difference in overall productivity. My personal hope is that some future generation of programmers is just better educated. I don't know how else any of these languages or tools will ever gain widespread acceptance.
I guess we'll see how Project Kotlin [1] does to move Java forward with some of these issues in mind (especially IDE support).<p>[1] <a href="http://confluence.jetbrains.net/display/Kotlin/Welcome" rel="nofollow">http://confluence.jetbrains.net/display/Kotlin/Welcome</a>
He tries to make a distinction between library-level and consumer-level in regards to the type-system and the user docs; hmm, where have I heard that before?<p>And how can you make that distinction in a language anyway? Aren't users supposed to implement their own flatMap -like functionality if not available?<p>This just highlights one big Scala flaw.
Interesting and honest article from a big Scala promoter.<p>I have been thinking about this in regards to Haskell- and much of this article would apply. But you can't write Java instead of FP in Haskell. Some aspects of Haskell are harder to learn, and some easier. I feel the biggest issue for a user of a library is: can they understand the compiler error messages? This places constraints on the level of abstraction that a library writer can achieve if sharing the library with the community.
Improved toolchain to minimize complexity:<p>- better compiler error messages:<p><a href="https://raw.github.com/scala/scala/master/test/files/neg/found-req-variance.check" rel="nofollow">https://raw.github.com/scala/scala/master/test/files/neg/fou...</a><p><a href="https://issues.scala-lang.org/browse/SI-2388" rel="nofollow">https://issues.scala-lang.org/browse/SI-2388</a><p><a href="https://issues.scala-lang.org/browse/SI-3092" rel="nofollow">https://issues.scala-lang.org/browse/SI-3092</a><p>(unfortunately the JIRA is down now and google didn't really cache them)<p>- compiler warnings, e.g. tupled arguments:<p><a href="https://issues.scala-lang.org/browse/SI-4851" rel="nofollow">https://issues.scala-lang.org/browse/SI-4851</a><p>- implicits: "-Xlog-implicits" switch tell you where they come from (and the IDEA plugin works pretty well on this issue), and explicit return types for implicits:<p><a href="http://groups.google.com/group/scala-internals/browse_frm/thread/8dba26b208f1870b#" rel="nofollow">http://groups.google.com/group/scala-internals/browse_frm/th...</a><p>- documentation: definitely a lot of work with a "doc czar" appointed.
<i>The Scala type system is tremendously powerful</i><p>But it's not tho', well maybe it is if you're used to Java, but coming from ML you will boggle that it can't infer types in function arguments.<p>Also Zed Shaw, WTF has he got to do with Scala? I think you will find most people who are more into code than they are into flamewars/trainwrecks won't have heard of him, and why should they?
I studied it with a couple of friends at work and I ended up with same conclusion. Scala was hard. Way too hard for the average corporate programmer. It could work in a startup environment, it would not work in corporate america. Flat out, the programmers are just not there.<p>It is a good language, just too complex. :(
Yes, it is.<p>This is why Gosu has, for example, covariant generics. Yes, it is unsound. But it is simple and good enough.<p>Type systems should be there to help us write code, in particular to support things like IDEs. Correctness is great as far as it goes, but it turns out it doesn't go too far and you get 90% of the correctness benefit with, hey, look at that, 10% of the effort and complexity.<p><a href="http://www.jwz.org/doc/worse-is-better.html" rel="nofollow">http://www.jwz.org/doc/worse-is-better.html</a>
People who aren't used to Scala complain that it's ugly, but I find that language beauty has a lot to do with familiarity. Ocaml and Haskell seemed ugly (to me) at one time, and now I love those languages. Lisp and its parentheses? You get used to it after 2 weeks, but some people hate it at first. The sign of an aesthetically defective language is that it stays ugly even after you get a hang of it.<p>Scala may be The Compromise That We Have To Make. In the functional programming (i.e. good languages) community, we're so passionate about languages that we become factional, divided between Ocaml and Haskell and Clojure and Erlang and F#. What comes out of this is that we divide ourselves up into 1-2% silos and end up having to use Java, because people who don't care about PL got behind a small set of languages a long time ago.<p>I don't know Scala very well and may end up eating my words here, but I think it (or F#) may be the language we need to Get Behind, at least for now.<p>Scala is statically typed and can take advantage of the JVM libraries. It actually has a shot at becoming a major production language in professional software.<p>Also, what strong, static typing does to bad developers (spits them out brutally) is an asset to the software world. It makes sense for talented engineers, it accelerates the learning process of the talented-but-inexperienced ones, and it fires the incapable ones so you don't have to.
Your developers already use (the advanced features (linq)) of C# : Easy(ier). C# is dragging a lot of my fellow developers to the functional world.<p>It's fascinating to watch as these developers "get it" finally.<p>I found Scala very close to functional C#. In fact I'm most comfortable now with Scala on the JVM (when i must be there) as Java itself has stagnated for so long, it's no longer fair to call C# a Java clone.
#77777 for text colour on a white background? Yes, David, usability is hard!<p>I actually had to Ctrl+A the whole thing to read it, and I'm sitting in front of an IPS LCD with real 16MM colours. I wonder what do folks on an average-terrible PC laptop screen will see?
"Your developers come in at 9:15 and leave before 6 and don't check work email at night: Hard"<p>Am I the only person who find this attitude obnoxious? I know -- and I'd like to include myself -- some good devs who don't sell 24x7 to our employers.<p>edit: in particular, I don't check work email at night. I don't do ops. People should write better code or hire a different engineer.