Tag Archives: scala

Programming

Toy Scala Static Webserver in less than 100 lines

Doh! The original link to the code was for the wrong file! Sorry. Corrected below.

Okay so there has been a craze for writing static webservers in new languages in less than 100 lines recently and I am not claiming that this code is anything special but I wanted to give to give the NetBeans Scala plugin a go (in NetBeans 6.5) so here’s my version of a Scala static webserver (in less than 100 lines, natch).

The code is more of a Toy at the moment as it assumes a very happy path. However it does work and it did provide some useful learning about Scala.

The good stuff includes: compact code, class imports, XML literals, map literal syntax and the NetBeans plugin does a good job of providing codealong feedback from the compiler.

Confusing stuff:

  • accessing array indexes with () not [], it makes sense but you have to get used to when coming from Java
  • implementing Java interfaces in Scala: still not totally sure how you do that
  • getting the right type to allow a Java API to be called: Array[Byte] seemed to take a long time to get right and not having type-coercion for Scala Lists to Java Lists means there is a anemic list variable in play
  • functions that have many parameters make for confusing IDE errors; do you want Int, Int, Int, Int, String, String or Int, Int, Int, Int?

And finally the bad:

  • the streaming IO for binary files is entirely imperative and is basically Java code, I’ve been told that Scalax can help put a prettier front on that
  • nothing to do with Scala but the in-built Java HttpServer should have had the public API in interfaces and there should have had an NIO-based HttpExchange
  • I.cant.stop.using.periods even.if.I.dont.have.to

Overall I am pretty happy with the quality of the final code and I feel I’m finding the balance of the language more and seeing Scala as more of an extension of Java than something entirely unique.

Standard
Java, Programming

Splitting Loot with Scala

Over the last couple of days I have been trying to implement the Sharing Problem (Ruby Quiz #65: Splitting the Loot) in Scala. So far I have implemented the greedy pick algorithim and still need to implement a recursive solution that will brute force the edge cases.

However on the way I think I have picked up some important lessons. You can see the code for yourself in the GitHub project related to the problem and the solution (it’s in the Scala directory) but I will be highlighting some of the code in this post.

This was the first set of Scala I’ve done that was actually an attempt to use some of the functional aspects of Scala rather than just porting Java code in a more or less literal and imperative way. After struggling a little bit with the implict return and list concatenation I implemented the greedy heuristic. This is what it looked like (link to the code file).

import gems._

package splitter {

  class LootSplitter

  object LootSplitter {
    def splitLoot(gembag: GemBag, shares: Int): List[GemBag] = {

      if((gembag.totalValue % shares) != 0) {
        return List[GemBag]()
      }

      val individualShareValue = gembag.totalValue / shares

      var partShares: List[GemBag] = List.make(shares, new GemBag(List()))

      gembag.gems.sort(_.value > _.value).foreach((gem: Gem) => {
        partShares = partShares.sort(_.totalValue < _.totalValue)
        partShares = List(partShares(0) add gem) ::: (partShares drop 1)
      })

      partShares
    }

    }
  }
}

I was struck initially by how compact this code was, you are looking at about 28 lines of code. However as I was looking at it I began to wonder whether it was concise or just terse. How is someone meant to interpret something like _.value > _.value? I showed it to a collegue and his first reaction was “I don’t know functional languages so I wouldn’t know what this means”.

This was exactly the kind of reaction I was afraid of because I have been converted heavily to the principal of readable code. Someone should be able to scan code and understand, in principle, what is happening here. If they don’t then the cost of maintaining that code is going to be higher and we have actually lost something in the concise syntax.

I decided to try and implement a readable version of the same file which added about 6 lines (only two according to GitHub!). You can read this version here but now I want to throw it open to the public. Is this version actually easier to read? Are things like the underscore variable actually part of the price of comprehending Scala?

In my rewritten version I use some of the nice features of Scala such as first order functions but you still have lines like this:

List(sortedBags(0) add gem) ::: (sortedBags drop 1)

I hope you are reading this as “add a gem to the first sortedBag and make a List of it and then add all the other bags except the first one to the new list” but I am worried that this is far from obvious. Is that because I’ve done something that isn’t idiomatic or is it because actually the operators and the library API are too obscure?

