Announcing the Daily-Scala blog

Today I am officially announcing the Daily-Scala blog.

Back in August I started a little blog called Daily-Scala. The idea was originally to post a little snippet of Scala each day and provide some comments about the snippet of code. I started out covering the basics but also added the occasional more advanced Scala tip. I expect now that much of the basics have been covered I will be able to provide more of the advanced tips.

Currently there are around 50 posts on the site and I expect to reach several hundred at least. Once I have the fundamentals covered, 3rd party libraries will also be covered. Even if you know most of the current tips I think it is a great blog to watch in order to get the occasional surprise or interesting tid-bit.

If you have any ideas for topics you would like to see covered please let me know.

Update:

Silly me I forgot to link to the blog:

Daily Scala

Daily-scala

I have just started a new blog intended to provide both a starting place for newbies as well as the occasional advanced tip. The format will be very simple. A short 1-2 sentence introduction followed by several simple code snippets that can be tried in the REPL. The results from entering the snippets will also be included so simply reading the blog without trying the snippets will also be informative.

At first I intend to keep the snippets aimed at the beginners but as time progresses I intend to increase the level of complexity and begin to play with some advanced techniques.

Suggestions will be welcome.

Jesse

Boiler Plate Kills (Good design)

There have been a number of blogs and and even a report or two about the cost of boiler plate code.

I concur... but not because of the easily refuted claim that it takes time to write all this extra code. That is a poor reason offset by the power of any modern IDE. Rather the problem is that the resulting software suffers from poor design caused by the avoiding boiler plate.

Now one might ask, why are people avoiding boiler plate if the IDE writes it all for you. The problem is not one of time, rather it is an issue of psychological weight: 25 lines "feels heavier" than 3 lines of "clever" code. This happens to all developers but especially the more junior programmers.

Here are a few common examples where this happens in Java:

Example 1:

I am writing a method that needs to return a string, integer and a boolean.

The correct way to do this is the make an object for the return value. And often this will be done. However, I have seen some creative solutions like returning Object[] and treating it like a tuple. Or creating a Tuple implementations that is used in many situations (guilty). Tuples are not bad but they do not offer contextual information so full objects should be preferred over Tuples in most cases, especially API.

In a language like Scala creating a simple class for this purpose is as light as a single line. In Java you have to specify all the fields the constructor and most likely getters and/or setters resulting in around 12 lines without getters and setters and around 60 lines with getters/setters and equals/hashcode. The psychological weight of 60 lines must not be discounted. Even then the work required to do that with Eclipse is nearly half-again that with a normal text-editor and Scala.

Example 2:

You want to transform a Sequence like list or array.

This is a really painful scenario using the standard java.util collections because unlike the Google collections library the collections do not have methods for passing in functions to perform the transformation/calculation. But even with Google collections the amount of code required will often cause a developer to attempt a "clever" (read "bad") solution to the problem.

Example 3:

You have a custom data structure and want to create multiple strategies for performing calculations based on the data structure.

As we all know the right thing to do is to create an interface and the various implementations for each calculation. Unfortunately I have observed several cases where developers have actually avoided creating the interface and implementations and instead directly accessed the getters and setters to traverse the data structure and perform the calculation.

The main point here is that extra code creates a mental/psychological weight that developers will work very hard to avoid. It a the long-term/short-term compromise comparable to what has happened and is happening with our economy. Making a clever work around feels nice on the micro level but over time it will make the system much harder to understand and maintain. Try to go back to a call to "doSomething" that returns a Object[]. The danger of making a mistake parsing the list and the difficulty of trying to understand what it does cannot be understated.

Unchecked Ducktyping in Scala

I finally had an occasion to to use Scala's structured typing, although not in the way it was intended. I needed to call a method on a class that was compiled during runtime. Therefore I had no type information on it. So I cast it to a structural type.

Here is something you can try that illustrates the principal:

scala> val o:AnyRef = "hi"
o: AnyRef = hi

scala> o.asInstanceOf[ { def length():Int } ].length()
res2: Int = 2

I obviously didn't come up with this strategy myself, but look at how much nicer this is than that the alternative using java reflection to invoke the method.


One question though: Is there a way to check if the object fits the type before casting? For example I would love to do:

