This is a translation of 「モナドはメタファーではない」に関する補足 by Kenji Yoshida (@xuwei_k), one of the most active Scala bloggers in Japan covering wide range of topics from Play to Scalaz.
Daniel Spiewak’s Monads Are Not Metaphors was written about two and a half years ago, but seeing how its Japanese translation is still being tweeted and being bookmarked by 250 users on Hantena, its popularity doesn’t seem to cease. I just remembered something to note about the example code used in the post, which could be an unstylish critique, but I’m going to jot it down here. It’s an unstylish critique, because I’ll be digging into the part where the author likely knew from the beginning but omitted it intentionally for the sake of illustration. Also I’ll be using Scalaz in this post.
It’s been a month now, but on March 1, 2013 I flew to Japan to attend “Scala Conference in Japan 2013.” That’s the name of the conference.
from a podcast
One day (June 2, 2012), I was listening to Scala Types recorded at Scala Days 2012, and someone (turns out it’s @timperrett) said “I would love to see Scala Days in Asia. We had two in Europe now. It would be wicked to have it in China or Japan, or somewhere like that.” I relayed this info on twitter saying there’s an opportunity for the Scala community in Japan to invite the conference.
During the months of December, tech-savvy geeks in Japan take turns to post themed blog articles, known as the “Advent Calendar”. For last year’s Scala Advent Calendar 2011 I translated Eric Torreborre’s post covering The Essence of Iterator Pattern. It was somewhat of a calculated move, knowing Japanese fondness for functional programming articles. Another selfish motive was that some of the concept would seep in to my thickness as I was translating the post word by word. In hindsight, both goals were achieved handsomely thanks to the quality of both Jeremy Gibbons, Bruno Oliveira and Eric’s work. This seeped in knowledge was probably the secret sauce behind the learning Scalaz series that I worked on this year.
Unlike XML-based build tools sbt’s build definitions are written in Scala (for both .sbt and .scala). This means that once one gets over the hurdle of learning sbt’s concepts and operators, it doesn’t take much for build users to start writing sbt plugins.
I’ve ported a few from sbt 0.7 before, but I’ve also been writing some original ones recently that I’d like to share.
sbt-dirty-money
sbt-dirty-money is a plugin to clean Ivy cache somewhat selectively (anything that includes organization and name under ~/.ivy2/cache). It was such a simplistic 25-line implementation, but clean-cache and clean-local tasks continue to be useful for me.
treehugger is a library to write Scala source code programmatically. It’s also an implementation of Scala AST based on Reflection API, now available from github eed3si9n/treehugger.
Edit:
I’ve expanded this into a complete guide using awesome n8han/pamflet.
Scala the language is one of the most elegant, expressive, consistent, and pragmatic languages. From pattern matching to the uniform access principle, it got so many things right. And Scala the ecosystem and Scala the community only makes it better.
In Scala 2.9.1, locally declared implicits are preferred over imported ones. The problem is that the spec does not cover such behavior. My original hypothesis was that either I did not understand the spec correctly, or the spec was wrong. Based on the assumptions, I set out to explore the implicits resolution precedence last week. Like MythBusters say, the best kind of result is when you get something totally unexpected. It turns out that both of the hypotheses were wrong.
Northeast Scala Symposium 2012 is coming up in a few months, but I want to revisit a talk from this year’s nescala to wrap up 2011. One after the other, nescala had amazingly high quality of talks. You can check them all out here. With Daniel’s Functional Data Structure and Jonas’s Akka each having an hour-long key notes, the symposium left an impression on me that actors and FP are two major forces within Scala community. (Paul declaring that sending messages to actors is not referentially transparent was a hint too, I guess) There were also earlier signs of how the year turned out, like Mark’s sbt 0.9 presentation and Nermin’s Scala performance consideration. One talk that stood out in terms of immediate impact to change my code was Josh’s talk: Implicits without the import tax: How to make clean APIs with implicits.
When the original version was published on 06/19/2011, the motive for writing this guide was to aid the effort of moving people over to sbt 0.10 from 0.7, inspired by Mark’s sbt 0.10 demos that I was able to see live (first at northeast scala, and second at scala days 2011). At the time, the plugins were considered to be a major roadblock to the migration, since build users can’t move to 0.10 without the plugins. So my strategy was to port the plugins myself if they weren’t there, ask questions on the mailing list when I get stuck, and write up the results. I’ve gotten many positive feedbacks, and it’s helped people get on to 0.10. However, as it turns out, my understanding of sbt 0.10 wasn’t always complete, and downright wrong and misleading at times. I take responsibility of my writing. Instead of leaving old contents in, I’ve decided to push it into github, make a new version and move on. The most up-to-date knowledge of writing plugins is compiled in Plugins Best Practices written mostly by Brian and Josh, and a tiny section by me.
Let’s talk about testing. Once you write a plugin, it turns into a long-term thing. To keep adding new features (or to keep fixing bugs), writing tests makes sense. But how does one go about testing a plugin to a build tool? We fly, of course.
scripted test framework
sbt comes with scripted test framework, which let’s you script a build scenario. It was written to test sbt itself on complex scenarios such as change detection and partial compilation:
I wish there was a common super trait for various future implementations in the standard library, so I can express the concept without tying the code to a specific platform stack. I am not sure if there are others who feel the same, but I think it would be useful for library authors. That’s my motivation of writing sff4s.
what is future?
You’ve probably come across the notion before but let’s go over it quickly. A future value (also known as promise) represents an incomplete calculation.
I’ve tried other IDEs for Scala, but always ended up going back to TextMate. As I am getting on the IntelliJ IDEA wagon, I’ve made a Twilight theme to make the ride smoother.
Ultimately, the users of scalaxb are interested the real problems that the entity objects express, not how they persist into XML. That’s why I knew I eventually had to vacate the singleton/companion object of the case class to implement the data binding. Until recently it has been generating the data binding implementation as follows:
Once you use any technology to a significant extent, you understand its strength and shortcomings. I’ve probably written tens of thousands of lines of code in Delphi or C++, Java and C# too to some extent. I’ve depended on those languages, but gripe about them too. The new language obviously has the advantage of just being new. Since I haven’t written anything significant in Scala besides Tetris, I haven’t hit the shortcomings yet.
