Programming

I wanted to update the Haskell development environment on my work computer, especially after I found out I didn't have one after upgrading to Snow Leopard. I proceeded to install Haskell Platform, which I had already installed on my home computer with great difficulties. This time it installed fine, they have a binary installation package for OS X on Intel, but the problems started only after that.

I tried to build happstack-tutorial with Cabal, but it failed with gcc complaining about missing cc1. Quickly looking at the directory there indeed was no cc1. After a slight misstep of accidentally installing older XCode on top of the new one, losing for example /dev/null in the process, having to reboot and reinstall XCode, I figured out something more about the cause.

With a bit of googling I found out about gcc --print-search-dirs. Gcc thought its installation directory was /usr/lib/gcc/i686-apple-darwin9/4.2.1/, which unfortunately did not exist, it should have had darwin10 there. A bit more googling showed me the light: I had some /Developer directories in the path. Getting rid of those got me forward, trying cabal again. And failing.

Now I got errors like "CPU you selected does not support x86-64 instruction set." Great. Still more googling, found out it was a bug in GHC. Of course the fix was not yet in the GHC that came with Haskell Platform. Fine, I installed the latest and greatest GHC. Trying cabal again. And failing.

This time: "cabal: failed to parse output of 'ghc-pkg dump'". It was mentioned on the ghc page that it only works with Cabal-install version 0.8 or later, I had 0.6.2 from Haskell Platform. I should have updated it first, but I couldn't because ghc didn't work. Chicken and egg.

So I had to get new cabal-install from somewhere. Cabal home page had the same 0.6.2 version I already had. Use the source, then. Cabal-install source package came with bootstrap.sh, which failed because my cabal library was too old.

I got the latest cabal source, ran ghc --make Setup, got "ld: can't write output file: Setup". Ran it again, this time it worked and produced Setup executable. I did what man's got to do, and surprisingly enough there were no errors.

Back to compiling cabal-install. With the new cabal library it compiled just fine. Backtracking further to where I started, happstack-tutorial. That didn't compile as fine:

Building containers-0.2.0.1...

Data/IntMap.hs:182:7:
    Could not find module `Data.Data':
      It is a member of the hidden package `base'.
      Perhaps you need to add `base' to the build-depends in your .cabal file.
      Use -v to see a list of the files searched for.

I gave up with that for now and tried to cabal install happstack. Naturally that failed too: "ghc: could not execute: trhsx". More googling, added ~/.cabal/bin in the path. Now happstack install succeeded.

Maybe I'll continue with happstack-tutorial some other day...

After a long time away, I've returned in the area of manual memory management. The reference counting model in Apple's frameworks is pretty nice and easy, but of course not as easy as automatic garbage collection would be.

I got a reminder yesterday, when I used a tool to check if it finds any memory leaks in my program. Indeed it found one place where I had forgot to release an object. That was easy to fix, but fixing that one revealed another bug. In a related code I released an object twice, which happened to be one time too much, causing a crash elsewhere. One bug hid another.

There has been a couple of occasions before where I tried to use a deallocated object, but those have surfaced immediately. I still consider myself lucky (or maybe just good?) in that I haven't run into any more problems with memory management in this project.

Recently I've become more and more drawn to functional programming, reading articles and tutorials about it and about various more or less functional programming languages, such as Lisp, Haskell, Javascript and Scala.

I just finished reading a nice, introductory article about functional programming. It explains some history of functional programming, benefits of it, and concepts like higher-order functions, currying, continuations, pattern matching and closures, in terms of Java.

The author seems to have quite a few interesting-looking articles on his site, thus there's one more site to my blogroll.

Ruby on Rails has caused quite a buzz recently in the web sites I follow. As far as I have understood it's a way to get web applications up and running fast, using a set of tools and Ruby as the programming language.

For those of us who wish to stick with Java, there is now Trails, a framework (as you can guess from the name) inspired by Rails. It has the same goal, to make web application development as easy and fast as possible. I haven't tried it out myself but looks pretty promising.

Trails website says it is "a domain driven development framework". "Domain" seems to be a buzzword nowadays, many new things being "domain driven" or "domain specific". But so far so good, it makes sense not having to do same things over and over again.

Domain specific languages were brought into my attention recently and some people believe they are the Next Big Thing. I'm yet to form an opinion, but I do agree that raising the abstraction level in programming is going to continue, as it has done since the first computers.

Domain specific languages are one good way to raise the abstraction level, but they are nothing new. There has been domain specific languages as long as there has been programming languages. What is new, however, is that there will be new, better tools for developing domain specific languages, and that might be both a requirement, and a spark, for domain specific languages to become a mainstream programming concept, or the next big thing.

Martin Fowler's article about language workbenches describes well what can be expected from such tools, and how current modern development tools already prepare us for that. I agree with what Fowler writes, and one paragraph struck me especially:

My colleague Matt Foemmel described how this struck him one time while working in IntelliJ. He made a change that was strongly assisted by these features and suddenly realized that he wasn't typing text - instead he was running commands against the abstract representation. Although the IDE translated these changes in abstract representation back into the text - it was really the abstract representation he was manipulating. If you've had a similar feeling while working with a modern IDE you're getting a sense of what a language workbench does.

That's really what programming with a modern integrated development environment can be. It's not so much about typing a program, but manipulating the abstract representation of a program with the tools provided by the editor. Variable and method name completion, refactoring and code generation tools, they all help in that the programmer can think in higher abstraction level than just the basic syntax of the programming language.

This is the link between current development tools and those that will come, supporting more abstraction. So, while waiting for language workbenches for domain specific languages to become more widely available, I encourage programmers to get used with the tools in current modern development environments, to try them out and take full advantage of them. Not only because they help in common programming tasks and thus improve productivity, but they might also subconsciously affect the way your mind processes programming tasks. You could begin to think in higher-level concepts, and let the tool take care of mundane details of keeping everything in sync. That could make you a better programmer, or make you prepared for the future of programming, when you can look back to this day, wondering how much there has been progress.