Other articles


  1. Deploying a Play Application on Ubuntu

    The more I use the Play Web Framework, the more I like it. The “dev mode” is great, compiling everything that’s changed on the fly, including the statically checked routes and templates. But sooner or later we want to deploy our app for reals.

    The dist target will package up your app into a zip file with a simple shell script to launch it. That’s fine as far as it goes, but of course I want to run it as a proper service that starts automatically when the machine boots and can be easily shutdown and restarted. My ...

    read more

    There are comments.

  2. Do You Get Referential Transparency?

    Do you get referential transparency? I mean, really get it? I thought I did, but I recently gained a deeper appreciation for what it means.

    Referential transparency is also commonly referred to as “pure” functional programming. I understood this to mean that the code lacked side effects like performing I/O or mutating state, and this seems to be a common understanding. But referential transparency can actually be defined quite precisely and succinctly (although I believe agreement with this definition would be far from universal):

    If replacing expression x by its value produces the same behaviour, then x is referentially ...

    read more

    There are comments.

  3. Applying Applicative Functors in Scala

    A chap named ittayd has written a nice gentle tutorial on functional programming in Scala. My only minor complaint is that he calls the applicative functor “sequential application” function apply. While this is a logical choice, in Scala apply is used everywhere to implement plain old function application, so it could lead to confusion. I think it’s better to call it <*>, as in Haskell. Read on.

    I found the tutorial interesting because it talks a bit about applicative functors, and how to give them a nice syntax in Scala. The one thing that has bugged me about applicatives is ...

    read more

    There are comments.

  4. A Variation on Scala’s Either Type

    I’ve been using Scala’s Either type a bit recently, and found a couple of minor annoyances with it. So as a learning exercise I tried to make a variation of Either, and this is what I came up with. I also wanted to experiment with syntax a little. See what you think.

    Either is a disjunctive type with two possible values: a left and a right. It places no meaning at all on left or right, but 99% of its uses in practice involve putting normal, expected values in right, and errors or other “exceptional” values in left ...

    read more

    There are comments.

  5. Ceylon: Interesting For The Wrong Reasons

    A couple of days ago, Gavin King announced that he is leading a team at RedHat that’s creating a new JVM language called Ceylon. See here for most of what is known so far. The stated motivation, in a nutshell is that they like Java very much, but it has deficiencies that are preventing progress in key areas, and they are generally feeling “frustrated”. They don’t have a complete compiler yet, but they’re working on it, and I get the impression RedHat is pretty serious about it.

    Gavin King’s slides provide a fascinating insight into the ...

    read more

    There are comments.

  6. More Thoughts on Apple and Java

    A few more points that occurred to me, following up on my last post.

    Whither the Mouse?

    Since its inception in 1984, the Mac user interface has obviously been designed for desktop computers with a mouse and a keyboard. When notebook computers came along and we wanted to be able to use them without carrying a mouse everywhere, or without even a flat, stable surface to put the mouse on, they had to emulate the mouse as best they could. This may now be reversing.

    In the announcement of Mac OS X Lion, there was great emphasis placed on the ...

    read more

    There are comments.

  7. Java and the Mac

    So Apple has quietly announced that it is deprecating its support for Java on the Mac. The wording was (not uncharacteristically for situations like this) a bit vague on the details of what this means. I think two things are definite: 1) Apple will continue to support Java 6 on Snow Leopard until it reaches end of life; which I think happens when the OS after Lion is publicly released. 2) Apple will not port Java 7+ to the Mac. The main unresolved question is whether Java 6 will be supported on Lion. My guess is that it will be ...

    read more

    There are comments.

  8. Scala’s Missing Monad

    I’ve been writing more and more pure functional code in both Scala and Java recently. An issue I found myself running into quite often is this: say you have a function that sometimes returns no results (e.g. looking up a key in a map). A common way to deal with that in Scala is to return an Option:

    def foo(i: Int): Option[String]
    

    Simple enough. But then a typical use of such a function is to map it over all members of a collection:

    val strings: List[Option[String]] = List(1, 2, 3).map(foo _)
    

    What ...

    read more

    There are comments.

  9. Cocoa vs Haskell

    So here’s the deal - if you want to write a Mac GUI app, you want to use the Cocoa framework. As a practical system for writing desktop GUI apps, the Cocoa stack simply has no equal anywhere. Part of what makes Cocoa so great is the Objective-C language, which adds a very flexible and dynamic OOP system on top of standard C.

    Objective-C turned out to be a great match for creating desktop GUIs. It’s obviously a general-purpose language, but for general programming it would be no where near my first choice. My first choice right now would ...

    read more

    There are comments.

  10. Some Simple Scala Null Tricks

    Scala code often needs to deal with null references, unfortunately. Such is the price of Java interoperability. One of my favourite utility methods is:

    def ?[A <: AnyRef](ref: A): Option[A] =
        if (ref eq null) None else Some(ref)
    
    // e.g.
    val value = ?(javaCallThatMayReturnNull()).getOrElse(defaultValue)
    

    Scala 2.8 offers this using Option(ref) instead of ?(ref). However, I can’t figure out why the Scala 2.8 method accepts non-reference values as well.

    Another simple thing that may come in handy is an extractor for non-null values:

    object NotNull {
      def unapply[A <: AnyRef](ref: A): Option[A] =
          if (ref ...
    read more

    There are comments.

  11. The FSF Doesn’t Care if They’re Lonely

    Daniel Jalkut, a leading light of the Mac developer community recently blogged about the GPL and some of consequences of it for collaborative software development. I agree with what he says, and I dislike how the GPL limits collaboration in a number of ways. But I thought it might be useful to go over the background and objectives of the GPL.

    There’s an important thing to remember when talking about the GPL: the impact, good or bad, on the practicalities of software development have nothing to do with its objectives. The authors of the GPL, the Free Software Foundation ...

    read more

    There are comments.

  12. Project Euler Problem 8

    I guess I should warn that these Project Euler posts have spoilers, in case you want to try the problems yourself ☺. My Scala solution to problem 8:

    val input = "73167176531330624919225119674426574742355349194934" +
      "96983520312774506326239578318016984801869478851843" +
      "85861560789112949495459501737958331952853208805511" +
      "12540698747158523863050715693290963295227443043557" +
      "66896648950445244523161731856403098711121722383113" +
      "62229893423380308135336276614282806444486645238749" +
      "30358907296290491560440772390713810515859307960866" +
      "70172427121883998797908792274921901699720888093776" +
      "65727333001053367881220235421809751254540594752243" +
      "52584907711670556013604839586446706324415722155397" +
      "53697817977846174064955149290862569321978468622482" +
      "83972241375657056057490261407972968652414535100474" +
      "82166370484403199890008895243450658541227588666881" +
      "16427171479924442928230863465674813919123162824586" +
      "17866458359124566529476545682848912883142607690042" +
      "24219022671055626321111109370544217506941658960408" +
      "07198403850962455444362981230987879927244284909188" +
      "84580156166097919133875499200524063689912560717606" +
      "05886116467109405077541002256983155200055935729725" +
      "71636269561882670428252483600823257530420752963450"
    
    val digits = input.map(_.asDigit).toArray
    
    def multiply(index: Int) = digits.slice(index, index + 5)
        .foldLeft(1)(_*_)
    
    val multiples: Stream[Int] = {
        def rec(n: Int): Stream[Int] = Stream.cons(multiply(n),
            if (n &gt; digits.length - 5) Stream.empty else rec(n+1))
        Stream.cons(mult(0), rec ...
    read more

    There are comments.

  13. Project Euler in Scala

    Project Euler is a bunch of mathematical/programming problems. I’ve been trying to improve my Scala skills by using it on some of the Euler problems. I’m trying to use functional programming styles as much as possible. My solutions definitely haven’t been very optimized, but I am learning, which is the aim.

    Euler Problem 1

    If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below ...

    read more

    There are comments.

  14. Logging vs String Construction

    A classic logging problem in Java is this:

    logger.finest(expensiveStringConstruction());
    

    The problem with this is that even when the logger’s level is above FINEST and the message is not logged, the message string must still be constructed. In cases where constructing the string involves a lot of work, your code can be slowed down significantly even when logging is off. The standard solution is like so:

    if (logger.isLoggable(Level.FINEST)) {
      logger.finest(expensiveStringConstruction());
    }
    

    By adding the if statement around the logging, the expensive string construction is only done if the message is actually going to be used ...

    read more

    There are comments.

  15. XML vs Streams

    Ever get the feeling that XML sometimes makes things harder than they need to be? One of the problems that I and others have run into is that when parsing XML using SAX (or, in my case, using JAXB to unmarshall XML, which uses SAX under the hood) from an InputStream, the stream is always closed after the parsing is complete. This is surprising behaviour in Java, because you’re not supposed to close streams you don’t own. This can be a problem when using network sockets or when you want to write two or more unrelated XML documents ...

    read more

    There are comments.

  16. Java’s clone mechanism is teh suq

    Doing cloning properly in Java is way harder than it should be. I thought I knew all the traps, but recently found yet another. In a nutshell, making inner classes cloneable is almost always a bad idea. The reason is that inner classes have an internal reference to an instance of their enclosing class, which is implicitly final and can’t be changed as part of a clone. For example:

    class Outer implements Cloneable {
        int i = 0;
        Inner inner = new Inner();
    
        public Object clone() {
            try {
                final Outer clone = (Outer)super.clone();
                clone.inner = (Inner)inner.clone(); // A.
                // Cloned inner still ...
    read more

    There are comments.

  17. Handling InvocationTargetException

    A quick hint on handling java.lang.reflect.InvocationTargetException.

    This sucker is thrown whenever you invoke a method via reflection (typically via Method.invoke), and that method throws any sort of exception. So it doesn’t indicate a problem with the reflection mechanism, it is simply how the reflection mechanism notifies you of exceptions thrown by the method you called.

    Whenever you catch this exception (and you will have to catch it at some level), the first thing you should do is call getCause(). This returns the exception thrown from the method that was invoked via reflection, and that’s ...

    read more

    There are comments.

  18. How Not to Catch Exceptions

    When it comes to bad Java practices, top of my list would have to be catching exceptions like this:

    try {
       // stuff - anything really
    }
    catch (Exception e) {
       // maybe log it if you're lucky
    }
    

    This is usually done because the “stuff” throws more than one kind of checked exception, and the code to handle each case is the same. So what’s wrong with it? The biggest problem is that this not only catches the checked exceptions you’re interested in, but also all RuntimeExceptions. The vast majority of RuntimeExceptions are only thrown from buggy code, and catching them ...

    read more

    There are comments.

blogroll

social