make clean

May 13, 2008

HoM : an experiment in Scala

Filed under: Uncategorized — harshadrj @ 7:35 pm
Tags: ,

I wrote a little game in scala; House of Mirrors. It is a logic game heavily inspired by Chromatron.

It was just a for-fun project and I also wanted to familiarize myself with scala with a real-world application.

My notes:

  • I first wrote the core of the game, with no interface at all. It was probably about 100 lines of Scala code. I found I could easily design and code on the go.
  • I built up all objects using a hierarchy of case classes and stuck to immutable data types.
  • Adding a GUI layer on top of the core was easy with the SQUIB library. I think the total code was about 400 lines of code.
  • However, when dealing with colored light beams I had to get my hands dirty with Swing, since I wanted to define my own Composite class. I found some missing functionality in AWT and had to use Double buffering while compositing. This is what to took most of my time, though it’s just 17 lines of code
  • The next part was saving and loading game files in XML format. Needless to say, this was a breeze to write in Scala. Total code was about 500 lines of code
  • After a lot of game features and minor GUI enhancements the code now stands at 1k loc

The biggest hurdle I faced when dealing with Scala was a lack of documentation for the standard APIs. The others being : instability of the compiler itself, changing APIs and some inconsistencies in the language. An example of the latter; “case North” is treated differently from “case north”! why? because capitalisation of identifiers is treated specially! Bad design choice I think; it’s too quirky.

Most of these problems should go away with time & love but some like the above quirkiness are potential hair-pullers.


March 6, 2008

lazy sequences in scala

Filed under: Uncategorized — harshadrj @ 12:53 pm
Tags: ,

At work, some of us were discussing about lazy lists v/s iterators. I just tried a quick lazy list in scala, and it worked pretty well to my satisfaction.

class roleNumbers extends RandomAccessSeq[String] {

def length=10;
def apply(n:Int) = {println(“evalutaing ” + n); “role:” + n}


val xyz = new roleNumbers

// drop 8 elements, map the sequence, and then take first element
val one_element = xyz.drop(8).map(“rum ” + _)(0)

println (one_element)

The output :

evalutaing 8
rum role:8

The laziness is preserved across list operations which is a good thing.

In fact, I notice that Iterator trait and List trait have a similar interface, which reinforces my belief that they are pretty much the same, though usage semantics might be differ slightly.

I now need to figure out how to implement an efficient get_next_element kind of iterator in scala.

December 27, 2007

Some cool new programs

Filed under: Uncategorized — harshadrj @ 3:07 pm
Tags: , , ,

I don’t know if this just some fanciful graphics or something truly marvelous. Check it out if you can (it’s for Mac only):

NodeBox | Evolution

The other cool application I stumbled upon:

Scala Ray 

It’s hard to implement a ray-tracer and, yet, these guys seem to have implemented Ambient Occlusion in version 0.1 itself. Render times seem to be a bit slow though.

December 6, 2007

Graph Layout using Genetic Algorithms

Filed under: Uncategorized — harshadrj @ 11:48 pm
Tags: , , ,

The field of Genetic Programming (GP) has always fascinated me, due to my interest in AI. But GP is a tough nut to crack. Genetic Algorithms (GA) is an easier stepping stone, that I wanted to try first. So, my interest was kindled when I saw jiva-ng, a scala based framework for GA.

After trying out some of the stock examples in the jiva-ng wiki, I was itching to try something a bit more involved, and I decided to try Graph Layout-ing.


December 1, 2007

Functional Programming and automatic type inference

Filed under: Uncategorized — pharaoh @ 12:28 pm
Tags: , ,

The power of functional programming combined with type inference is amazing. Consider for example this code snippet, written in Scala, and taken from here:

class Knapsack extends jiva.ProbDefiner {
     def gaProblem = buildBooleanProb {buildr =>
        buildr name "Knapsack"

It’s an amazingly compact piece of code which does a lot of things under the hood.

  • It defines a function “gaProblem”. The return type is automatically inferred to be the return type of the function buildBooleanProb() which is defined in ProbDefiner.
  • The function buildBooleanProb() takes another function as it’s argument. This is the hallmark of functional programming languages. They support “first-classed functions”, which means that functions are like any other objects, and can be passed around as values!
  • The => notation creates an anonymous function automatically. Let’s give it a name, say “monkey_1”
  • The monkey_1 function takes as argument an object called “buildr”, and calls some functions on it. Note that the type of “buildr” has not been declared. The syntax ‘buildr name “Knapsack” ‘ is translated in Scala to ‘“Knapsack”)’

Note that Scala is a strongly type language, and yet for all the above objects not a single type definition has been specified. It is all inferred by the compiler. The benefits of this are, less boiler-plate code to type, which means it is suitable for RAD*, and type-checking at compile time, which prevents common errors.

For example, if the programmer types “buildr xyz” and xyz is not defined in that class, Scala will complain at compile time.

*Although type inference might be suitable for RAD, the functional programming paradigm itself may not be suitable for RAD if programmers are not comfortable/familiar with it.

Create a free website or blog at