Significant Software Development Developments of 2012

I have written before (2007, 2008, 2009, 2010, 2011) on my biased perspective of the most significant developments in software development for that year. This post is the 2012 version with all my biases and skewed perspectives freely admitted.

10. Groovy 2.0

Groovy 2.0 have been an important version for Groovy. Groovy 2's arguably most notable new features are its static type checking and static compilation capabilities.

9. Perl Turns 25

Perl celebrated its 25th anniversary in 2012. Love it or loathe it, Perl has definitely become the predominant scripting language, especially in the non-Windows environments. Perl is not my favorite (I'd rather use Groovy, Python, or Ruby), but I find myself needing to use it at times, usually because I'm modifying or using an existing script or set of scripts already written in Perl. Happy Birthday, Perl!

8. Git and GitHub

Git is the trendy choice now in version control and GitHub is equally trendy for hosting code. The post Why Would Anyone use Git in their Enterprise? states, "Git has a cult-like following in the development community." The book Pro Git (2009) is freely available for reading online and can be downloaded as a PDF, mobi, or ePub electronic book.

7. NoSQL and Polyglot Persistence

The NoSQL concept seems to be maturing and moving from unabated hype and hyperbole to understanding when it works well and when it doesn't. In 7 hard truths about the NoSQL revolution, Peter Wayner writes: NoSQL systems are far from a perfect fit and often rub the wrong way. The smartest developers knew this from the beginning. ... the smart NoSQL developers simply noted that NoSQL stood for "Not Only SQL." If the masses misinterpreted the acronym, that was their problem.

Martin Fowler's nosql page states: "The rise of NoSQL databases marks the end of the era of relational database dominance. But NoSQL databases will not become the new dominators. Relational will still be popular, and used in the majority of situations. They, however, will no longer be the automatic choice." With this, Fowler introduced the concept of polyglot persistence (which he mentions was previously coined by Scott Leberknight in 2008) and explicitly compared this to the concept of polyglot programming. If we as a software development community believe that the advantages of using multiple languages in the same application (polyglot programming) are worth the costs, then it follows that we might also determine that the advantages of using multiple data stores within the same application (polyglot persistence) are also worth the costs of doing so.

6. Mobile Development

Mobile development continues to rapidly rise in 2012. The December 2012 write-up on the Tiobe Index states that Objective-C is likely to be the language of the year again in 2012 due to its rapid rise (third in December 2012 behind only C and Java and ahead of C++ and C#). The writers of that summary conclude about language ratings on this index, "In fact it seems that if you are not in the mobile phone market you are losing ground."

Suzanne Kattau's post Mobile development in the year 2012 succinctly summarizes the changes in popular mobile device platforms and operating systems in 2012.

5. Scala (and Typesafe Stack 2.0 with Play and Akka)

I have highlighted Scala multiple times in these year-end review posts, but this is my highest rating of Scala because Scala has seen a tremendous year in 2012. On 23 August 2012, Cameron McKenzie asked, "Is Scala the new Spring framework?" An answer to that question might be implied by the 1 October 2012 announcement that Spring founder Rod Johnson had joined Typesafe's Board of Directors (Johnson left SpringSource in July). Scala provides the intersection of again-trendy functional programming with widely popular and proven object-oriented programming and is part of the increasingly popular movement to languages other than Java on the JVM. It's not difficult to see why it had a big year in 2012.

The Typesafe Blog features a post called Why Learn Scala in 2013? that begins with the statement, "2012 was a big year for the Scala programming language - with monumental releases, adoption by major enterprises and social sites alike and a Scala Days conference that knocked the socks off years past." The post then goes on to list reasons to learn Scala in 2013 with liberal references to other recent positive posts regarding Scala.

Ted Neward has predicted that in 2013 "Typesafe (and their Scala/Akka/Play! stack) will begin to make some serious inroads into the enterprise space, and start to give Groovy/Grails a serious run for their money." I am not calling Play and Akka out in this post as separate significant developments in 2012, but instead lump them together with Scala as part of justifying Scala taking the #5 spot for 2012. There is no question, however, that 2012 was a big year for Akka and Play. The year 2012 saw the release of Typesafe Stack 2.0 along with Play 2.0 and Akka 2.0.

4. Big Data

Big Data was big in 2012. AOL Government has named Big Data its Best of 2012 for the technology category. Geoff Nunberg argues that "'Big Data' Should Be The Word Of The Year." Interest in the statistical computing language R has (not surprisingly) risen along with the surging interest in Big Data.

3. HTML5

2012 was another big year for HTML5. Although HTML5 continued to be evangelized as a standards-friendly favorite of developers, some hard truths (such as performance versus native code) about the current state of HTML5 also became more readily obvious.

That being stated, I think HTML5 still has a very positive future ahead of it. Although it has certainly been over-hyped with emphasis on what it might one day become rather than what it is today, it would also be foolhardy to ignore it or underestimate its usefulness. Two articles that remind us of this are FT exec: HTML5 is not dead and HTML5 myth busting. The article 'HTML5 is ready' say creators of mobile HTML5 Facebook clone talks about attempts to prove HTML5 is ready today from a performance standpoint.

2. Security

Awareness of security holes, risks, and vulnerabilities has been increasing for the past several years largely due to high-profile incidents of lost sensitive data and new legal requirements. However, 2012 seemed to be a bigger year than most in terms of increasing awareness of security requirements and expectations in software architecture and design.

Java seemed to be particularly hard hit by bad security news in 2012. Articles and posts that provide examples of this include 1 Billion computers at risk from Java exploit, Oracle's Java Security Woes Mount As Researchers Spot A Bug In Its Critical Bug Fix, Java Vulnerability Affects 1 Billion Plug-ins, Another Week, Another Java Security Issue Found, Oracle and Apple Struggle to Deal with Java Security Issues, and Java still has a crucial role to play—despite security risks.

The article Oracle to stop patching Java 6 in February 2013 suggests that users of Java should upgrade to Java 7 before February 2013 when Oracle will supply the last publicly available security patch to Java SE 6 outside of an Oracle support plan. Another article is called Oracle's Java security update lacking, experts say.

1. Cloud Computing

It seemed like everybody wanted a cloud in 2012 even if they didn't really need one. Archana Venkatraman put it this way, "2012 was the year cloud computing hit the mainstream." Steve Cerocke stated, "2012 will go down as the year of cloud computing." Other articles and posts on the biggest cloud stories of 2012 include The 10 Biggest Cloud Stories Of 2012 and Top five cloud computing news stories in 2012.

Cloud Computing is in the sweet spot many trendy technologies and approaches go through when enthusiasm is much greater than negativism. Charles Babcock's Cloud Computing: Best And Worst News Of 2012 is more interesting to me than many cloud-focused publications because it highlights the good and the bad of cloud computing in 2012.

Honorable Mention

I couldn't fit everything that interested me about software development in 2012 into the Top Ten. Here are some others that barely missed my cut.

C

As mentioned earlier, the C programming language appears headed for #1 on the Tiobe Index for 2012. One of programming's most senior languages is also one of its most popular. When one considers that numerous other languages are themselves built on C and when one considers that many languages strive for C-like syntax, the power and influence of C is better appreciated. C's popularity has remained strong for years and 2012 was another very strong year for C.

Another piece of evidence arguing C's case is the late 2012 O'Reilly publication of Ben Klemens's book 21st Century C: C Tips from the New School. The author discusses this book and C today in the O'Reilly post New school C.

Although I have not written C code for several years now, I've always had a fondness for the language. It was the language I used predominately in college (with Pascal and C++ being the other languages I used to a less degree) and I wrote the code for my electrical engineering capstone project in C. I remember (now fondly) spending almost an entire Saturday on one of my first C assignments fighting a bug to only realize that it was not working because I was using the assignment operator (=) rather than the equality operator (==). This lesson served me well as I learned other languages in terms of both what it important to differentiate and in terms of how to better debug programs even when a debugger is not readily available. I think my C experience grounded me well for later professional development with C++ and Java.

Gradle 1.x

Using an expressive programming language rather than XML or archaic make syntax to build software seems like an obviously beneficial thing to do. However, make, Ant, and Maven have continued to dominate in this area, but Groovy-based Gradle shows early signs of providing the alternative we've all been looking for. Gradle still has a long way to go in terms of acceptance and popularity and there are many other build systems with some of Gradle's ideals that have failed, but Gradle did seem to capture significant attention in 2012 and can hopefully build upon that in future years. Gradle 1.0 was formally released in June 2012 and Gradle 1.3 was released in November 2012.

DevOps

Among others, Scott Ambler predicted that "DevOps will become the new IT buzzword" in 2012. If it is not "the" buzzword of 2012, it is not for a lack of trying on the DevOps evangelists' part. The DevOps movement continued to gain momentum in 2012. The DZone DevOps Zone sees one or more posts on the subject added each day. The only reason this did not make it into my Top Ten is that I still don't see "Typical Everyday Coder" talking about it when I am away from the blogosphere talking to in-the-trenches developers.

Amber's concluding paragraph begins with this prediction, "Granted, there’s likely going to be a lot of talk and little action within most organizations due to the actual scope of DevOps, but a few years from now, we’ll look back on 2012 as the year when DevOps really started to take off." Only time will tell. There continue to be posts trying to explain what exactly DevOps is.

Departures of Noteworthy Development Personnel

There were some separations of key developers from their long-time organizations in 2012. As mentioned previously, Spring Framework founder Rod Johnson left VMWare/SpringSource (and ultimately ended up on the Board of Directors for Scala company Typesafe). Josh Bloch, perhaps still best known for his work at Sun on the JDK and for writing Effective Java, left Google in 2012 after working there for eight years.

Resurgence of Widely Popular but Aged Java Frameworks

Two very popular long-in-the-tooth Java-based frameworks saw a resurgence in 2012. Tomek Kaczanowski recently posted JUnit Strikes Back, in which he cites several pieces of evidence indicating a resurgence in JUnit, arguably the most commonly used testing framework in Java (and, in many ways, the inspiration for numerous other nUnit-based unit testing frameworks). Christian Grobmeier's recent post The new log4j 2.0 talks about many benefits of Log4j2 and how it can be used with more recently popular logging frameworks such as SLF4J and even Apache Commons Logging.

Electronic Books (E-books)

Electronic books (ebooks) are becoming widely popular in general, but also specifically within software development books. This is not surprising because e-books provide many general benefits, but also have benefits particular to software development. In particular, it is nice to be able to electronically search for terms (overcoming the poor index problem common to many printed programming books). Other advantages include the ability to have the book on laptops, mobile devices, e-readers, and other portable devices. This not only makes a particular book readily available, but makes it easy to carry many books on many different technical subjects with one on travel. It is also less likely for the electronic book to be "borrowed" unknowingly by others or turn up missing.

Perhaps the biggest advantage of electronic books is cost. It is fairly well known that technical books are generally not big profit makers for publishers. However, with printing and distribution costs being a significant portion of traditional publication costs, e-books make it easier to publishers to price these books at a lower cost than the printed equivalent.

The reduced cost to the publisher for an electronic book can be passed onto the consumer. I recently took advantage of an offer from Packt Publishing to purchase a total of eight of their books as electronic books for a total price of $40. Given that a single printed programming book can cost $40 or more, this was a bargain. I have also blogged on other good deals on e-books provided by other technical publishers such as O'Reilly and Manning.

I have especially appreciated the Manning Early Access Program (MEAP). This program is only viable thanks to electronic books and allows readers to read a book as it is developed. Because technologies change so quickly, it is often helpful to get access to even portions of these books as quickly as possible.

Finally, another advantage of e-books is their ultimate disposal. In reality, they take up such a small portion of even an old-fashioned CD or DVD, that I can usually dig up a copy if I want to. However, I can remove them from my electronic devices when I no longer need them and need the space. There are no environmental or logistic concerns about their disposal. This is important because these books do tend to get outdated quickly and sometimes an outdated programming book is worse than having no book at all because it can be very misleading.

PhoneGap / Cordova

Given the popularity of mobile development and HTML5 in 2012, it's not surprising that PhoneGap and Cordova had big years in 2011/2012. In the web versus native debate, one of the advantages of web is the portability of web apps across multiple devices. The PhoneGap/Cordova approach brings some of this benefit for writing code but maintains some of the performance advantages of running native applications.

Objective-C

Objective-C looks to win the Tiobe Index language of the year again in 2012. This is yet another indicator of mobile development prevalence as Objective-C's popularity is almost exclusively tied to iPhone/iPad development, though Objective-C's history is closely coupled with the NeXT workstations and even has been called an inspiration for Java (advertised as quoted by Patrick Naughton) instead of C++.

Kotlin

For several years now, it has been trendy for the "cool kids" to post feedback messages on articles or blogs about Java features proclaiming that Groovy or Scala does anything covered in that blog post or article better than Java does it. Many of the "cool kids" (or maybe different "cool kids" with the same modus operandi) now seem to be doing the same on Scala blog posts and articles, advocating the advantages of Kotlin over Scala.

As Scala and Groovy still lag Java in terms of overall popularity and usage, Kotlin lags both Groovy and Scala in terms of adoption at this point. However, there are definitely some characteristics of Kotlin in its favor. First, the Kotlin web page describes the language as, "a statically typed programming language that compiles to JVM byte codes and JavaScript." I could definitely see how "statically typed" and "compiles ... to JavaScript" would be endearing to developers who must write JavaScript but prefer static compilation. Andrey Breslav, Kotlin Project Lead, believes that static languages compiling to "typed JavaScript" will be a major development of 2013 and he cites Dart and TypeScript as other examples of this. Being able to run on the JVM can also be an advantage, though this is no different than Groovy or Scala.

One major positive for Kotlin is its sponsor: JetBrains. It is likely that their IDE, IntelliJ IDEA, will provide elegant support for the Kotlin language. This is also a sponsor/owner with the resources (monetary and people) to improve chances for success. Because JetBrains is "planning to roll out a beta of Kotlin and start using it extensively in production," they are more likely to continue investing resources in this new language.

There was no way I could justify to myself putting Kotlin in my top ten for 2012, but once it is released for production use, it is possible that Kotlin may make another year's Top Ten list if it is widely adopted.

Ceylon

Kotlin isn't the only up-and-coming static language for the JVM; Ceylon is also relatively young in this space. I wrote about the JavaOne 2012 presentation Introduction to Ceylon and that post provides brief overview and description information.

The first milestone of Ceylon IDE (Eclipse plug-in) was released in early 2012 and was followed in March with the release of Ceylon M2 ("Minitel"). This was followed by the Ceylon M3 ("V2000") release in June and Ceylon M4 ("Analytical Engine") in October.

The newer JVM-friendly languages with the seeming best chances of long-term viability are those with strong sponsors: Groovy has SpringSource, Scala has TypeSafe, Kotlin has JetBrains, and Ceylon has RedHat.

End of Oracle/Google Android Lawsuit

The lawsuit between Oracle and Google over Android seems to have, for the most part, concluded in 2012. There still seems to be bad blood between the two companies, but the settlement of this probably allows for continued success of the Android platform and potentially for collaboration at some future point between the two companies on Java. It will be interesting to see if Google allows its employees to submit abstracts to JavaOne 2013.

Everyone a Programmer

When HTML first started to expand across the universities and colleges in the early-to-mid 1990s, it seemed that everyone I knew was learning HTML. Most of us were "learning" it by copying other peoples' HTML source and editing it for our own use. Of course, everything then was static and fairly easy to pick up. It probably also skewed my perspective that I was majoring in electrical engineering with an emphasis in computer science and so was around people who had a tendency to adopt and use new technology. Perhaps for the first time since then, I have felt that there is an ever-growing interest in pushing everyone to learn how to program at a certain level. I don't need to provide any supporting points for this because I can instead reference Joab Jackson's 2012: The year that coding became de rigueur. Not only does this post enumerate several examples of the debate about whether everyone should learn programming, but it also makes cool use of "de rigueur" in its title.

Java

I did not include Java itself in my Top Ten in 2012. Perhaps this is an indication that I too felt that 2012 was a slow year for Java (and agree that this is not necessarily a bad thing). That being stated, Martijn Verburg has listed some "personal highlights of the year" in the world of Java in 2012 in What will 2013 bring? Developers place their bets. These include the JVM's entry into the cloud, Java/JVM community growth, OpenJDK, Java EE 7, and Mechanical Sympathy.

It's a small thing in many ways, but I think James Gosling returning to JavaOne and throwing out t-shirts was symbolic of a strengthening resurgence among an already strong Java development community.

Jelastic

Java on the cloud in general had a big year in 2012. Jelastic had a particularly big year. The screen snapshot below is from an e-mail sent out by Jelastic COO Dmitry Sotnikov.

Jelastic was prominently mentioned at JavaOne 2012 multiple times. Some of these mentions were due to winning the Duke's Choice Award for 2012. Other mentions resulted from James Gosling's positive review of his use of Jelastic. As I blogged on earlier, Gosling described himself as "a real Jelastic fan" at the JavaOne 2012 Community Keynote.

Linux-based ARM Devices

Oracle announced release of a Linux ARM JDK in 2012. The ability to run even JavaFX on Linux ARM devices provides evidence of Oracle's interest in supporting Linux ARM devices. Given that Oracle is well-known for investing in areas where returns are often great, it follows that perhaps Oracle sees great potential for the Linux ARM devices in the future. An interesting article that looks into this is Java 8 on ARM: Oracle's new shot against Android?

One couldn't go to a keynote presentation at JavaOne 2012 without hearing about one very trendy Linux ARM Device, the Rasperry Pi. Similarly, the BeagleBoard and PandaBoard have also become very popular.

Improving Job Market for Software Developers

2012 seemed to be a good year for those with careers in software development and this seems likely to continue. CNN Money ranked software developer as #9 in its Best Jobs in America story (software architect was #3). For example, Lauren Hepler has written that Software developers top 2013 job projection and cites a Forbes slides-based presentation.

Perhaps more importantly than these stories are my anecdotal observations of a surging market for software developers. I have seen an uptake in number of unsolicited employment queries from potential employers and clients. I am also seeing an increase in billboard advertising for developers, especially in areas of the United States with high concentrations of software development. This improving job market might be one of many reasons for increasing interest in programming in general.

Other Resources

There are other posts of potential interest. Katherine Slattery's Takeaways from the Top Development News Stories of 2012 talks about the Node.js "hype cycle," open source hardware, native apps versus HTML5 apps, and the "'learn to code' craze."

Ted Neward's annual predictions (for 2013 in this case) and review of his prior year (2012 in this) predictions is an interesting read.

Conclusion

2012 was another big year in software development across many different areas and types of development. Many of the themes discussed in this post overlap and are somehow associated with mobile development, cloud computing, and greater availability of data.

JavaOne 2012: What’s New in Scala 2.10

After getting lunch, I went to Hilton Golden Gate 6/7/8 to see Martin Odersky's (Typesafe) presentation "What’s New in Scala 2.10." It is always an opportunity to hear a language's creator discuss the language that he created.

Odersky stated by providing a brief history of Scala:

1996-1997	Pizza
1998-2000	GJ, Java generics, javac
2003-2006	The Scala "Experiment"
2006-2009	Industrial Strength Programming Language

Scala is a unifier between worlds of functional programm and object-oriented programming and is a unifier of agile (with lightweight syntax) and safe/performant/strongly typed programming.

Functional programming on the rise. 12 years ago OOPSLA had ten times attendance of ECOOP but today ICFP has three times ECOOP attendance and OOPSLA is no longer an independent conference. Functional programming important now because of market drivers. Odersky stated, "The world of software is changing because of hardware trends" and added, "Moore's Law is now achieved by increasing number of cores rather than clock cycles."

In this new world of clock cycle limitations, we have a "Triple Challenge": "Parallel" (how to use multicore), "Asynchronous" (how to deal with asynchronous events), and "Distributed" (how to deal with failures). In this world, "every piece of mutable state you have is a liability." The "problem in a nutshell" is "non-determinism caused by concurrent threads accessing shared mutable state."

non-determinism = parallel processing + mutable state

Non-deterministic behavior is something "we are uncomfortable with" and "avoiding mutable state means programming functionally." Eliminating mutable state is the one thing we have control over and can change. This is why Odersky believes that functional programming is just now rising out of the academic world to be used in the business world. Functional programming has always been inherently tied to fancy machines.

Odersky pointed out that writing functional programming is quite different than writing object-oriented programming. The "thought process of functional programming is really quite different" because it requires thinking of things spatially rather than temporally.

Having made the case for functional programming, Odersky asked if we should all move to Haskell now? He answered that there are still important things learned from object-oriented development. His slide stated, "What the industry learned about OO decompositionis analysis and design stays valid." We want to have functions and objects in our coding.

Odersky quoted Grady Booch, "Objects are characterized by state, identity, and behavior. Odersky maintains we now want to "eliminate, or at least reduce, mutable state." We want to get away from mutable state being the default. Odersky also believes we want to get away from referential equality and focus on structural equality.

Odersky listed simplicity, productivity, and fun as other reasons for functional programming in addition to dealing with the hardware environment of parallel processors.

Odersky moved from general functional programming discussion to specific Scala discussion. His bullet stated, "Scala can be as simple or as complex as you like, but it's best when it's simple." He cited Kojo as an example of Scala's alignment with simplicity. He also referenced "Sadaj's great talks." Odersky then began to work on some examples based on Ninety-Nine Scala Problems.

Scala 2.10 is "very close to RC1" and is in "code freeze" while working on three remaining code blockers and several documentation blockers. Odersky talked about the Scala Improvement Process (SIP) and showed the "Pending SIPs" that are accepted, postponed, or rejected.

SIP 12 ("String Interpolation" addresses the weaknesses and difficulties associated with concatenation of Strings using the + operator. It is shorter and safer to use string interpolation. The biggest obstacle to adding string interpolation was that $ is "already a legal character in strings." Rather than using a "special trick" of placing "s" in front of strings for which $ should be escaped and used for string interpolation, Scala will use more general solution of recognizing arbitrary IDs. The "f" string processor will interpret $ and %.

Developers could implement their own string processors and Odersky showed examples of this that might be written for XML and JSON. Odersky stated that, "Adding XML support in Scala is something that did not turn out so well." He says now there would be an advantage to using an XML string processor instead and remove the XML specific library dependency Scala currently has.

Odersky addressed why Scala does not have extension methods that "other cool languages" have. He answered that Scala does not have extension methods because "we can't abstract over them." It is "impossible to have them implement an interface."

Odersky introduced SIP 11 ("Implicit Classes"). One issue to think about here is "runtime overhead." SIP 15 ("Value Classes") introduces idea that Scala classes could extend AnyVal instead of Object. Classes extending AnyVal are "value classes" and are always unboxed. Odersky showed what code using these value classes would expand (be compiled) to.

The implicit keyword in Scala enables "very poweful" implicit conversions, but Odersky warns that "they can be misused" particularly if "there are too many of them." I like that Odersky likened them to chocolate: a little is very good, but too much leads to a stomach ache. You can turn off implicit conversion warnings by "bringing the identifier scala.langage.implicitConversions into scope (typically via import).

Odersky briefly discussed SIP 18 ("Language Imports") and then covered "Better tools." I found Odersky's goal for his language to be interesting: Odersky wants to "make Scala the language of choice for smart kids." To him, it's the ideal of what the language should be.

One attendee felt that boilerplate code is one of the best forms of simplicity and wondered whether Scala was missing its goal of simplicity by displacing boilerplate code. Odersky replied that boilerplate code would not be his preferred form of simplicity.

Odersky stated that Scala is largely mature from the perspective of significant API changes and so forth. He pointed out that all languages reach the point where it is difficult to make wholesale fundamental changes and that Scala's changes are smaller in nature now than they were in the late 2000s.

In response to an audience member's question, Odersky said that the best way to learn Scala is to read a book or take a course. He says many of the people he sees who try and struggle with Scala tried to learn it by studying its API documentation.

When asked to compare Scala to Groovy and JRuby, Odersky said that Scala is about as complicated as JDK 7 and will be less complicated than JDK 8. He feels Groovy is more complicated because it is a superset of Java. This is an interestingly different perspective on complexity. I have found Groovy to be very simple to learn, but I do have years of Java experience. I wonder if someone without Java experience would find Scala less difficult to learn. For me, even with all of Scala's great features, it cannot be easier to learn than Groovy was.

Another audience member's question led to Odersky mentioning some alternate IDE support (including Emacs and IntelliJ IDEA) for Scala in addition to ScalaIDE. There is a NetBeans plugin for Scala.

Odersky pointed out something I like about Scala in response to another question. He stated that Scala allows the developer to easily specify a piece of data is mutable. I like that Scala "does not prejudice" against mutable data and allows the developers to choose to do so if they want to. I really don't like it when "opinionated software" forces me to do what the framework's or language's author thinks is best.

I really enjoyed this presentation. I had changed from a differently planned session to this one last night and am happy with the change (although the other likely would have been good as well). My only concern about this presentation had been that, given my lack of Scala familiarity, that I'd be overwhelmed by discussion of new Scala 2.10 features without proper foundation. Fortunately for me, Odersky did not get into Scala 2.10-specific features until half way into the session. His coverage of functional programming and basics and history of Scala were helpful to me in general and were helpful specifically in preparing me to appreciate the new Scala 2.10 features. Between this presentation and the Scala Tricks presentation, my interest in trying out Scala is being renewed.

The photograph in this post was taken at Muir Woods National Monument before the beginning of JavaOne 2012.

JavaOne 2012: Scala Tricks

The first session I attended after lunch was Venkat Subramaniam's "Scala Tricks," held in the Hilton Golden Gate 3/4/5 conference room area. This is the first session in which I switched my planned session during JavaOne. I switched it last night as I look at my day's schedule and realized that, although excited about Lambda, I felt like I had the familiarity with Lambda I was looking for at this point (thanks to the Technical Keynote and The Road to Lambda), and felt like I'd benefit more from attending "Scala Tricks" than from attending the previously scheduled session "Jump-Starting Lambda Programming" (which sounds packed anyway). Although some speakers prefer questions and comments be asked at the end, Subramaniam prefers that questions be asked when they arise.

Subramaniam began with a quick summary of the basics of the Scala programming language. He showed that everything is an object in Scala by showing the Groovy/Ruby-like example 1.toString(). He stated that you can use Scala anywhere you use Java and should expect 40 to 60 percent less code than you'd write in Java. He added that, like Groovy, you can mix Scala and Java. He likes the conciseness and expressiveness of Scala.

The approach used in this presentation was not to necessarily provide a tutorial on basics of Scala, but rather to approach introduction of Scala via examples. In many ways, this felt like a presentation equivalent of a "recipes" or "cookbook."

Subramaniam's first real example was reading a file (he went for one of Java's ugly points early!): val stuff = Source.fromFile("sample.scala").mkString() [See this StackOverflow thread for differences between toString() and mkString()] There is no signs of exception handling. Like Groovy, Scala does not enforce catching or re-throwing/stating checked exceptions. Removing exception handling makes the code much more concise.

Subramaniam stated that "one of the things I really like about Scala is there is no ceremony to deal with." He described "ceremony" as the stuff you have to do before you can do the stuff you want to do. He pointed out that people teaching Java to someone else are reminded of how difficult Java can be to learn because there are so many aspects of ceremony to learn.

The next example Subramaniam showed was returning multiple values from a method. In this case, he wanted to return two names: "James" and "Bond." He showed creation of an immutable Tuple:

def createAgent() =
{
   ("James", "Bond")
}

He showed how the above Tuple could be accessed.

val agent = createAgent()
println(agent._1 + " " + agent._2)

Subramaniam showed what happens when he tried to access agent._3 in the code above: it led to a compile-time error because there aren't three fields. This was an example of a runtime error being moved to a compile-time error.

One of the Scala features that Subramaniam focused on that I also like is its requirement that method arguments be specified as mutable or immutable (val or var) when writing the signature. I liked the var modifier clear back when programming and hacking with Pascal and am glad to see this differentiation.

Subramaniam covered a "very convenient feature" that is on the borderline between "really cool" and "really scary": the implicit keyword. It can, of course, be difficult to know when implicit keyword kicks in, especially if it comes from an import. Subramaniam joked that its use helps improve "job security."

Another example was based on implementing a factorial method in Scala. As is almost always the case, the factorial was implemented with recursion. Subramaniam forced it to recurse enough times to lead to a StackOverflowError. He cited Structure and Interpretation of Computer Programs and then talked about how the code could be written in Scala so that it appears to be recursion, but the Scala compiler will optimize it to be a procedural loop. The @scala.annotation.tailrec annotation can be used to enforce that tail recursion applies, allowing for this compile time optimization to occur. This is pretty nifty, but it's also a reminder that recursion should not be used solely because it's cool.

Subramaniam stated that "Scala says XML should be treated with the respect it deserves" rather than forcing XML content into Strings. He then showed code in which a variable was assigned to an XML element directly without quotation marks. He showed how use of curly braces around that variable assigned directly to XML allows access to the body of that XML element. He said there is much more to Scala's XML support.

"Producing code that spits out XML should be given to people in prison" was Subramaniam's opening statement to introduce Scala's support for generation of XML. He showed how he could embed Scala code within curly braces within the defined XML. This allowed him to define a function that would use Scala trickery to easily build XML based on an underlying Map of data. That is impressive!

Traits are probably one of the most heralded aspects of Scala and Subramaniam covered them in his presentation. He stated that one of the problems with multiple inheritance was C++'s implementation of it. He talked about method pollution and showed how use of the with keyword, coupled with the extends keyword and trait keyword, supports traits.

Subramaniam showed how traits can be applied to individual instances rather than to a general class when so desired (when the instance is different than the general class). His example here was that dogs are friends and so need the trait at the class level while most cats are not friends and so he modeled his cat's individual instance with the friend trait rather than applying the fried trait to the Cat class.

Subramaniam stated that he'd not let anyone use Java who had not first read Effective Java. He said that Java has been fixed to meet the approaches described in Effective Java and that version described in Effective Java is known as Scala.

Subramaniam pulled off well one of the most challenging things I've seen in presentations. Most speakers who turn to their IDE quickly lose the audience as they lose themselves in the code and start talking to the monitor. Subramaniam, however, did a nice job of keeping the code samples small and displayed them with large font. This allowed for easy focus on the important things. His is one of the few code-heavy presentations I've seen that is easy to stay attentive to. The only downside is that these examples are not in the slides, but he said that they'll be available for download.

This was another presentation that was everything I had hoped for. I'm becoming motivated to play around with Scala again and picked up some nice ideas. It didn't hurt that Subramaniam is a skilled and practiced speaker and entertains his audience while educating them. Some speakers, even at this JavaOne 2012, have required extra effort on the audience's part to remain attentive, but that wasn't the case here.

JavaOne 2012: Modern Web Development with Play Framework 2.0

My second session on Tuesday was my first non-keynote session at JavaOne 2012 outside of the Hilton. Peter Hausel (Typesafe) gave the presentation "Modern Web Development with Play Framework 2.0" was held at Cyril Magon I in Parc 55. For some unexplained reason, they did not allow attendees into the room until ten minutes before the session started. It was a small room and ended up being over 3/4 or more full.

In a slide titled "tl;dr", the speaker talked about DRY, out-of-your-way configuration, avoiding bloat, avoiding verbosity, using Java 7, using fork/join (or Akka) and NIO, going asynchronous when possible, favoring immutability, favoring fluid interfaces, and questioning the status quo.

Play Framework 2 provides a "development console for RAD" and is "type checked all the way." Play 2.0 supports "asynchronous programming techniques" along with support for "front end technologies" (LESS, Clojure, Require.js, CoffeeScript).

Play is built upon and/or supports Java, Scala, akka, HTML5 Web Sockets, and Netty.

The speaker showed a slide stating, "Simple tasks should be simple, hard task should be possible, and focus on developer happiness." He then went on to show a slide on the "Development Console." One slide on the Development Console showed a compilation error and how the line of code with the error is highlighted within in the web browser. The error message appears at the top and the offending line is highlighted in red. He showed several different types of errors including those related to compilation of JavaScript/CoffeeScript code. One error provided a clear explanation of why certain JavaScript/CoffeeScript did not work in Microsoft Internet Explorer.

The speaker showed a provided template, but pointed out that this mechanism is extensible and organizations can create their own templates and plug-ins.

Hausel moved onto showing code examples. The code seemed fairly fluent, straightforward, and readable, even without having any significant experience with Play or Scala. I certainly could not write it right now, but I could read it. He showed implementation of a application controller (with several static functions) and model class and showed how to hook all of this up to a Redis plugin.

It was difficult at times to hear in this presentation due to competing sounds such as voices from nearby conference rooms and "everyday noises" within the room. The loud opening and slamming of doors in the back as late arrivals came in and others left early added to the difficulty (I'm not the only one particularly bothered by this as shown by this this Tweet that appeared about the same time I wrote the previous sentence). In general, this is type type of thing that could make the difference between selecting between two presentations in the future: all else being equal, I'll select the one in a room other than Parc 55 Cyril Magnon I.

I've read quite a bit of positive buzz in the blogosphere about Play Framework and I can see from this presentation that it definitely has some attractive features and attributes.

A Slicker Typesafe Stack: Q&A with Martin Odersky

Typesafe announced this morning that the Scala Language Integrated Connection Kit (Slick) has been added to its Typesafe Stack. Slick has been mentioned in Michael Azoff's Typesafe roadmap indicates the maturing of Scala and the ScalaDays 2012 presentation SLICK: Scala Language Integrated Connection Kit provides significant details about Slick as well as code examples of how to use it.

The "About" portion of the Slick web page states the following:

Slick is a modern database query and access library for Scala. It allows you to work with stored data almost as if you were using Scala collections while at the same time giving you full control over when a database access happens and which data is transferred. You can write your database queries in Scala instead of SQL, thus profiting from the static checking, compile-time safety and compositionality of Scala. Slick features an extensible query compiler which can generate code for different backends.

I had the opportunity to pose some questions to Scala creator and Typesafe co-founder Martin Odersky about Slick. It is exciting to think about what Slick offers based on Martin's answers (posted next) and based on the material available on the Slick website (tweeted by Martin yesterday).

Slick Q&A with Martin Odersky

Q: Is Slick open source?

A: Yes, Slick is an open source project.

Q: What is the licensing for Slick?

A: Slick is distributed under a BSD-style license. The license was chosen to be the same as Scala's to keep the hurdle for adoption low.

Q: Can Slick be used with databases other than those explicitly supported as listed in the press release (such as Oracle)? and Q: What steps must be taken to use a database other than those listed?

A: Yes. The session handling and "plain SQL" layer is database-independent. Compiling Scala code to SQL requires a Slick driver for the target DB. There is a BasicDriver implementation based on standard SQL which should support the majority of standard features of many database systems. Since all databases in practice deviate more or less from the SQL standard, custom driver implementations will be needed to make use of all features.

Q: Is Slick extensible to make use of an unsupported database transparent to the developer if certain extensions are implemented (in other words, can the community add support for other databases)?

A: User code can be written in a database-independent way, depending only on an abstract profile which is implemented by different database drivers. New drivers can easily be implemented by 3rd parties as separate projects.

Q: Are there plans in the future to support other databases out-of-the-box?

A: At the moment Slick is limited to JDBC-based SQL databases. We are planning to support different kinds of NoSQL databases with non-JDBC drivers in the future as part of the Slick core release. Drivers for high-end commercial database systems will be available as a commercial add-on from Typesafe.

Q: Is a JDBC driver required to use Slick or does the Slick driver for a particular database handle it completely?

A: All database connections are made through JDBC using the standard JDBC drivers for the respective database systems. This makes it easy to integrate Slick into existing platforms, e.g. for using container-managed data sources or sessions in JEE environments.

Q: Does Slick make Java and Scala ORM solutions unnecessary?

A: Slick is not a drop-in replacement for an ORM but we believe it can provide superior results in many cases. Traditional ORM solutions focus on making the database disappear from your application, giving you the illusion of working with a network of mutable objects in memory. This comes with the usual problems of mutable state in general, plus additional challenges caused by the large impedance mismatch between the relational and object-oriented worlds. Slick makes heavy use of immutable data structures and concepts from functional programming which are much closer to SQL, thus staying clear of most impedance mismatch problems while providing much of the power of an ORM.

Conclusion

There seem to be many great ideas incorporated into Slick and I think it may be the feature that finally motivates me to make time to try out Scala. Thanks to Martin for responding to my questions and to Laura Masterson for arranging for the opportunity to have my questions about Slick answered.

Software Development Posts of Interest - March 2012

This post references some of the recent blog posts and articles that have interested me. Topics include Java-specific topics such as Java EE, JavaFX, Scala, and Gradle as well as more general software development topics such as software patents and open source.

Why Software Patents are Evil

Simon Phipps summarizes in Why software patents are evil why patents in software may not make sense:

Patents may work in other industries, where the cost of innovation is so high that a temporary, state-sanctioned monopoly provides just enough time to gain a return on the investment. But that investment-return ratio has a completely different value for software. It turns out that software patents have little bearing on encouraging innovation. ... Software patents are ... bad news for most innovators in the software industry.

Phipps also looks at the relationship between software patents and open source software. He writes, "The problem is that open source software is defenseless against the anticompetitive abuse of patents."

Java EE 6 Versus Spring Framework

In the post Why is Java EE 6 better than Spring? Arun Gupta discusses why he believes developers should use Java EE 6 rather than the Spring Framework. Gupta begins the post by referencing several similar blog posts including Java EE wins over Spring and Why I will use Java EE (JEE, and not J2EE) instead of Spring in new Enterprise Java Projects in 2012.

Some of the feedback comments on this post are interesting because they demonstrate the differences of opinions between Java EE evangelists and Spring Framework evangelists (with comments from employees of both Oracle and SpringSource/VMWare among them). It is interesting to see the role reversal in this situation. Evangelists of the Spring Framework (even before it was so named) helped convince the Java enterprise development community of the problems with early J2EE, but now it seems the tables have turned and similar evangelism is advertising the "legacy" nature of Spring Framework as compared to modern Java EE.

Java EE 6 vs Spring - let's get ready to rumble provides another look at this post.

Oracle's Long-Term Intentions for Java

Paul Krill's Oracle lays out long-range Java intentions summarizes the "Oracle slide presentation entitled 'To Java SE 8 and Beyond!' posted on the QCon conference website." Based on Krill's summary, this presentation sounds very similar to the Oracle OpenWorld 2011 presentation From Java SE, 2012, to Java 12: Java SE Roadmap.

Reducing Memory Usage and Garbage Collections with -XX:+UseCompressedOops

Stuart Leneghan's post Reducing Java Memory Usage and Garbage Collections with the UseCompressedOops VM Option looks at the author's observation of the -XX:+UseCompressedOops HotSpot-specific JVM option "[reducing] the memory usage of the application by 14% and the number of garbage collections by 24%."

More on Java Tuning

Speaking of Java performance and memory tuning, Rupesh Ramachandran's post Java Tuning in a Nutshell - Part 1 provides a "JVM tuning cheat sheet" and categorizes JVM options into four categories: garbage collection, heap tuning, logging, and other performance.

The IBM DeveloperWorks article From Java code to Java heap is fairly comprehensive, providing background details on JVM memory handling and a focus on the impact of different Java collections on memory. This article also references the HotSpot option -XX:+UseCompressedOops as well as the similar IBM JVM option -Xcompressedrefs.

Understanding Garbage Collection is another recently-posted resource. This post is "the first of a series of 'Become a Java GC Expert' articles" and its focus is on introducing garbage collection in Java. The same site also hosts the blog post How to Analyze Java Thread Dumps. Figure Out Why Java is Eating CPU provides an interesting tip.

Scala

There continues to be a profusion of Scala posts. Recent posts include How Scala Can Improve Your Life, Is Scala making the right steps forward?, Scala creator Martin Odersky fends off critics of Scala's roadmap, Free online books for learning Scala, and Scala: Sink or Swim? Part 1. I have also seen new references to Twitter's Effective Scala.

Unit Testing

Neil Buesing's post How to Mock Final Classes in Unit Tests examines the problem that "both Mockito and EasyMock cannot mock classes (or methods) that are final." The feedback comments are also informative and discuss other available solutions to this issue: PowerMock), Groovy-based gMock, and JMockit.

Improved Java Stack Trace Presentation

Tomasz Nurkiewicz has posted two blog posts on how to improve Java stack trace experience using the Logback Project. Filtering irrelevant stack trace lines in logs demonstrates his "proof-of-concept" for filtering out selected stack trace frames using Logback and references the StackOverflow thread Cleaning noise out of Java stack traces. An older post, Logging exceptions root cause first, discusses a feature he contributed to Logback for displaying exceptions with root cause first rather than last.

A Peek at NetBeans 7.2

Geertjan Wielenga's NetBeans Java Hints: Quick & Dirty Guide provides a peek at a capability coming in NetBeans 7.2 for creating NetBeans hints.

Gradle

Last milestone for Gradle as it prepares for first major version cites the Gradle roadmap and states that the current version of Gradle ("1.0-milestone-9, released on 13th March 2012") "will be the final one" before Gradle goes into release candidate.

GroovyFX and JavaFX

Gradle is not the only product in the Groovy ecosystem with recent version advancement news. Dean Iverson has announced the GroovyFX First Official Release. He also shows how to use Grape to "grab" GroovyFX similar to the approach shown in my post Easy Groovy Logger Injection and Log Guarding.

Other interesting recent posts related to JavaFX include Example CSS Stylying in JavaFX, New in JavaFX 2.1: ComboBox, and Packaging JavaFX Applications as Native Installers.

Groovy and DevOps

In the post Groovy, A Reasonable JVM Language for DevOps, Geoffrey Papilion writes that Groovy provides the "JVM glue" he sought for "a simple JVM language that allows me to use any native object." After demonstrating use of Groovy for a "quick script to get data from JMX into ganglia fromSsolr," he concludes

So, if you're working in a Java with a bunch of Java apps, think about giving Groovy a chance for writing some of your monitoring tests, and metric collectors. It is a simpler language than Java to put together those little applications that can tell you how your system is performing, and well within the reach of your average DevOps engineer.

DNS for Software Developers

Doug Rathbone's post DevOps DNS for Developers – Now There’s No Excuse Not To Know is intended to help software developers become more familiar with the basics of DNS. This does seem like the sort of article one would except to be associated with the DevOps movement.

The Big Three JVM Languages

The Big Three – Scala, Clojure and Groovy is a blog post with observations about Groovy, Scala, and Clojure seeming to be the most popular JVM languages among Java developers based on two polls (Which alternate JVM language do you prefer? and Which JVM Language Is On Top?). Charles Oliver Nutter has added a feedback comment regarding JRuby being a more popular JVM language when you consider Ruby developers.

Java 7 WatchService

The post What’s New in Java 7: WatchService describes java.nio.file.WatchService and calls the related functionality "one of the more interesting ... new features in Java 7." This is a fairly concise post that quickly introduces the functionality and includes sample code.

Opinions on Rails, Hibernate, Google, JSON's License Agreement, and the Spanish Theory of Management

I started this post with reference to an opinion-oriented post on open source and patents. It seems symmetrically pleasing to close this post with references to other opinion-oriented pieces. Tyler Menezes discusses technical and cultural reasons he won't use Ruby on Rails in the simply titled post I will not learn Rails. James Whittaker provides a articulate and insightful post Why I left Google.

Rob Gordon is "not impressed" with Hibernate 4.1 ease of use. The Dodgy Coder blog ("Never trust a programmer in a suit") includes a post on the "Spanish Theory" of project management.

Brian Fox points out that JSON's license agreement states "The Software shall be used for Good, not Evil." Fox further points out that "compliance is impossible" and that "this isn't even open source." He asserts that "this additional clause adds an unnecessary complication" and I tend to agree. The folks in suits are not comfortable with objective statements in the license agreements.

Conclusion

I have summarized and linked to Java-specific and general software development posts of interest in this blog post. The software development industry continues to be ever-changing and full of news.

Typesafe Stack 2.0 Released: Q&A with Typesafe President and CEO

Typesafe issued a press release today including this initial paragraph:

Typesafe today announced the release of Typesafe Stack 2.0, the latest version of its open source software stack. Typesafe Stack 2.0 is a comprehensive platform for building applications in Java and Scala that can scale to the largest workloads in cloud computing and virtualized enterprise datacenter environments. The release adds the innovative Play web framework for the first time, and includes Akka event-driven middleware 2.0, with significant enhancements for building concurrent and distributed applications.

This newly released Typesafe Stack 2.0 might provide a nice way to introduce oneself to Scala while addressing modern development needs. I've long felt the best way to learn a new language, framework, or library is to use it in a practical situation. Jan Machacek made a similar point in the JavaWorld article Learn Scala with Specs2 Spring, where he discussed learning Scala as one used it with his company's Specs2 Spring Extension.

Because I'm new to Play, Akka, and even Scala, I welcomed the opportunity to ask the folks at Typesafe questions about the Typesafe Stack 2.0 from a beginner's perspective. The following questions were asked of and answered by Typesafe President and CEO Donald Fischer. With these questions, I tried to find out what I needed to know to determine the motivation for beginning use of Typesafe Stack 2.0 and where to start in my efforts to learn and use it.

Q&A with Typesafe CEO Donald Fischer

Question: What are the most compelling advantages of the Typesafe Stack 2.0?

Some of the most compelling advantages of the Typesafe Stack versus legacy platforms are:

• Strategies for working in a world of horizontal scale. Modern software needs to take advantage of more cores and more machines, rather than faster single cores.
• An emphasis on developer agility, productivity, and enthusiasm. Developers want to work quickly and focus on business logic rather than boilerplate.
• Fewer bugs. The Typesafe Stack has tools to avoid bugs up front. For example, Akka helps you avoid tricky thread synchronization issues, and Scala helps you write side-effect-free, typesafe code with fewer opportunities for error.
• An emphasis on pragmatic interoperability. The Typesafe Stack APIs can be used from Java or Scala or both; and they can be adopted incrementally. It's as simple as adding some jars to your project.

Question: How much familiarity with Scala is required to use Typesafe Stack 2.0?

While the Typesafe Stack includes Scala, and is built on a Scala foundation, both the Play web framework and Akka middleware offer native APIs for both Java and Scala. So developers can build applications that leverage all of the capabilities of the Typesafe Stack without any specific knowledge of Scala (though we don't think they'll be able to resist the added productivity that Scala provides once they get a taste).

Question: On a spectrum of 100% Java to 100% Scala with a combination of the two between those ends of the spectrum, what portion of the spectrum is supported by Typesafe Stack 2.0? (Can one use Typesafe Stack 2.0 with Java only?)

100% of the functionality in the Typesafe Stack frameworks (Akka and Play) is supported for both Scala and Java.

Question: What is the easiest way to get started using the overall Typesafe Stack 2.0?

We've put together a Getting Started Guide, here: http://typesafe.com/resources/getting-started/

Question: What online resources are available regarding the use of Typesafe Stack 2.0?

We've collected a variety of resources including videos from project contributors, commercial users, and the community here: http://typesafe.com/resources

Question: Are there any books available or planned that cover the individual products within Typesafe Stack 2.0 as well as the overall integrated stack?

Yes, we've accumulated a collection of books here: http://typesafe.com/resources/books We're proud that several of these books are authored by Typesafe employees, including Martin Odersky, Josh Suereth, Heiko Seeberger, and Philipp Haller.

Question: What is the licensing for Typesafe Stack 2.0 and is it consistent across the individual products and the overall stack?

The Typesafe Stack is 100% open source. It's complemented by the commercial Typesafe Subscription, which adds support, maintenance, and tools including the new Typesafe Console. The Typesafe Console is available exclusively to Typesafe Subscription customers.

Question: What potential enhancements are planned for Typesafe Stack 2.0?

Upcoming releases of the Typesafe Stack will include additional clustering features and enhanced support for building applications that adapt to elastic cloud environments.

Screen Images

I was provided with some images that I have posted next. Note that these display the Typesafe Console, which is only available via the Typesafe Subscription option.

My Own Thoughts and Observations

Typesafe Stack 2.0 appears to offer developers several advantages, one of which is the ability to learn the Scala language, the Play framework, and the Akka toolkit all while solving difficult problems associated with modern software development. The press release alludes to these problems in the sentence, "Typesafe provides the most scalable software platform designed for the computing architectures of the future -- multicore, parallel and cloud applications."

Typesafe's licensing model is a familiar one with significant product (the Typesafe Stack 2.0) available via an open source license and add-on tools available for a commercial subscription. The advantage of this is that a developer can "play" (no pun intended) with Typesafe Stack 2.0 and then later move to Typesafe Subscription as needed and desired. It has been my experience that, generally speaking, it is an advantage to have a large corporate sponsor of an open source product I am using. Corporate sponsorship tends to mean dedicated resources invested in improving and maintaining the product. Examples include the Spring Framework and Groovy (SpringSource), NetBeans and GlassFish (Sun/Oracle), Eclipse (IBM), etc. Typesafe's optional commercial support for Typesafe Stack 2.0 is potentially useful for customers, but Typesafe's apparent commitment to the product's development and maintenance is highly valuable as well.

Specific licensing information for the products of Typesafe Stack 2.0 can be found at the Typesafe Licenses page. As of this writing, this page reports that "Scala and the Scala IDE for Eclipse are available under the Scala License", Play and Akka are licensed with the Apache License, Version 2.0, and "Simple Build Tool (sbt) is available under the BSD license."

Conclusion

The press release, the answers to my questions above, and the plethora of resources available on the Typesafe site all imply a highly beneficial product. I am not in any way affiliated with Typesafe and I have not yet tried Typesafe Stack 2.0 out for myself, but it looks very promising. If nothing else, playing with it and possibly applying it to real problems might be one of the best ways to learn Scala, Play, and Akka, but one can always fall back to Java when using it if necessary.

Scala for 2012? Deciding Whether to Invest In a Programming Language

I have found it both interesting and rewarding to learn a new programming language or major framework on a roughly yearly basis. If forced to self-identify with any single programming language, it would be Java. However, over the years, I've used C and C++ fairly extensively and have used and learned enough to be dangerous about several other languages including shell scripting languages, Perl, JavaScript, Pascal, C#, Ruby, JRuby, Groovy, PHP, and Python. Of the latter group of languages (Ruby, JRuby, Groovy, PHP, and Python), Groovy has had the most practical benefit for me, but I have learned valuable idioms, best practices, and different ways of thinking from using the other languages.

In some years, I've not been as quick to learn a language in a year in which I've been learning either a major framework for that language or in a year in which a language I am familiar with undergoes significant changes. For example, Struts and the Spring Framework dominated my time as I learned each of them. JavaFX has similarly dominated my interest in recent weeks. When not working with a new language, I tend to focus on libraries and frameworks of the languages I am comfortable with. I have spent more time on Guava this year, for example.

Learning a new language does provide many benefits. However, these benefits don't come for free. There is always an opportunity cost associated with learning anything new. If a programming language is particularly different than what one is used to, this opportunity cost can be great. The opportunity cost can be manifest as many different things. It might be lower productivity than could be had using a known language. It might be missing out on learning a new framework, library, or approach in the more familiar language. The opportunity cost might be having to settle on fewer or choosing different features that better fit the new language. The opportunity cost may be as simple as not being able to do other things one would want to do and might have time to do if using a familiar language.

Because there are so many potential opportunity costs associated with learning a new programming language, I try to be careful about which I invest my time in. I typically have a compelling reason for learning a new language. Compelling reasons might include specific advantages of a language (such as PHP for many Web 2.0-centric projects) or widespread use and "employability" of that language. Other reasons might be to learn new techniques that can be adapted to more familiar languages. Perhaps the most compelling reason I've learned a new language has been to read and maintain code or scripts that I have handed to me and am assigned responsibility for.

For several years now, I've been somewhat curious about Scala, but have not yet committed myself to using it and learning it because other languages, frameworks, and tools have grabbed my attention. Typically, I've had some motivation that has made these tools, languages, or frameworks seem most worth my investment of time and energy. For example, the need to have a nice scripting language that meshes well in my Java development environment led me to Groovy. My attendance at JavaOne 2010 and JavaOne 2011, coupled with my interest in a modern GUI technology, has led to my interest in JavaFX. I spent time with Python after being in a position where I needed to read and modify Python scripts.

I recently welcomed the opportunity to pose some questions to Scala creator Martin Odersky related to what is in Scala that might motivate me (and others) to invest time and energy into learning Scala. As I articulated the questions I had for Martin, I realized that these are really the things that I informally look at when investigating a new language. I typically spend an hour to two finding a language's highest-level motivations first and only invest more time in that language if it seems to be a good potential fit for me. Martin has agreed to me posting my questions and his answers and they are shown next (I have added hyperlinks).

Question: What is the most compelling/motivating reason or reasons that one might want to invest time in learning Scala as opposed to continuing use of Java (mostly for applications in my case) + Groovy (mostly for development environment scripting in my case)? For example, Groovy appealed to me at a high level as a way to script with libraries, idioms, and syntax that I was comfortable with from Java application development experience.

There are actually quite a few different facets of Scala that individuals attach to for different reasons. Some are attracted by the succinct syntax and resulting productivity. Others gravitate to the stability of the JVM and runtime performance of a compiled language (versus an interpreted language, like Groovy), or the ability of a sophisticated type system to help programmers avoid errors that would otherwise crop up at runtime. Others find the functional style of programming to be a more natural way to reason about their application logic.

One of the strongest attractors, from a practical point of view, is that Scala (and the rest of the Typesafe Stack -- including Akka and Play) are designed to provide better tools to address the dual challenges of parallel and concurrent programming. With the advent of mainstream multicore/manycore hardware, and the increasing scale of applications that developers are charged to build, many industry developers are looking for higher level abstractions than threads and locks for building at this next scale. Many find that the functional style, immutable state, actor concurrency model, and other concepts at the heart of Scala make it simpler to build parallel and concurrent applications.

Question: What are Scala's biggest strengths, advantages, and innovative features?

At a high level, Scala seeks to be a pragmatic language that scales from the smallest scripts to the largest distributed systems.

One major thread of innovation in Scala is its unique blend of object-oriented Java with functional programming concepts. Scala's libraries build on this foundation to provide outstanding support for concurrency and parallelism, for example through the actor programming model and the built-in parallel collections introduced in Scala 2.9.

Scala's expressive type system and syntax helps developers build more reliable code and greatly increase extensibility, especially for library developers and those building domain-specific languages (DSLs).

Finally, it's important not to overlook the fact that Scala is deeply integrated with Java, supporting blended Scala/Java projects and allowing developers to apply their skills and investments in Java immediately when they start working with Scala.

Question: What are Scala's biggest weaknesses, disadvantages, and plans for improvement?

One of the challenges for a relatively young language like Scala is the maturity of tools. In particular, the Scala IDE for Eclipse has had its rough edges in the past -- one of the reasons that Typesafe, as the leading commercial contributor to Scala, has invested substantial resources in overhauling the IDE with version 2.0 (just released in December 2011).

Another challenge for adoption is that Scala does introduce with functional programming a new mode of thinking about programs, which takes some time to learn. It makes the transition gentle, because one can start writing Scala code like more concise Java code. But as Scala's native library ecosystem grows chances are that newcomers to the language will come across to some of its more foreign features before they have developed a good understanding. To avoid culture shock, we need to develop a set of best practices and good tutorials that help the transition. "Programming in Scala", which I have co-authored, is a comprehensive tutorial of the object/functional style. Cay Horstmann's "Scala for the Impatient", available as a free preview on the Typesafe site, is a pragmatic, fast-paced introduction.

Question: What situations/scenarios/use cases is Scala best and worst suited for?

As described above, Scala and its frameworks like Akka and Play really shine for building systems that need to scale on multiple fronts -- across cores, across machines in a cloud environment, and across large software teams.

Traditionally, one area where Scala or other JVM-hosted languages would not be considered well suited would be lower-level systems programming. But interestingly, we see evidence of forward-looking systems developers increasingly embracing managed runtime languages like Scala because they face fundamental challenges in building reliable systems for the era of multicore hardware and distributed deployments.

Martin's responses validate some of my own conclusions about Scala from reading posts by Scala enthusiasts and even some of the detractors. In terms of motivation, I have a difficult time believing that learning Scala primarily as a scripting language will be very motivating because I'm pretty happy with Groovy for scripting. However, for development of applications, I tend to use Java and not Groovy and I wonder if it's in that area where I'd be most likely to benefit from learning and using Scala.

Once I determine that a language is worth investing in, the next step is deciding how to best learn it. Reading about it is a necessity, but using it is what really helps me learn it and also what helps me identify the things I don't like about it. The trick is to come up with a somewhat realistic example that is easy enough to implement, but interesting enough to prove out some concepts. A "Hello World" is okay to get one's feet wet, but doesn't really test how the language fares for a developer's specific needs. My favorite initial examples are ones that actually provide benefit in addition to being a mechanism for learning. For example, when I was learning Groovy, I developed several scripts early on that were helpful to me as scripts in their own right regardless of the language they were written in. In those cases, I gained familiarity with Groovy while also receiving other utilitarian benefits.

The JavaWorld article Learn Scala with Specs2 Spring describes how a Java developer who uses the Spring Framework can use the author's company's Specs2 Spring for integration testing and also benefit from "an efficient and safe way to learn the patterns of object-functional programming with Scala." The entire premise of this article is exactly the kind of thing I like to do when learning a new language: combine legitimate benefit with learning of the new language.

One other thing to think about when trying out a new language is to ensure that one is trying it out for the correct situations. This was easy for me with Groovy: I tried out Groovy first in situations in which I wanted the power of the JVM or the scope of the JDK, but wanted a scripting-friendly language. A developer can quickly decide a language is "not good" simply because the situation in which the language used is not a great fit for that language. Related to this, another issue I try to keep in mind when learning a new language is that it's not fair to compare a language I know well and have spent thousands of hours with to a language that I've spent a few hours with. Unless I encounter some real deal-breakers early in the process, I try to not let "little problems" or things I don't like about the new language prevent me from giving it a real chance. An excellent recent post on this is Rob Pike's Esmerelda's Imagination. All that being stated, there are times I run into a true deal-breaker that makes me realize I should not invest any more time in a particular language because it doesn't fit my needs. That doesn't necessarily mean there's anything wrong with the language, but simply that it doesn't fit my needs well. An example of this would be using Java for a real-time system in Java's early days.

I think I'm almost ready to commit to spending more time with Scala. I'm not the type to make new-year resolutions, but it just so happens that it seems like the right time to give Scala a closer look. If I really do start to invest more time in Scala, my plan is to first re-read Bruce Eckel's Scala: The Static Language that Feels Dynamic and then read the A1 chapters of Scala for the Impatient, trying out and adapting examples. If I'm still interested in Scala after that, I can invest more at that time.

Do I still have reservations about spending time on Scala? Of course. One of my biggest concerns is best articulated by someone who actually seems to have tried out Scala. Cédric Beust states, "In my experience with Scala, it's hard not to like the language in the first week and it's hard to still be in love with it after reading the 700+ pages of a book about it." On the other hand, Casper Bang articulates well why I think I maybe I should spend time with Scala despite any other obvious motivations: "So I guess my point is, even if I do find Scala hyperbolish and biting over a bit too much; the majority of identifiable alpha-geeks that I track, are moving this way and as a practicing professional, I can not afford to ignore this."

The post Offbeat: Scala by the end of 2011 – No Drama but Frustration is Growing and the feedback comments related to that post are insightful and seem to reiterate some of the issues that Martin pointed out that Scala must deal with. In particular, when I look at the issue most likely to deter me from spending time on Scala, it is the risk that Scala may never take hold in mainstream development. If that turns out to be the case, then the primary advantage of learning Scala would be to change my way of thinking about things and that's not always necessarily worth the opportunity cost and other costs. This post and the feedback comments contain multiple sides of the same issue and are another reminder that I probably need to do more with Scala to decide for myself how I feel about it.

My plan as of right now is to invest significant time and effort into learning basics of Scala and applying it to some "realistic" examples. I even have plans to blog on what I learn. But, I have had these types of plans before and been distracted by some other shiny thing that has come my way. I think this time will be different, but I should know for certain by the end of 2012.