Scala release

2009-01-15 00:36:47 +0100

The final release of Scala 2.7.3 is out! You can download the release from the scala-download page.

Some background: Scala is a elegant language that runs on the JavaVM. Unlike languages like Ruby and Groovy, Scala is statically typed. One of the reasons a lot of people like dynamic languages more than Java, is because Java is very verbose. That verbosity is, amongst others, because of its type-system.
However, unlike Java the typing-system is much more elegant and flexible. Because Scala can infer types, you'll have to define types only when necessary. Look for example at the following code (taken from the Scala website):

object Maps {
  val colors = Map("red" -> 0xFF0000,
                   "turquoise" -> 0x00FFFF,
                   "black" -> 0xFFFFFF,
                   "orange" -> 0xFF8040,
                   "brown" -> 0x804000)

  def main(args: Array[String]) {
    for (name <- args) println(
      colors.get(name) match {
        case Some(code) =>
          name + " has code: " + code
        case None =>
          "Unknown color: " + name
      }
    )
  }
}

There are no explicit type definitions, eventhough every defined value is statically typed. The scala compiler can infer that the val colors should have type scala.collection.immutable.Map[java.lang.String,Int]. Compare that to Java, where you'd  have to use Map<String,Integer> several times.
Minor sidenote: there are languages that have an even more advanced typing system, see, this nice article.

Furthermore, another what's very much to like about new dynamic languages is it's extendibily. You can extent a language like Ruby or Groovy, and create a new internal language.  Eventhough Scala is statically typed, in Scala this is possible as well.
Let's say you want a sort method for the general Array type. This can be accomplished with the following code:

/* Defines a new method 'sort' for array objects */
object implicits extends Application {
  implicit def arrayWrapper[A](x: Array[A]) =
    new {
      def sort(p: (A, A) => Boolean) = {
        util.Sorting.stableSort(x, p); x
      }
    }
  val x = Array(2, 3, 1, 4)
  println("x = "+ x.sort((x: Int, y: Int) => x < y))
}

There's a lot more exciting, as a last example, I put a code-snippet that demonstrates how XML is integrated in Scala:

  val header =
    <head>
      <title>
        { "My Address Book" }
      </title>
    </head>;

  val people = new AddressBook(
    Person("Tom", 20),
    Person("Bob", 22),
    Person("James", 19));

  val page =
    <html>
      { header }
      <body>
       { people.toXHTML }
      </body>
    </html>;

Finally, an example of a quicksort taken from this sample website. Impressive, but I am to much unexperienced in Scala to grasp that code immediately:

  def sort[A <% Ordered[A]](xs: List[A]): List[A] = {
    xs match {
        case List() => xs
        case _ =>  sort(for(item <- xs.tail if item < xs.head) yield item) ::: List(xs.head) ::: sort(for(item <- xs.tail if item >= xs.head) yield item)
    }
  }

Below a book about Scala I recently read

Read more

Trying to do good for the wrong reasons

2009-01-10 18:42:05 +0100

Many programmers with at least some education computer science code by a few principles:

  • Encapsulate database access, using Data Access Objects so we're not tied to one or another database
  • Use Model View Controller pattern, so we can change the view logic easily without having to change the entire software.
  • Use Facade beans and Remote Beans so we can separate our application server in a frontend-server and business-logic server.
  • Know the book of GoF by heart and use their patterns, so our code is good.

However that's all wrong! The principles are good, when applied correctly. However the reasons are all wrong resulting mediocre software. If in any project changing database is from for example from MySQL to Oracle or changing view-layer from JSF to GWT is a possibility, then that software-project is very bad managed. The ability to change a product shouldn't be the reason. And if people think they can have their software be more robust are perform better by setting up an extra business-logic server, they'll be disappointed.

Because people often use the wrong reasons, a lot of code is overly complicated, badly performing and highly unmaintainable. You known something is wrong if you have to wade to a lot of interfaces, Impl classes, XML-configuration files just to known what a piece of code is doing

Naturally the principles are good, however, the goal is totally different.  The reason for all of the principles should be: program correctly functioning code that can be adapted easily now or in the future.
Design patterns isn't a bible

Known that any book on design patters shouldn't be used as a bible. Wrongly applied design patterns produce terrible code. The book of GoF was a great book because they (Gamma et al.) introduced the concept of design patterns and gave a list of good design patterns for C++ and Smalltalk. Many of the design patterns are relevant, but many are also not.
Design Patterns
Design Patterns
Erich Gamma & Craig Larman

Most important contribution of the book, is the notion of design patterns. They introduces common words, a name, like Data Access Object, Visitor, Singleton to programming constructs. Because they gave name to certain programmings patterns, people can talk about them and understand each others code. Similar like architects use various patterns to design houses, office buildings, public buildings or monuments. The origin of design patterns was a book about architecture:

The Timeless Way of Building
The Timeless Way of Building
Christopher Alexander

There are endless design patterns besides the one listed in Design Patterns: Elements of Reusable design. Every programming language, framework and software project and application has its own patterns. Recognize patterns, give them a name if they haven't got one. Make sure the patterns and the naming are known within the company, organization or all of the users of a framework. That way, the code will be easily to grasp for anyone who has modify or extend the software, because of common naming and usage.

Great coder

Read who a  great hacker is, how to become better programmer read what you can do to be a better coder. The greatest cause why software development is so expensive and costly, is because there's enough emphasis within many organisations on writing good code.

Read more

Archive

subscribe via RSS