if( o.getClass.isAssignableFrom( { def length():Int } ) {
// do something
}

Right now the only way I know is to cast the object to the structural type then test each method for existance. Not that convenient.

Scala multiple assignment

Maybe I am a bit slow, but I finally taken the ability to assign multiple values in a single assignment using tuples and extrapolated to the more general pattern matching case. The only way I can really explain is with examples:

Here is the basic case that is shown in so many examples:

scala> val (x,y) = (10, "ten")
x: Int = 10
y: java.lang.String = ten

In this example the Tuple (10,"ten") is assigned to x and y using the same mechanism that match and case uses.

scala> (10, "ten") match {
| case (x,y) => println(x,y)
| }
(10,ten)

I finally came to the realization that if we can do this with Tuples can we not do it with other case classes or classes with Extractors?

scala> case class T(one:Int, two:String)
defined class T

scala> val t = T(6,"six")
t: T = T(6,six)

scala> val T(i,j) = t
i: Int = 6
j: String = six

scala> val T(a,b) = T(10,"book")
a: Int = 10
b: String = book

Some may ask: "Why do you need this if you can use Tuples?" My answer is that Tuples while handy have no semantic meaning. A case class can have meaning. So it is better to pass around an object with meaning rather than a Tuple.

Consider the case where a method returns a case class, one could use this method to extract just the values desired or extract them into local variables:

scala> val T(a,_) = T(10,"book")
a: Int = 10

Pretty cool eh!

Now in the spirit of "how deep down the rabbit hole can we go":

scala> object Names{
| def unapply(s:String): Option[String] = {
| if( s.trim.startsWith("Mr")) Some(s.trim.drop(2))
| else None
| }
| }
defined module Names

scala> val Names(name) = "Mr Jones"
name: String = Jones

Wow so extractors also work. This is too much fun :)

Scala: Program like you mean it.

In my mind one of the best features of Scala is the ability to write a program in a manner that makes sense for the problem space.

I am not discussing external DSLs in this discussion. Although external DSLs have their use I am reluctant to use them too often, Martin Fowler has a number of informative blog entries regarding the uses and dangers of external DSLs.


Instead I want to discuss the ability to write nice internal DSLs in Scala. Scala provides a number of strategies in which a library author can create a library that can be used in a way that makes sense given the problem. GUI programming may make sense with a declarative syntax. Parser coding might be improved with a DSL that closely mirrors formal grammar.

Why is this such an important issue?

• First one there is the up-front productivity gain. If the problem can be solved in a language that makes sense for the problem then developers do not need to make several translations from the problem space to the program space. In addition if the language suits the problem then most likely the language does not contain much of what Martin Fowler terms: Syntactic Noise.


• The next issue to consider is maintainability and "debuggability". Assuming a well designed DSL (a potentially large assumption), the code should closely align with the problem which means anyone familiar with the problem should be able to follow the logic of the program with relative ease. I think it nearly goes without saying that if the logic can be easily understood then it is easier to debug and maintain.

In my mind XSLT is an example of what happens when the language is not well suited to the problem space. Because XML was chosen as the programming language rather than a more flexible language like Scala or Groovy XSLT is far more difficult to use than it should be.

Some of the issues that make XSLT a burden to use:

• XML is horribly verbose making it slow to program with and to be able to tell what are the important parts of the program.
  Here is an example that I think illustrates how difficult XSLT can be to follow.
  Where does the XSLT start and stop and where is the new XML defined?
  Imagine an XSLT that is 10+ documents and try to follow the logic if you were not part of the development team who wrote the original XSLT.
  

  <xml id="xsltExample" style="width: 400px">
       <template match="GM03Comprehensive.Comprehensive.MD_FeatureCatalogueDescription">
               <che:CHE_MD_FeatureCatalogueDescription>
                   <xsl:for-each select="complianceCode">
                       <complianceCode>
                           <gco:Boolean>
                               <xsl:value-of select="."/>
                           </gco:Boolean>
                       </complianceCode>
                   </xsl:for-each>
  
                   <xsl:for-each select="includedWithDataset">
                       <includedWithDataset>
                           <gco:Boolean>
                               <xsl:value-of select="."/>
                           </gco:Boolean>
                       </includedWithDataset>
                   </xsl:for-each>
  
                   <xsl:for-each select="dataModel">
                       <che:dataModel xsi:type="che:PT_FreeURL_PropertyType">
                           <xsl:choose>
                               <xsl:when test="GM03Core.Core.PT_FreeURL">
                                   <xsl:apply-templates mode="language" select="GM03Core.Core.PT_FreeURL"/>
                               </xsl:when>
                               <xsl:otherwise>
                                   <URL><xsl:value-of select="."/></URL>
                               </xsl:otherwise>
                           </xsl:choose>                   
                       </che:dataModel>
                   </xsl:for-each>
                   <xsl:apply-templates mode="Content" select="modelType"/>
               </che:CHE_MD_FeatureCatalogueDescription>
           </xsl:template>
     </xml>

  
  


• XSLT is designed to transform XML but unfortunately is written in XML so it is so hard to tell where the declaration starts and the program ends.


• Because it is written in XML you have many restrictions on what characters are permitted and depending if the character is in a text element or an attribute there are different rules.

I am not here to claim that you can't write bad code in Scala. In fact Scala give the programmer a powerful suite of tools which would allow a developer to write the worst code imaginable. Yet for the same reason you can make some of the cleanest and maintainable code out there.

There are those that say allowing developers access to that power is irresponsible because most developers are bad programmers.

Seriously, I have heard this. Even were this true, which I do not believe, a project manager can and should monitor the design of APIs to ensure that all developers have good examples to work from. Also, well-defined best practices can be a big help to reduce the amount of Franken-code.

