Skip to content

Language Choice Overload


I’ve been seeing a surprising trend in the articles that have come through my feed reader recently: evaluating JRuby, Groovy and Scala for use as primary languages in new, on-JVM projects.  This seems to be the new and trendy thing to write about.  I suppose it’s not really surprising that each of these languages is receiving such attention, they all deserve it.  What is surprising is that they are all put on the same playing field.  Of the three, only Ruby and Groovy are actual peers in terms of capability and design.  Syntactic differences aside, both languages do roughly the same things in fairly similar ways.  Scala on the other hand isn’t even in the same league.

This is about the point that most comparison rants conclude by saying “Scala is statically typed therefore it is completely different.  QED.”  We can actually go a bit deeper though.  Scala’s entire philosophy and reason for existence is divergent from dynamic, so-called “scripting” languages like Ruby or Groovy.  Scala is designed to be a mid-level, general purpose language.  By “general purpose” I mean something suitable for writing large applications, enterprise class stuff, etc.   Not suitable for writing operating systems or for creating quickie scripts.  In short, Scala is a peer for Java more than it is a peer for Ruby.

What I think is interesting is that Scala has a number of features which make it appear to be a dynamic language (such as implicit conversions, flexible syntax, type inference, etc).  These features give Scala the “feel” of a dynamic scripting language like Ruby without really sacrificing the strengths of the compiler and static typing.  It seems that this illusion is so effective as to actually have fooled most people into lumping Scala in with the dynamic crowd.  While this is good in the sense that Scala is getting more attention this way, it also leads to a rising misconception of what Scala is and what it’s good for.

Ironically, many of the use-cases being presented in these language comparisons are best solved by a mid-level language like Java or Scala, rather than high-level languages such as Ruby, Python or Groovy.  This actually seems to be leading to even more trouble in the world of language choice as the problem domain itself becomes blurry.  Many developers these days are trying to apply Ruby to large desktop application development, or (just as bad) apply Java to simple CRUD and RAD applications.  It’s the old adage: if all you have is a hammer, every problem looks like a nail.  Developers are starting to select languages based on “what’s hot” rather than what offers the most effective solution.

The rampant number of Ruby-Groovy-Scala comparisons is not the problem, but rather a symptom of a greater problem: language overload.  Even confining our search to the JVM, we can find so many wonderful languages of every size, shape and type-system.  All of these languages have their creators pushing their product as the solution to life, the universe and everything.  With so much noise pervading the language arena, it’s easy to see why many developers get confused when performing that crucial selection of tools.

Unfortunately, there doesn’t seem to be a “nice and easy” solution to the problem of language selection noise.  Every language will always have its proponents, people who try to sell the language as the cure for life.  Getting them to just shut up and realize the imperfection of their product is just about as likely as convincing the masses not to listen to them.  So it seems that for the foreseeable future, we will continue to see rants, comparisons and rationales taking languages X, Y and Z out of context and attempting to come to a sane conclusion.

Techniques of Java UI Development


Too often these days I see Java developers new to the psuedo-science of UI development finding themselves completely lost before they even get started.  There are a lot of misconceptions about the “best” and “easiest” way to create a professional UI in Java, and precious few resources which attempt to clear up the confusion.

In this article, I’m going to make use of the Swing framework simply because it’s more widely known.  All of the same techniques and processes apply to SWT with equal validity.  I’ll walk through the steps required to create a simple form UI in the easiest and most maintainable fashion.  I’m well aware that there are faster ways of doing this, but in my experience, this process will lead to more maintainable and less rigid UIs.

Note: These steps will obviously be different if you’re working in a team or with a designer.  The intention of this article is not to present the “be all, end all” of UI design practices, but rather to be a set of guidelines for the common-case developer.


It may surprise you, but the very first step in creating a UI is design.  You have to know fairly precisely how you want the UI to look and (more importantly) behave.  This step is more than just drawing a few mockups in Illustrator.  This is sitting down and hashing out what you want the controls to do when the window is resized, if the state of any controls should be tied to that of others, whether your labels LEFT aligned or RIGHT, etc.  Often I find the easiest way to start is with a diagram:


This is what my diagram would look like, but it’s important to note that this isn’t a “one size fits all” style.  The point of the diagram is to give you a medium to lay out the semantics of a panel and to help you understand just what it is you have to do.  This step becomes invaluable later on as you start actually writing code.

The important thing about this diagram is that it is annotated.  Anyone can just draw a picture of what they want the UI to look like, what components to use, how they should be spaced.  The real meat of the question is not what does it look like, but how does it behave.  One of the biggest questions Java UI developer have to answer (as opposed to, say .NET developers) is how do the controls behave when the form is resized.  This is a much more complicated question than “where should the component be placed” or “how should it look”.  In essence, the question is asking “what sort of layout manager configuration do you need?”