Scala represents a significant evolution of Java in terms of absorbing all the lessons learned during the evolution of the language. When porting Java code I feel far more comfortable with it than when I am trying to create new code that uses the core language libraries. I don’t want to evolve to a new set of problems and best practices that try to avoid them.

Standard
Programming

Baby steps in Scala

Okay so following on from the User Group meeting I have started the exercise of porting a Java application to Scala. I’ve chosen Jay’s Secure Diary (or just JDiary for short) and I have commited some code to Launchpad.

So then, learnings so far… Well this is all being done via the command-line and a text editor as I have the Eclipse plugin has just not wanted to play ball with me. It’s also a tremendous pain in the ass to get stable updates of the plugin. I’m getting support from the Scala Tools forum but it feels a curious mix of features. A lot of things are very polished but the basic behaviour isn’t solid.

I was mightly relieved when I got Gant working and taking some of the strain of the build. It is surprisingly easy to get going. I based mine on this blog post. The harder part is referencing the Scala Home Directory which I have hardcoded for now and need to sort out.

I also gave Scala GUI a go but gave up quite quickly because it seems very opinionated about how you should be doing guis and while I like some of the ideas it didn’t allow me to use any of my existing Swing knowledge and didn’t have any easy documentation for how you are supposed to use it. In Profligacy for JRuby and Groovy you are allowed to mix the two approaches a lot more freely.

I also spent a ridiculous amount of time trying to implement the ActionListener trait/interface until I hit on the fact I was meant to be using the override key word. The compiler error complains that the parameter (ActionEvent in this case) is not defined, that’s true but it’s really not helping you understand what is wrong with the code.

I also spent too long fiddling around with Launchpad, but that’s another story for another post.

After investing eight hours or so in the effort I can be happy that my code is looking relatively clean compared to the original but I have to say that I was enjoying Scala more when I was sticking to just Scala.

Standard
Java, London, Programming

London Scala User Group Meeting

Had a good meeting (I thought anyway) at the TW offices that featured a talk from Jamie Webb introducing Scala and then a quick dojo. Scala has a much terser syntax than Java but I managed to do my classic thing of mixing my languages and putting my constructs in the wrong place. The other thing that doing rather discussing taught me is that Scala’s constructor syntax is much better defined than Java with the default constructor going into the declaration of the class. That’s the kind of improvement on Java that I really like in Java. It seems to distill all these lessons you’ve been learning if you write good Java code.

The pub after the event also saw a lot of discussion, there was quite a bit of discussion about testing and dynamic versus static typing. Personally I have decided to follow Neal Ford and reject the issue. To me both Ruby and Scala are low ceremony, high essence languages that choose different approaches to address the same issue. As such I don’t think there is any contradiction in liking and wanting to learn both languages.

Similarly I love compile time checking but I’m not giving up on testing. It’s a synergistic practice and I want to get the benefits from TDD/BDD/Tests as Specification. To me there is some irony that if I do have a test suite then actually I have more flexibility about my choice of languages. Not testing means you get much higher value from strong compile checking and therefore something like Scala is going to deliver much more benefit quickly. At the end of the day though I don’t want to have treat my tests as the gamekeeper of my wild code. I do expect the language and the compiler to give some structure and help to the development process.

Despite (because of?) my mistakes  want to do some more and I think Aaron (the founder of the group) suggested converting an existing Java program to Scala. That seems pretty sensible and I have an old Java program that I use a lot hanging around that needs some TLC.

If you are interested in Scala and in London I would recommend coming along to this meetings because you have the chance to meet and talk to everyone who is really engaged in Scala in the city. And to the guy who came all the way from Belgium; I salute you, you are a real hero!

Standard
Scripting

Discovering Scala

Over the last two days I have been giving Scala a quick whirl and I have to say out of all the new languages (functional and otherwise) I have been looking at recently only Erlang is anywhere near as exciting. There is a small fifteen page tutorial and after finishing it I immediately thought: “I want to see more of that”.

I can’t put my finger on it at the moment but I imagine its the fact that it seems perhaps more familiar due to the Java background. The functional syntax is as confusing as any other functional language.

P.S. if you go through the short 15 page tutorial then there is a slight blip in the tutorial when case classes are introduced. All the code for the calculator example should be wrapped in an object block if you want it to work. I.e.

object Calculator {
... tutorial code
}

Standard