But I digress.

In contrast to XSLT Scala poses few restrictions on how a library can be declared so that it is possible to create a library that uses a syntax that makes sense for the domain. A couple of examples are in order.

Scala Swing

I have recently been looking at JavaFX and have really enjoyed using it to write Rich UIs (hopefully Oracle doesn't kill it :( )). Using declarative programming for a UI really makes sense. It is easy to read and even if you aren't familiar with the language. Because of Scala's flexibility the Scala team were able to write rich wrappers around Java's Swing library that is nearly as easy to program and read as JavaFX.

Here's a little snippet to whet your appetite (from Scala-swing examples):

object SwingApp extends SimpleGUIApplication {
   def top = new MainFrame {
     title = "SwingApp"
     var numclicks = 0     
     object label extends Label {       
       val prefix = "Number of button clicks: "       
       text = prefix + "0  "       
       listenTo(button)       
       reactions += {         
         case ButtonClicked(button) => {
           numclicks = numclicks + 1           
           text = prefix + numclicks
         }
       }   
    }     
    object button extends Button {       
      text = "I am a button"     
   }     
   contents = new FlowPanel {       
     contents.append(button, label)       
     border = Swing.EmptyBorder(5, 5, 5, 5)    
   }   
 } 
}

The example defines an application with a label that increments each time the button is pressed. This is clearly a different way to do swing programming from the traditional Java swing programming.

Scala XML

Another good example is Scala's XML support. I am not talking about the literals that are embedded into the language (although that makes XML handling much nicer.) I am talking about the library that could be written for any data format; JSON is an example that comes to mind.

val countries = for( country <- XML.load(inputStream) \\ "countries" ) yield {   
  Country(country \ "@name", country \ "@population", deserializeCities(country \ "cities")) 
} 
// do something with my scala country objects 

This simple example illustrates how the countries elements in an XML document can be deserialized very easily and readably with the Scala XML API. It currently does not have all the power of XSLT but it is getting more and more complete as time passes and is, in my mind, much more readable than XSLT for many common uses.

Actors

One of the libraries that really attracted me to Scala was the Actor's library. Actors were inspired by Erlang Actors and are essentially an implementation of the Active Object pattern (http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf).

The cool thing about the Actor library in Scala is even though the Actor support is only a library, using it feels like actors are a fundamental part of the language.

  val newGuy = actor {                                                                            
    receive {                                                                                      
      case msg => { 
        println("how nice, I just met a person: "+msg); 
        sender ! "Nice to meet you"
      }
    }
  }
  
  newGuy ! "Hi new guy."
  
  receive { case msg => println("Got a reponse from the new guy: "+msg) }

An obviously silly example but look at how easy it is to construct a new thread and interact with it in a thread-safe manner. It is very clean and very easy to understand the intent of the code. An introduction to actors in scala can be found at: http://www.scala-lang.org/node/242

Other examples:

http://scala.sygneca.com/libs/dbc - A library for accessing Databases
http://code.google.com/p/specs/ - A declarative approach to unit testing
http://www.artima.com/forums/flat.jsp?forum=270&thread=231515 - a discussion on writing internal DSLs in scala

The word on JavaFx

First off I should say that I am going to try to be fair in this little write-up but I have to declare that I am from the Java camp and am probably biased in that direction.

ok Lets get into it.

I have now developed a quick demo application that displays maps. It is something of a combination between Google earth and Google maps. Hopefully I will find time to take a screen capture and get it online. I also have started a project for doing code reviews. It is still very much in its infancy but it gave me a very different point of view on JavaFX.

I have to say that I have really enjoyed the experience thus far. JavaFX is nice language for building UIs. I really like the combination of declarative and functional aspects of the language. My current favourite systems language is Scala and coming from there (and from Java) to Javafx was very natural and I was able to get up and running very fast.

The tutorials are very helpful in getting going as well. Adding wiz-bang and wowzer effects to an application is a real no-brainer and having property support into the language is absolute genius.

If you want to play around I would highly recommend taking a look at the samples. They are some good examples and the code is right there to show you how you can pull it off.

I did most of my development on Ubuntu so although linux is not officially supported it is not a major issue so don't hold up over that issue.

At this point Javafx also has some warts. Although they are all easily solvable and I am sure are simply here only because the system is a V 1.0 product. The only really major issue I encountered was the sever lack of widgets. Yes swing can be easily used... but swing is in no way a nice way to do UIs. This aspect MUST be fixed or Javafx will be no more than a Swing replacement, if that.

I also experience some compiler bugs but when I went to report them I saw that they were not only reported but already fixed and schedule to be included in the next release. So that really does not concern me.

The last issue is the netbeans support is only decent. Code completion frequently fails and there are occasional unpleasant behaviour. Nothing major and now that Tor is on the job I am sure that will be very nicely fixed up.

In short I have to say that I am VERY excited about Java One this year. I am hoping for another big JavaFX release. Hopefully it bring some widget libraries to the platform.