On Monday I'm giving a talk at Scala Exchange on my take on idiomatic Scala. For those of you who can't make it, I'll give a quick rundown. You basically need four patterns:<p>- algebraic data types<p>- structural recursion<p>- fold, map, and flatMap<p>- type classes<p>That, in my experience, will cover the majority of code you need to write in Scala and give a solid basis for a robust and comprehendible code base.<p>It's unfortunate that in Scala algebraic data types and type classes require a bit more code than in most other functional languages.<p>E.g.<p><pre><code> sealed trait Foo
final case class Bar(...) extends Foo
final case class Baz(...) extends Foo
</code></pre>
vs something like<p><pre><code> data Foo = Bar ... | Baz ...
</code></pre>
for an algebraic data type, but it's really not so onerous to type.<p>These patterns are really truly shockingly simple to use. We teach them in introductory courses and the majority of people get them.<p>It's true that Scala has some warts, but as software engineers we ought to make decisions based not on our personal biases but on a consideration of the problem domain and tradeoffs involved. If you want 1) static typing, 2) a modern language, and 3) JVM compatibility then Scala is the best choice at the moment IMO. Remove one of those restrictions and other choices come into the picture.<p>Update: If you're interested in learning more about these patterns, on Friday we're going to send a free excerpt of our "Essential Scala" book to our mailing list. The excerpt will include material on algebraic data types and structural recursion. You can sign up here: <a href="http://underscore.io/newsletter.html" rel="nofollow">http://underscore.io/newsletter.html</a>
Interesting. I've followed Matthias' project as I've tried learning the Play framework as well as front end development, and it has been incredibly useful. Incidentally, I learned Scala after I knew Clojure reasonably well, and I feel like I could apply the same arguments in the reverse direction.<p>When it comes to the back end, I'll likely choose Scala 100% of the time. I really believe there is no substitute for a strongly typed ML-derivative for that type of environment. Additionally, there are a strong set of robust scala libraries (Typesafe mostly) that are completely production ready, and java interop is much more natural when you need it.<p>For the front end, I'm currently using Javascript, but I have toyed with the idea of both Scala.js and Clojurescript. This is where Clojure really makes me mad. I feel as though the dynamically typed Clojurescript should be a better fit as a compile-to-javascript language, but in every instance I've tried, Scala.js just works better. It compiles correctly, error messages make sense, much better documented, and there are fewer deviations from the core language. And the clojurescript libraries are mostly terrible in this regard...even the super-hyped ones like Om. My biggest pet peeve are the tutorials that force you to learn unrelated things (like Datomic, Emacs, Ring, etc) to be able to walk through them. I really feel like Clojurescript had a chance to shine here, but I find it far less inspiring than the relatively immature Scala.js. Oh well.
If you like Scala but find it too scattered then there's always Haskell* :)<p>(*) Not that there aren't a thousand reasons to not choose Haskell. This is merely obligatory temptation dangling.
I found your experience closely mirrors mine with scala. At my current shop we write mostly ruby and scala. The ruby code between developers looks much more uniform than the scala code I believe due to the fact that while trying to please everyone scala hasn't yet developed much of "the scala way". I do hope this changes as I really enjoy scala. Currently my team is experimenting with style/punting tools like stylecop to try to bring a little consistency to our code. Too early to say how it will work out but I would love to hear from others how you try to bring a team style to a code base that will happily let a fully functional developer, a fully object oriented developer, a straight imperative developer, and someone who believes in mixing these things all work side by side. Mentally by giving up the possibility of nothing you have to learn everything which means loading a lot of the scala compiler up into your brain before even trying to read a bit of anyone else's code.
I think the article is fundamentally flawed from this comment alone:<p>"In well over a year of working in Scala teams there hasn’t been a single day where I felt that there was a shared mindset about how to develop a system or even approach a problem."<p>So this guy expects a programming language to create a shared mindset?<p>I've been developing software for close to 17 years in more languages than you can shake a stick at and none of them do this for you. It's always about picking the right tool for the job and/or team.<p>A shared mindset comes from other planning type activities like use cases, function/non-functional specifications, and general architecture type planning before you write code. Especially for larger projects.<p>I think software patterns tend to help drive synergy in a team environment. It's not perfect but my experience has shown me and the folks I work with at least, that adopting patterns helps to bring us together but those patterns are usually fleshed out during architecture planning activities.
A programmer complains that different programmers have different styles of programming in Scala ...<p>and ... switches to a lisp. You know, languages that execute code by rewriting the syntax tree of the running program ...<p>This ought to be good.<p>This is not meant to be disparaging against LISPs. I'm just alluding to the fact that while there are 5-10 ways to do the same thing in Scala, all looking very different, working subtly different, there's 5000 different ways to do the same thing in LISPs.
His Clojure implementation is here: <a href="https://github.com/matthiasn/BirdWatch/tree/master/Clojure-Websockets" rel="nofollow">https://github.com/matthiasn/BirdWatch/tree/master/Clojure-W...</a>
fogus, what should I read nowadays? BOOKS???<p><a href="http://blog.fogus.me/2011/03/27/the-long-lost-art-of-thoughtfulness-in-blogging/" rel="nofollow">http://blog.fogus.me/2011/03/27/the-long-lost-art-of-thought...</a>
There are three and only three vague points conveyed in the article: (1) Scala has "immense" syntax, (2) Scala tries to support too many paradigms, and (3) the Iteratee library is hard to grasp.<p>For (1): I disagree -- Scala's syntax is relatively easy to grasp. Perhaps the author meant constructs.<p>For (2): people keep saying this but why not just stick with the way you are comfortable with?<p>For (3): I don't see how this is a language issue; at the very least it shows that the author is unable to grasp a particular functional programming abstraction.
No offense to the author, but this reads like a 16 old claiming he finally find the girl who is 'the one' for life. __only two years later__, that Another girl shows up and OMG the new chick definitely is the 'true' one.<p>To put it another way, under extreme circumstances, Mr. Martin Odesky can use even the $&<i>^%$#</i>$ PHP to write safe and efficient airplane flying control software.<p>The point is the language is hardly matter as much as your kids think. There are far more important things for good software. But language is not only a tool but also a toy and a passion, so I can appreciate the urge to talk about it. :-)