There are two directions which need to be considered: vertical and horizontal resize.  This may not be news, but it’s something that a lot of developers (myself included) seem to forget.  The way the form scales horizontally is just as important as how it scales vertically, so it is critical that these considerations are dealt with in the design phase.  You’ll notice on my diagram that I have annotated almost every component with scaling constraints, dictating visually how the component will behave as the form changes size.  For example, all but one of the text fields scale out horizontally, but remain with a fixed height.  The one text field which does not scale horizontally is annotated so that it remains with completely fixed dimensions, both vertical and horizontal.  It’s also important to note that the City text field scales horizontally, “pushing” the State combo box as it does so.  Thus the state selection is always right aligned, the city label is left aligned, and the intervening space is filled with the city text field.  This sort of “resize mapping” (to coin a phrase) must be considered before any code is written.

You’ll notice that there is just a single annotation indicating behavior when the form resizes vertically.  This is because, like most form-based UIs, there isn’t really a good way to deal with this situation.  In this case, I just drew a line through the form where I thought I saw the most logical split and indicated annotatively that this “non-component” should be what scales vertically.  Thus the buttons remain fixed to the bottom, while the remainder of the components build down from above.  Some forms have text areas (multi-line text fields) which may scale vertically, filling this space.  Our form however has no components which logically scale in the vertical direction, thus we invent a non-component which fills the gap in our imagination.  This non-component will only be reflected in the layout constraints, we won’t have to add anything extra to the panel itself.

When drawing this diagram, note that I wasn’t afraid to make mistakes and then annotatively clarify them.  For example, I made the form to narrow to clearly express the intent of the layout.  The City and State fields take up more room than I expected.  Rather than starting from scratch, I just draw the fields as it seems most intuitive and then indicate with arrows that they should be aligned with the other text fields.  Likewise, the Line 1 and Line 2 fields should actually stretch all the way to the edge of the section.  This wasn’t clear in the diagram, so I added the –| annotation to remind myself of this fact.  Always remember that we’re not trying to make an unambiguous specification, just a reminder to ourselves.  It’s a design aid, nothing more.

The final bit of annotative goodness which needs to be observed is the “disables” marker attached to the Address checkbox and the section below it.  This marker indicates some basic UI state behavior: when the checkbox is selected, the section will be enabled; otherwise the section below (and all its components) will be disabled and no data may be entered.  Note that the annotation doesn’t say “clears” or “resets”, since we just want the section to be disabled and ignored.  Someone may disable the address section only to realize later (prior to saving) that they actually do need to enter an address.  They would likely want all of their previous changes to still be there, rather than completely lost.

Notice what we didn’t annotate here.  We didn’t clutter our design with intuitive concepts like “Save button saves the contents and closes the window”.  Rather, we left that up to our imagination and (likely) prodigious memory.  Remember that this diagram is for our use, not our manager or the other developers in our team.  If we were building a diagram for external consumption, we would have had to make an effort to be more clear.  As it is, we can trust ourselves to build a UI that makes sense according to convention.

First Steps

So we have our design diagram in hand, it’s finally time to consider some code.  It’s usually around this time that developers start thinking about what tools to use and how they can be of help.  Let me start out by saying flat-out that I am not in favor of any graphical UI design tool.  Don’t get me wrong, I think Matisse is a brilliant bit of engineering and a credit to the entire NetBeans team, but it’s not a silver bullet.  In fact, I don’t even think it’s a bullet worth firing.  I could create the code for the diagramed UI in a few minutes using Matisse, but what would the code look like?  Would it be code worth coding?


javax.swing.GroupLayout jPanel1Layout = new javax.swing.GroupLayout(jPanel1);
          .addComponent(jTextField4, javax.swing.GroupLayout.DEFAULT_SIZE, 376, Short.MAX_VALUE)
          .addComponent(jTextField3, javax.swing.GroupLayout.DEFAULT_SIZE, 376, Short.MAX_VALUE)
            .addComponent(jTextField5, javax.swing.GroupLayout.DEFAULT_SIZE, 282, Short.MAX_VALUE)
            .addComponent(jComboBox1, javax.swing.GroupLayout.PREFERRED_SIZE, 
                 javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE))))
        .addGap(18, 18, 18)
        .addComponent(jTextField6, javax.swing.GroupLayout.PREFERRED_SIZE, 93, 

Oh yeah, I’m looking forward to working with that code.  What’s actually worse is you can’t work with that code.  NetBeans prevents you from editing the auto-generated sections of the code.  Meaning if Matisse got it wrong (and it did a couple times during the construction of the screenshot), there’s no way for you to fix it by hand.  And even assuming you drop back to your favorite external editor to make your fix, the next time you open the file in NetBeans, your changes will be overwritten.  Matisse is a totally dominating, uncompromising beast that takes over your UI and doesn’t let go.

Honestly, this isn’t a stab at NetBeans in any way.  Matisse does a fine job auto-generating its code and it’s amazingly good at inferring layout constraints based on convention and control placement.  It’s no substitute for fine-grained manual control however.  People may argue that “UI design is a visual task”, but that’s what the design diagram is for.  I’ve worked with some fairly complex Swing UIs in my time, and let me tell you that if you don’t know how to write the code by hand, you’ll never be able to maintain it.  And if you can’t maintain your UI code, that’s going to cause tons of problems down the road.  So no quick and easy tools for our UI-making.

If we’re going to write the code by hand (and we are), then we’re going to need to decide which layout manager(s) to make use of.  This is where the diagram can be extremely helpful.  Just looking at our design suggests a grid based approach, a subpanel (for the address) and a footer panel for the buttons (probably using something like FlowLayout).  Working from the high-level down to the fine-grained details:

  1. From top down: we have a body, some empty space which stretches on resize and a footer section.  This suggests the use of BorderLayout with the “body” as the CENTER constraint and our button panel as SOUTH
  2. Button panel appears to keep the components centered, so FlowLayout would be the most appropriate
  3. Body panel seems to be a grid of two columns, one for the labels and one for the text fields.  The Address component spans both grids with a left offset of 15-20 pixels.  Below this is the address panel which spans both columns and stretches to fill.  The address panel is not set to stretch vertically, but is rather attached to the top of its cell, allowing empty space to stretch below it
  4. Address panel appears to be a grid divided into four columns.  The first two rows have text fields which span three columns.  The bottom row contains a text field which also spans three columns, but does not stretch to fill

And no, I’m not concerned with resolution independence here.  After all, if Apple doesn’t care, why should I?  :-)

