I’ve been busy rewriting the guts of Squeak’s Browser.
It’s an important tool: it’s the primary way we write code and explore the system. It’s also the tool I must use to edit the Browser. Time to operate on my own brain again! Read more…
This month’s post is something a little bit different to the usual LShift posts. Don’t worry, there’s still plenty of software and algorithms in there, but I’m also creating an actual physical object as well (\*shock\* \*horror\*).
I’ve recently acquired access to a laser-cutter, and I’ve been going through a bit of a learning process and seeing what I can do with it. Like everyone else, I started with other people’s designs, but I’d been thinking about doing something of my own. Along the way, I’d found and used the BoxMaker which is a very useful service for generating laser-cutter plans to make a cube of arbitrary size, and this got me thinking. I wanted to do more advanced things with multiple cubes, but designing all the joints correctly by hand would be an exercise in frustration. Enter the imaginatively named cube generator
Like Tim, I’ve been playing around with zippers recently, only I’ve been working in Smalltalk. In particular, I’m trying to explore how easy it is to work with objects in a fully functional way . With that in mind, I’m working within certain constraints, most important of which is “thou shalt use immutable data structures”.
This is Smalltalk, so we can’t actually have immutable objects. Rather, we can’t enforce immutability. Some dialects do support immutability, thanks to support from the virtual machine. I’m working in Squeak, though. So what do we do?
Fantom is an object / functional hybrid with strong typing or dynamic typing depending how you are feeling.
foo.bar(zarjazz) // This is static
foo->bar(zarjazz) // This is dynamic
If you go with the static typing you get some type inference and nice errors from the compiler, and if you go dynamic you can write your own despatch mechanism for your class and pretend you’re writing Smalltalk or Ruby. You may even be able to go really crazy and add methods that don’t exist as they are called using closures but I haven’t tried that yet.
It has some other nice features inspired by Ruby such as mixin inheritance and passing closures to the methods on its collection libraries so you never have to write a for loop again. Additionally it has a simple build tool, logging and unit testing baked into its core libraries.
So far so good! But the thing that really caught my interest was Nullable types. C# has nullable value types, this has always seemed stupid to me – you take my int which can never generate a NullReference exception, you replace it with an int? which can either contain a null or an int, now NullReference is free to roam your code at will. In Fantom types can only contain null if you let them; by default Fantom types can’t contain a null, however if you add a ‘?’ to the type name it becomes a nullable type – which is like a Maybe in Haskell but just using null as its value for None. This is exactly what I want in my code, if I say I want a Foo the compiler will make sure that I get a Foo and not a null pretending to be a Foo, and if you see a method returning a Foo? you know that you will need to check for nulls before proceeding to use its result or get an error – unlike in Java where really everything that isn’t a primitive type maybe null. The paranoid part of my brain is now thinking, “Oh my! I should null check every parameter, in every method, forever!”
To summarize: so far I like Fantom, it is a nicer and simpler Java / C# and is nowhere near as complicated as Scala. Programming in Fantom feels a lot like programming in Ruby but with the added benefit of having a simple type system present to catch some of your errors.
You are currently browsing the LShift Ltd. blog archives for March, 2011.