This process mainly depends upon familiarity with layout managers and some experience with form layout.  I happen to know that some of the most powerful layout managers are grid based, so I try to fit most UI designs into a grid.  I also know that Swing comes with a very nice (if limited) default layout manager called BorderLayout.  Many high-level layout constructions fall into a category of problems which are trivial to manage with BorderLayout (like our button footer).  There really are a number of patterns which can be kept in mind during this layout process, but in the end it all comes down to experience.  Once you’ve built a form-based UI, the steps involved in creating another become somewhat instinctive.

We’ve already specified two of the three layout managers we will need for this UI.  All that remains is to select a grid-style manager which can accommodate both fixed and fluid constraints.  We could use GridBagLayout, but for reasons which should be obvious, I like to avoid that one.  Unfortunately, Swing doesn’t really have another grid layout which is powerful enough to accomplish our goals.  So we look outside of the core Swing API.

There are a number of third-party layout managers available, but the one I really favor is a layout manager I ported from SWT a number of years ago.  SWT’s GridLayout is basically most of the power of GridBagLayout, wrapped in a clean and intuitive API.  It’s more than sufficient for our purposes, and it won’t needlessly gum up our code with dozens of verbose constraint definitions.

Fleshing it Out

With all three layout managers chosen and most of the constraints solidified, it’s time to get our hands dirty and actually write some code.  For simplicity of example, we’re just going to put everything into a single class with a main method.  This main method will simply set the look and feel (avoiding metal) and launch the frame:

public static void main(String... args) {
    EventQueue.invokeLater(new Runnable() {
        public void run() {
            try {
            } catch (ClassNotFoundException e) {
            } catch (InstantiationException e) {
            } catch (IllegalAccessException e) {
            } catch (UnsupportedLookAndFeelException e) {
            new ContactDetails().setVisible(true);

As per convention, all of our components will be created and initialized in the class constructor.  Some people are proponents of the init() or initComponents() convention, but I personally don’t see that it serves any purpose.  If you’re just calling the method from the constructor anyway, why bother?

You’ll notice that we’ve wrapped the entire launch sequence in an invokeLater()This is extremely important.  Swing (or rather, AWT) manages the entire event dispatch queue for you in separate threads.  It’s not like SWT where the event dispatch is manually, er…dispatched.  This means that the main thread is not in fact the EDT (event dispatch thread).  If we just made a call to our constructor within the main thread itself, we would be creating components and interacting with Swing in a thread other than the EDT.  Swing is pretty good at making sure that the event dispatch still works, but odd bugs can creep in around the edges.  Ever wonder why the setVisible(true) invocation sometimes blocks and doesn’t at other times?  This is usually due to the differences between an in-EDT invocation and a main thread call.  Romain Guy turned me on to this misunderstood bit of Swing usage, and I’ve been using it ever since.  Believe me when I say that you’ll save yourself a world of hurt by making sure you’re square with the EDT.

Now that we’re sure our invocations are properly wrapped, we can get started writing the UI layout code, adding the components to the frame.  Honestly, this code is more than slightly verbose and repetitious, so I’m not going to reproduce all of it.  This is just the interesting stuff:

setSize(400, 265);
JPanel body = new JPanel(new SWTGridLayout(2, false));
body.add(new JLabel("First Name:"));
JTextField firstName = new JTextField();
SWTGridData data = new SWTGridData();
data.grabExcessHorizontalSpace = true;
data.horizontalAlignment = SWTGridData.FILL;
body.add(firstName, data);
body.add(new JLabel("Last Name:"));
JTextField lastName = new JTextField();
data = new SWTGridData();
data.grabExcessHorizontalSpace = true;
data.horizontalAlignment = SWTGridData.FILL;
body.add(lastName, data);
JCheckBox address = new JCheckBox("Address");
data = new SWTGridData();
data.horizontalSpan = 2;
data.horizontalIndent = 15;
body.add(address, data);
JPanel addressPanel = new JPanel(new SWTGridLayout(4, false));
data = new SWTGridData();
data.grabExcessVerticalSpace = true;
data.horizontalAlignment = SWTGridData.FILL;
data.verticalAlignment = SWTGridData.BEGINNING;
data.horizontalSpan = 2;
body.add(addressPanel, data);


Well, this isn’t quite like our diagram, but it’s close enough.  Remember that the diagram is only a guide.  It’s purpose is to focus your thought and allow you to create the layout constraints.  It’s never intended to be a hard-and-fast spec.

You’ll notice how much more readable the manually written code is than its Matisse-generated counterpart.  It may be repetitive and annoying, but it’s very readable, very maintainable.  We could actually add a little bit of abstraction here (e.g. createGridData()) to make things even more readable, but that’s overkill for this example.  Actually, not only is this code readable and maintainable by myself, but I can also check it into a shared repository and other people (potentially using different editors) can make changes to the layout and UI logic and expect them to actually work.  I’ve had nothing but bad experiences when using UI builders in a team setting, especially builders like Matisse which rely on external meta files.

One thing that is worth calling attention to is that magic number pair in the setSize() invocation.  Of course, I could have used pack(), but that rarely sizes a frame as something which looks pleasing to the eye.  I’ve found that the easiest way to get a frame which is sized nicely for most platforms is to put in some easy default width and height (say, 400×400), then once the layout is fixed, size the form by hand.  Literally run the form and resize the window until everything looks good.  Once that’s done, screenshot it and measure the width and height in Paint.  :-)   It may sound crude, but it works surprisingly well.  Of course, the size will have to change a bit, depending on which platform the app is running on, but this is easy enough to handle.  Usually I repeat the process on each platform, taking the largest width-height pair as making that the fixed standard for all platforms.


And there you have it, a simple Java form UI created with minimal fuss and maximum compatibility.  More importantly, the techniques presented in this article can be applied to more UIs in future, and not just forms.  All of us at some point have to build a basic Swing UI, and it’s best if we’re comfortable doing so and able to create something that’s worth keeping around.  Hopefully the concepts I have presented will be useful to you the next time you find yourself faced with a similar situation.

Excellent Overview of Functional Programming


I just ran into an article on DZone that totally threw me off my chair in terms of content.  It’s titled (ambitiously enough) “Functional Programming For the Rest of Us“.  Basically the article attempts to explain many of the common FP techniques in terms that imperative programmers can understand.  More importantly, it motivates these explanations with a long and rambling set of real-world reasons.  It’s extremely long, extremely involved and well worth the read.

It’s worth noting that the author claims to be presenting his explanations in Java, but is in fact devising an extension of Java to represent FP constructs more concisely.  He does say though that this is for clarity only and it is possible to write purely functional programs in Java (stateless) “…if you felt particularly masochistic.”  Personally, I wish he had stuck with the masochistic route and avoided the invention of syntax extensions (or better yet, just used Scala); but regardless, his intent is clear.  Anyway the explanations themselves are not where the real meat of the article is.

The really interesting bit is how the author motivates FP through a combination of real-world examples and lengthy reasoning.  I’ve been sold on the benefits of functional programming for a long time now, but I’ve never seen so many supporting arguments thrown into a single batch.  For those of you still skeptical about the benefits of writing side-effect-less code in Scala, this article is for you.

So grab yourself a cup of coffee and a box of donuts (it’ll take you about that long to finish the article), and slog your way through.  Trust me, it’s worth the effort.  :-)

Roundup: Scala for Java Refugees


To be honest, I’m somewhat kicking myself for writing this post.  As I’ve said many times: roundup posts are for people who are too lazy to write real content.  I can’t tell you how many blogs I’ve come across which have a roundup-to-post ratio of easily 3:1.  You know it’s a bad sign when sites start having roundups of their roundups…

Meta-roundups aside, I decided (after much deliberation) that a single post linking to all six parts of the series would be useful to one or two people.  So if you like to save things with or even plain-old-bookmarks (POBMs for short), this is the one!  And if no one finds it useful, eh, I suppose Google probably likes it. 

Of course it’s always possible that you subscribe to my way of looking at things.  If you hate roundups as much as I do, skip this article and go read something useful.

Introductory article giving motivation for learning Scala and some first steps to “get your feet wet” in the language.

Looking at Scala’s syntax in a little more detail.  Properties, variables, methods, classes and constructors all find their home here.  We also touch on Scala’s import statement (which is a vast improvement over Java’s).

Scala’s method syntax is far too powerful to cover in a single post.  Part 3 goes into more detail, as well as introducing the concept of the singleton object and explaining how Scala really doesn’t have statics at all.

Pattern matching is one of the most useful constructs in the entire language.  Having a good understanding of it is critical to utilizing Scala to its full potential.  This article covers some basic pattern matching, case classes and a bit of exception handling.  There are a lot of very interesting comments on this post, so be sure to scroll all the way down!

Getting further away from perfect parity with Java, this article looks at traits (Scala’s more powerful substitute for interfaces) and just skims the surface of type theory applicability in Scala.

This article throws caution to the wind and picks up all the fun, Scala-specific topics I didn’t cover throughout the rest of the series (such as functionals, implicit type conversions, symbolic method names, etc).  This is my favorite of the series, simply because it covered many of the really interesting topics.

Scala for Java Refugees Part 6: Getting Over Java


Thus follows the sixth and final installment of my prolific “Scala for Java Refugees” series.  After this post, I will continue to write about Scala as the spirit moves, but I don’t think I’ll do another full-length series focused entirely on this one topic.  It’s a surprisingly exhausting thing to do, tying yourself to a single subject for so long.  (insert piteous moans from my keyboard)  Anyway, enough of my whining…

To be honest, I’ve been looking forward to this article from day one of the series.  This is the article where we get to open the door on all sorts of wonderful Scala-specific goodies.  So far, the focus has been mostly on areas where Scala’s semantics more-or-less parity Java’s.  In this article, we’ll look at some of the many ways in which Scala surpasses its lineage.  It’s time to get over that old girlfriend of yours and join me in the new tomorrow!

Class Extensions

There has been some chit-chat around the Java communal fireplace talking about adding class extensions to Java 7.  The basic idea is that classes need not have fixed members, but that methods can be weaved into the class or instance depending on imports.  This is similar to the concept of “open classes” supported by highly dynamic languages like Ruby:

class String
  def print_self
    puts self
"Daniel Spiewak".print_self    # prints my name

This funky looking sample is actually adding a new method to the String class (the one already defined by the language) and making it available to all instances of String in the defining scope.  Actually, once this class definition executes, the print_self method will be available to all instances of String within any scope, but let’s not be confusing.

Obviously, Java class extensions have to be a bit more controlled.  Things are statically typed, and what’s more there are some hard and fast rules about namespaces and fully-qualified class names.  The compiler will actually prevent me from creating a class with the same fully qualified name as another.  The main proposal seems to be some sort of variation on static imports, with the use case being things like the Collections.sort(List) method.

As one would expect from a language not tied to such heavy legacy baggage, Scala has managed to solve the problem of class extensions in a very elegant (and type-safe) way.  Actually, the solution took a lot of inspiration from C#, but that’s not important right now.  The ultimate answer to the problem of class extensions is…implicit type conversions.

Scala allows you to define methods which take a value of a certain type in as a parameter and return a value of a different type as the result.  This in and of itself isn’t so unique until you add the real magic.  By declaring this method to be implicit (which is a modifier keyword), you tell the compiler to automatically use this conversion method in situations where a value of type A is called for but a value of type B was passed.

Maybe an example would clear this up:

implicit def str2int(str:String):Int = Integer.parseInt(str)
def addTwo(a:Int, b:Int) = a + b
addTwo("123", 456)

Notice the type “error” in the final line.  With this call, we are passing a String value to a method which is expecting an Int.  Normally this is frowned upon, but before the compiler throws a fit, it takes one last look around and discovers the str2int method.  This method takes a String, returns an Int and most importantly is declared implicit.  The compiler makes the assumption that however this method works, it somehow converts arbitrary String values into Ints.  With this bit of knowledge in hand, it is able to implicitly insert the method call to str2int into the output binary, causing this sample to compile and return 579 as the final value.

Now if that were all implicit type conversions were capable of, they would still be pretty amazing.  But fortunately for us, the cleverness doesn’t end there.  The Scala compiler is also capable of intelligently finding the type you need given the context; more intelligently than just relying on assignment or method parameter type.  This is where implicit type conversions become the enabling factor for extension methods.

Let’s imagine that I want to duplicate my Ruby example above in pure Scala.  My end goal is to “add” the printSelf() method to the String class.  This method should be usable from any String instances within the enclosing scope (so enabling the literal/call syntax we had in Ruby).  To accomplish these ends, we’re going to need two things: a composing class containing the extension method and an implicit type conversion.  Observe:

class MyString(str:String) {
  def printSelf() {
implicit def str2mystring(str:String) = new MyString(str)
"Daniel Spiewak".printSelf()

I’d call that powerful.  Here the compiler sees that String does not declare the printSelf() method.  Once again, before it blows up it looks around for an implicit type conversion which might yield something with a printSelf() method.  Conveniently enough, there is just such a conversion method declared in scope.  The compiler adds the call, and we’re none-the-wiser.  As far as we’re concerned, we just called the printSelf() method on a String literal, when actually we were invoking the method on a composing instance which wraps around String.

Implicit conversion methods are just that, fully-functional methods.  There are no limitations (that I know of) on what you can do in these methods as opposed to “normal” methods.  This allows for conversions of arbitrary complexity (though most are usually quite simple).  Oh, and you should note that the compiler checks for conversions solely based on type information, the name is not significant.  The convention I used here (typea2typeb) is just that, a convention.  You can call your implicit conversion methods whatever you feel like.

Operator Overloading

Moving right along in our whirl-wind tour of random Scala coolness, we come to the forgotten island of operator overloading.  Founded by mathematicians accustomed to dealing with different operational semantics for identical operators, operator overloading was abandoned years ago by the developer community after the fiasco that was/is C++.  Until I saw Scala, I had assumed that the technique had gone the way of lazy evaluation (another Scala feature) and pointer arithmetic. 

Some languages like Ruby support operator overloading in a very limited way, but even they tend to discourage it for all but the most hard-core use cases.  Scala on the other hand is really much closer to how mathematicians envisioned operator overloading in Turing-complete languages.  The distinction is simple: in Scala, method names can contain arbitrary symbols.

This may seem like a trivial point, but it turns out to be very powerful.  One of the leading problems with operator overloading in languages like C++ and Ruby is that you cannot define new operators.  You have a limited set of operators with hard-coded call semantics (less-so in Ruby).  These operators may be overloaded within carefully defined boundaries, but that’s all.  Neither Ruby nor C++ succeed in elevating operator overloading to the level of a generally useful technique.

Scala avoids this trap by lifting the restriction against arbitrary operators.  In Scala, you can call your operators whatever you want because there is no special logic for dealing with them hard-coded into the compiler.  Little things like * precedence over + and so on are hard-coded, but the important stuff remains flexible.

So let’s imagine that I wanted to define an insertion operator in Scala similar to the infamous << in C++.  I could go about it in this way:

implicit def ps2richps(ps:PrintStream) = new RichPrintStream(ps)
class RichPrintStream(ps:PrintStream) {
  // method with a symbolic name
  def <<(a:Any) = {
val endl = '\n'
System.out << "Daniel" << ' ' << "Spiewak" << endl

Wow!  We can actually write code as ugly as C++ even in fancy, new-fangled languages!  Obviously we have an implicit type conversion here (see above if you weren’t paying attention the first time).  More interesting is the <<(Any) method declared within the RichPrintStream class.  This is actually a proper method.  There’s no magic associated with it nor any funky limitations to bite you in the behind when you least expect it.

Looking down a bit further in the code, we see the “nicely” chained PrintStream invocations using the <<(Any) method and the implicit conversion from PrintStream to RichPrintStream.  It may not look like it, but these are actually method calls just like the block-standard var.method(params) syntax.  The line could just as easily have looked like this:

System.out.<<("Daniel").<<(' ').<<("Spiewak").<<(endl)

Of course, I’m not sure why we would prefer the second syntax as opposed to the first.  This just illustrates the flexible nature of Scala’s invocation syntax.  You can actually extend this concept to other methods.  For example:

class Factory {
  def construct(str:String) = "Boo: " + str
val fac = new Factory()
fac construct "Daniel"
// is the same as...

With methods which only take a single parameter, Scala allows the developer to replace the . with a space and omit the parentheses, enabling the operator syntax shown in our insertion operator example.  This syntax is used in other places in the Scala API, such as constructing Range instances:

val firstTen:Range = 0 to 9

Here again, to(Int) is a vanilla method declared inside a class (there’s actually some more implicit type conversions here, but you get the drift).


Mathematics defines a structure such that 2 or more values are contained in an ordered list of n dimension (where n is the number of values in the “list”).  This construct is called an n-tuple (or just “tuple”).  This is obviously a construct which is easily emulated in code through the use of an array or similar.  However the syntax for such constructions has always been bulky and unweildy, eliminating raw tuples from the stock toolset of most developers.  Shame, really.

Tuples are fundamentally a way of pairing discrete pieces of data in some sort of meaningful way.  Theoretically, they can be applied to many different scenarios such as returning multiple values from a method or examining key-value pairs from a map as a single, composite entity.  Really the only thing preventing programmers from exploiting the power of such simple constructs is the lack of an equivalently simple syntax.  At least, until now…

val keyValue = ("S123 Phoney Ln", "Daniel Spiewak")
println(keyValue._1)   // S123 Phoney Ln
println(keyValue._2)   // Daniel Spiewak

In this example, keyValue is a so-called 2-tuple.  Scala declares such values to be of type (String, String).  And yes, that is an actual type which you can use in declarations, type parameters, even class inheritance.  Under the surface, the (String, String) type syntax is actually a bit of syntax sugar wrapping around the Tuple2[String, String] type.  In fact, there are 22 different “n-tuple types” declared by Scala, one for each value of n up to (and including) 22.

Tuples don’t have to be all the same type either.  Here are a few tuples mapping between integer literals and their String literal equivalents:

val tuple1 = (1, "1")
val tuple2 = (2, "2")
val tuple3 = (3, "3")
val (i, str) = tuple1
println(i)     // 1
println(str)   // "1"

What ho!  The simultaneous declaration of values i and str is another bit of Scala syntax sugar one can use in dealing with tuples.  As expected, i gets the first value in the tuple, str gets the second.  Scala’s type-inference mechanism kicks in here and infers i to be of type Int and str to be of type String.  This is inferred from the type of the tuple1 value, which is (Int, String).

So what are they good for?  Well it turns out Scala allows you to put tuples to good use in a lot of ways.  For example, returning multiple values from a method:

class Circle {
  private val radius = 3
  def center():(Int, Int) = {
    var x = 0
    var y = 0
    // ...
    (x, y)

Scala has no need for clumsy wrappers like Java’s Point class.  Effectively, the center() method is returning two separate values, paired using a tuple.  This example also showcases how we can use the tuple type syntax to specify explicit types for methods, variables and such.

The Map API can also benefit from a little tuple love.  After all, what are maps but effective sets of key-value tuples?  This next example shows tuples in two places, both the map iterator and the Map() initialization syntax:

val tastiness = Map("Apple" -> 5, "Pear" -> 3, "Orange" -> 8, "Mango" -> 7, "Pineapple" -> 8)
println("On a scale from 1-10:")
tastiness.foreach { tuple:(String, Int) =>
  val (fruit, value) = tuple
  println("    " + fruit + " : " + value)

Remember our old friend foreach?  (think back to the first article)  We’ll look at the semantics of this a bit more in a second, but the important thing to focus on here is the map initialization syntax.  Scala defines Map as an object with an apply() method taking a varargs array of tuples.  Got that?

The declaration for the object with just this method might look like this:

object Map {
  def apply[A,B](tuples:(A, B)*):Map[A,B] = {
    val back = new HashMap[A,B]
    tuples.foreach(back.+=)    // iterate over the tuple Array and add to back

The apply() method is going to return a new Map parameterized against whatever the type of the specified tuples happens to be (in this case String and Int).  The * character on the end of the parameter type just specifies the parameter as varargs, similar to Java’s “…” notation.

So all the way back to our tastiness example, the first line could be read as: declare a new value tastiness and assign it the return value from the expression Map.apply(…) where the parameter is an array of tuples.  The overloaded -> operator is just another way of declaring a tuple in code, similar to the (valueA, valueB) syntax we saw earlier.

Higher-Order Functions

Contrary to popular opinion, the term “higher-order function” doesn’t refer to some sort of elitist club to which you must gain entrance before you can understand.  I know it may seem that way sometimes, but trust me when I say that higher-order functions are really quite easy and surprisingly useful.

Taking a few steps back (so to speak), it’s worth pointing out that any Java developer with a modicum of experience has employed the patterns allowed by higher-order functions, knowingly or unknowingly.  For example, this is how you declare listeners on a JButton using Swing:

JButton button = new JButton("Push Me");
button.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent e) {
        System.out.println("You pushed me!");

This example passes an instance of an anonymous inner class to the addActionListener() method.  The sole purpose of this inner class is to encapsulate the actionPerformed(ActionEvent) method in an object which can be passed around.  Effectively, this pattern is a form of higher-order function.  addActionListener() accepts a single argument (called a functional) which is itself a function delegate encapsulating a block of statements (in this case, one println()).

Of course, this isn’t really a higher-order function since Java doesn’t allow functional values.  You can’t just pass a method to another method and expect something to happen (other than a compiler error).  This sort of anonymous inner class delegate instance pattern is really like a distant cousin to proper functionals.

Let’s assume for one blissful moment that we could rewrite Swing to take full advantage of Scala’s syntax.  Let’s pretend that we changed the addActionListener() method so that it actually would accept a true functional as the parameter, rather than this ActionListener garbage.  The above example could then condense down to something like this:

val button = new JButton("Push Me")
button.addActionListener((e:ActionEvent) => {
  println("You pushed me!")

Instead of a bulky anonymous inner class wrapping around our block of statements, we pass an anonymous method (a method without a name declared in-place similar to anonymous inner classes).  This method takes a single parameter of type ActionEvent and when called performs a simple println().  It is effectively the same as the Java example, except with one tenth the boiler-plate.

We can actually condense this example down even farther.  We can take advantage of some of the flexibility in Scala’s syntax when dealing with function parameters and remove some of those nasty parentheses (after all, it’s Scala, not LISP):

val button = new JButton("Push Me")
button.addActionListener { e:ActionEvent =>
  println("You pushed me!")

Concise and intuitive, with no nasty surprises like only being able to access final variables (Scala anonymous methods can access any variable/value within its enclosing scope).  In fact, what we have here is currently the focus of a great deal of controversy within the Java language community.  This, dear friends, is a closure.

Wikipedia’s definition falls a little bit short in terms of clarity, so let me summarize: a closure is exactly what it looks like, a block of code embedded within an enclosing block which logically represents a function (or method, the terms are roughly analogous).  This is the type of construct which people like Neal Gafter are pushing for inclusion into Java 7.  This addition would enable code similar to the above Scala example to be written in pure Java.

Most of the closures proposals though have a single, overwhelming point of opposition: cryptic syntax.  As I’ve said many times, Java is tied to a great deal of legacy baggage, especially syntactically.  This baggage prevents it from evolving naturally beyond a certain point.  Scala on the other hand has virtually no history, thus the designers were able to create a clean, well-considered syntax which reflects the needs of most developers.  You’ve seen how Scala allows you to declare and pass functionals, but what about the receiving end?  Does the syntax bulk up under the surface?

Here’s a simple example which iterates over an array, calling a functional for each element:

def iterate(array:Array[String], fun:(String)=>Unit) = {
  for (i <- 0 to (array.length - 1)) {    // anti-idiom array iteration
val a = Array("Daniel", "Chris", "Joseph", "Renee")
iterate(a, (s:String) => println(s))

See?  The syntax is so natural you almost miss it.  Starting at the top, we look at the type of the fun parameter and we see the (type1, …)=>returnType syntax which indicates a functional type.  In this case, fun will be a functional which takes a single parameter of type String and returns Unit (effectively void, so anything at all).  Two lines down in the function, we see the syntax for actually invoking the functional.  fun is treated just as if it were a method available within the scope, the call syntax is identical.  Veterans of the C/C++ dark-ages will recognize this syntax as being reminiscent of how function pointers were handled back-in-the-day.  The difference is, no memory leaks to worry about, and no over-verbosity introduced by too many star symbols.

At the bottom of the example, we see another (slightly different) syntax for specifying an anonymous method.  In this case, the method is just a single expression, so we don’t need all the cruft entailed by a proper block.  So we drop the braces altogether and instead write the method on a single line, declaring parameters and handling them within.

We’re not done though.  Scala provides still more flexibility in the syntax for these higher-order function things.  In the iterate invocation, we’re creating an entire anonymous method just to make another call to the println(String) method.  Considering println(String) is itself a method which takes a String and returns Unit, one would think we could compress this down a bit.  As it turns out, we can:

iterate(a, println)

By omitting the parentheses and just specifying the method name, we’re telling the Scala compiler that we want to use println as a functional value, passing it to the iterate method.  Thus instead of creating a new method just to handle a single set of calls, we pass in an old method which already does what we want.  This is a pattern commonly seen in C and C++.  In fact, the syntax for passing a function as a functional value is precisely the same.  Seems that some things never change…

Now there is one outstanding dilemma here that the attentive will have picked up on: what about println() (accepting no parameters)?  Of course Scala allows zero-arg method invocations to optionally omit the parameters for brevity’s sake.  What’s to prevent the compiler from assuming that instead of wanting the value of println(String) as a functional, perhaps we actually want the return value of println().  Well the answer is that the Scala compiler is very smart.  It has no trouble with this particular sample in differentiating between the different cases and choosing the unambiguous answer.

But assuming that the compiler couldn’t figure it out, there’s still a syntax to force the compiler to accept a method name as a functional rather than an actual invocation (Scala calls these “partially applied functions”):

iterate(a, println _)

That dangling underscore there is not a weird typo introduced by WordPress.  No, it’s actually a weird construct introduced by Martin Odersky.  This underscore (preceded by a method name and a non-optional space) tells the compiler to look at println as a functional, rather than a method to be invoked.  Whenever you’re in doubt about whether you’re semantically passing a functional or a return value, try throwing in the underscore suffix.  If you can’t figure it out, the compiler probably can’t either.

I could go on talking about higher-order functions for days (and many people have), but I think I’ll just close with one final note.  A lot of features throughout the Scala API are designed as higher-order functions.  foreach(), the standard mechanism for iterating over any Iterable, is an excellent example of this:

val people = Array("Daniel", "Chris", "Joseph", "Renee")
people.foreach { name:String =>
  println("Person: " + name)

This is the idiomatic way to loop through an array in Scala.  In fact, as I said this is the idiom for looping through anything in Scala which is potentially “loopable”.  As you can now see, this is in fact a higher-order function taking an anonymous method as a parameter which it then calls once for each element in the array.  This makes sense from a logical standpoint.  After all, which is more “componentized”: manually managing a loop over a range of values, or asking the array for each value in turn?

So Long, Farewell…

That about wraps it up for my introductory series on Scala.  I certainly hope this set of articles was sufficient information to get you on your feet in this tremendously powerful new language.

If you’re like me, something like this series will only whet your appetite (or dampen your spirits to the point of manic despair).  I strongly suggest you read Alex Blewitt’s excellent introduction to Scala (if you haven’t already).  Much of the material he talks about was covered in an article in this series, but he provides a different perspective and a degree of insight which is valuable in learning a new language.  There is also a wiki for the Scala language.  It has a frustrating lack of information on some (seemingly arbitrary) topics, but it can often be a source of explanation and usage examples that cannot be found elsewhere.

On a more “hard core” level, I have found the scaladoc API for the Scala runtime to be an invaluable resource in my own projects.  Finally, when all else fails, there’s always the official Scala documentation.  Included with this package is the (very heavy) Scala tour, which doesn’t seem to be linked from anywhere except the Nabble mailing-list archive.

I leave you with this parting thought:  You’ve seen Scala, how it works, the benefits it can bring and the total transparency of its interop with Java.  If you haven’t at least tried this language first hand, trust me, you’re missing out.