After spending quite some time working on funfem, I just decided to halt it for an undetermined duration. That's a bit sad but easily understandable. I work on finite elements all day long, and I just figured out that I did not have the motivation to work on finite elements again when back home, during my spare time. But how disappointing. Yet another halted project of mine.

I should dedicate this precious time on focusing on a completely different problem domain. Like programming languages design for example, to understand the common key notions and how they are defined in different languages, especially Haskell. Not that I want to create a language, far from it; I want to have a full understanding of the concepts, their advantages and disadvantages, how is polymorphism expressed, understand what is an arrow and why it is important, etc.

Another field I want to spend more time on is computer science. The corresponding project to contribute to is GHC. I think this is the best way to deeply understand and become better in Haskell. Compiler design and implementation is tough. I know nothing of it. But it's fascinating. The GHC team needs hands and brains to keep moving forward and stay afloat from the tickets. This is a way for me to say thank you to the community after all it gave me. I know it will be a time sink for me because I am a self-taught programmer: the only way to improve is reading, coding, and getting involved. So I'll start small, and see how it goes. I hope one day I can understand computer science papers and blog posts more easily. I want to understand key theorems, learn formal proofs and how to use them (with the assistance of Coq) too.

Having my own pet project is very important too, to get my hands dirty and face day-to-day situations. At the moment I don't have a brand new idea for a project to work on. Actually I have a plethora of ideas, but not one that really stays. The only one that doesn't want to leave is a website to manage wine, beers and other spiritus, with pictures, description, rating, etc. Can be fun and useful, at least for me. There are already softwares and websites to do it of course, the idea is not new, but it'll bring me a wide scope of fields to look at. Lots of small hackable pieces. Ideal for a home project. My hosting provider doesn't allow yet to run custom server instances, which is a bit difficult because the web frameworks for Haskell rely on their own server. Correct me if I am wrong, that would be good news. So I may resort to CGI, why not after all. Or write the haskell apache mod...

Evolution does not follow a straight path. The most important is to learn from our own failures.

I've just spent more than an hour trying to write an essay-like blog entry on a topic of software engineering. The conclusion is: it's hard.

It's difficult because every essay is essentially difficult to write. That's why they are interesting to write. And read. The topics they cover have to be interesting too of course, that's the obvious starting point. Yet, once the subject found and matured, comes the time for writing. I won't start an essay on how to write essays; I'll do that when I am satisfied with what I write or asked to (yes, you are right to see the unspoken hope of such a request).

I indeed lack practice and experience. Hence the blog. Which is worth it only if I write regularly on it. Which I failed to do recently. Which will end up in another blog entry. Proof that it requires more discipline than initially thought.

English is not my mother tongue. There are two worlds between spoken and written English, as long as you do not want to write the way you talk. I personnaly don't, simply because I find such blogs utterly boring. Get to the point, will you! is what I have in mind when I stumble upon those. Writing proper English is an excellent exercise; I will learn lots of vocabulary, and most of all, how to turn this natural French way of thinking and building sentences into more idiomatic English. I am sure this will result in a nice cocktail. I will read The elements of style, it will serve me for both writing and programming.

My lack of experience in software engineering might obviously bias the points I try to make in related essays. The observations I make are based on blogs, mailing lists, podcasts, get togethers, etc. I can be still living in the pink world of discovering what it is to develop software, but this view has its interests too. And besides, I don't see why the pink should fade away. I have nothing against la vie en rose.

When you write an essay, it is implicitly expected that it is not short. That would mean lack of reflection, some laziness, up to show off pretentions in the worst case. To that I want to reply that as a scientist, I consider conciseness a virtue. Along with its sister precision. That's the ultimate goal. Concise and precise. All that's needed, nothing more. Instead of the Saint-Exupery quote I prefer one from Pascal, in a letter to a friend: excuse me for writing you a long letter, I did not have the time to make it shorter.

Time is an issue too. Took me an hour to try to write an essay, takes me as much to write this one. Here too, it is just a matter of habits, typing speed, and experience. All I need to do is find more time to write. And by finding I mean taking. Just a matter of organization, nothing more.

In the end, writing essays is really a fullfilling experience. It is good to write down these ideas that lurk in the brain, surfacing from time to time. Writing an essay for these ideas forces you to take the time to give it more thought. It is very likely that writing an essay opens several new ideas, which makes them even more worthwhile.

Time has come for me to introduce funfem. funfem is the functional finite element library. I could say it is a functional finite element library, but there aren't enough of them to say it is yet another finite element library. To my knowledge, only femlisp exists, and it does not emphasize that much on the functional aspect of it. Funfem is open-source; it follows a BSD3 license.

The 'fun' in funfem has at least three meanings:

1. fun as in functional.

2. fun as in fun.

3. fun as in fundamental.

Let's explain these points in more details.

First, I am learning Haskell, and there's nothing better than a project to go in the details and have a better understanding of the language. But more than that, I want to show that functional languages are also well-suited for scientific/numerical methods. After all, the finite element method is a set of functions and relations, which are first class citizens in functional languages. I am convinced than once Haskell syntax is understood, which takes less than apprehended, the organization of the program and the method are simpler to grasp than the flood of imperative loops.

Second, believe me or not, it is fun. This is not the first word that comes to mind when thinking of finite elements, but out rooting it from its imperative culture is really a lot of fun. I have been asked why I was not implementing more 'haskell-ish' programs, like chess games or sudoku solvers, instead of yet another finite element library, or why I wouldn't want to write a Haskell wrapper around a C++ 'fast' library instead. My answer was that language where it is not expected is fun (after precising that functional languages are far from confined to those cliches). Attacking the FE method with a functional approach is fun. As James Hague put it nicely when explaining why Erlang for games, 'it seemed so perverse': that brings its amount of fun in itself. Moreover, I work on this library on my spare time, so if there is no fun, there is no point in it.

The third point is about the nature of this library. Funfem is an experiment. It is not aimed to be used in the industry; there are already plethora of libraries that focus on performance, features, etc. Funfem is a crucible for students, researchers and any curious mind. There won't be tuning techniques, benchmarks to see if I gained 32ms at the cost of obfuscating the code. I want funfem to be crystal clear, nearly a bit naive, so that students can learn the FE method easily. To show that Haskell is more friendly and less esoteric than the imperative point of view might suggest. Simple enough to invite imperative programmers to look into the code.

Yet it does not mean that I don't want it to run smoothly. I want to be able to run consequent models in a reasonable time. Not the fastest I could get, but reasonable enough. I intend to parallelize it to gain some performance, to learn then show how easy it is with Haskell. I love Haskell because I spend much of my time thinking about the algorithm instead of implementing it. I hope that in this respect funfem will leverage new approaches on the algorithms used generally in the FE method, or even new algorithms. I am curious about what a plasticity law will look like in funfem. You get the idea: I want funfem to be the tool that allows easy implementation of new ideas, approaches, while not having to fear an off-by-one mistake. This is where I think the functional approach will shine.

Funfem aims to be generic. Users should be able to model physics and couplings between them simply. For example, I am quite curious about the implementation of avalanches and glacier dynamics. This has to be easy to implement in funfem. If not, it will mean that the library is not simple enough. A note on the features. I'd like funfem to have:

• a mesh generator for at least triangles

• post processing facilities: VTK output, or some other formats that enable good visualization at low cost

• support for any kind of element

• support any kind of integration method

• parallel capabilities

... and many more. All written in Haskell of course. That's a long road, but I am in no hurry.

About the status. You will not be surprised to read that the 0.0.1 version is not even finished. I'll upload it to Hackage when I have something playable with. That should be soon, still. You can find the code at the darcs repository or browse it on the website. There is also a github mirror.

I'll be writing extensively about it. Any feedback welcome.

I hope you will enjoy it as much as I already do.

Recently I have moved from Django to static pages for my blog, using a Perl script and a git post-receive hook to trigger the updating script. That was too tempting not to write it in Haskell. The full source code is available on GitHub

Let's start with the central data structure, the Entry data type:

data Entry = Entry {
    entryUrl :: String,
    entryDate :: CalendarTime,
    entryTitle :: String,
    entryTags :: String,
    entryBody :: String}
        deriving (Eq, Show)

An Entry contains its relative url, its post date, title, tags and body. I chose CalendarTime to access to full letters days of the week, but other formats would do too. I will change the tags to a list of strings to group entries by tags. I defined a couple of functions to take care of the formatting of the dates, for the RSS feed and the sitemap.

I will need to sort entries according to their post date to display the last one on the main page and to list them on the archive page. So let's just derive an instance of Ord accordingly:

instance Ord Entry where
    compare e1 e2 = compare (entryDate e1) (entryDate e2)

Two lines. Using Perl I had to hash the date to sort it using the builtin function. Not a big deal, but more book keeping and code.

The body is of type String to make it more portable. Using Pandoc's Markdown facilities, it is also simple to convert it to html:

markdownToHtml :: String -> String
markdownToHtml s = let md = readMarkdown defaultParserState {stateStrict = True} s
                   in writeHtmlString defaultWriterOptions md

Now the html part, the core of the script. I use mainly the blaze-html library from Jasper Van der Jeugt. The approach is elegant and convenient, using combinators to write html. It also has nice documention and tutorials. One thing that I like about it is the ease to create templates. I have two different type of pages: blog entries and the rest. The template changes in few places, namely the meta tags, the title and the comments. The head of a non entry simply needs the title of the page, if any:

htmlHead :: String -> Markup
htmlHead t = do
    H.head $ do
        meta ! httpEquiv "content-type" ! content "text/html; charset=UTF-8"
        meta ! name "keywords" ! content "adrien haxaire, programming geomechanics"
        link ! type_ "text/css" ! rel "stylesheet" ! media "all" ! href "base.css"
        H.title $ toHtml ("Programming Geomechanics" ++ t)

The (!) function allows a natural chaining of the tags, as you can see for the link to the css file for example. For an Entry, I add more information through the meta tags; the structure is similar:

entryHead :: Entry -> Markup
entryHead e = do
    H.head $ do
        meta ! httpEquiv "content-type" ! content "text/html; charset=UTF-8"
        meta ! httpEquiv "Last-Modified" ! content (toValue $ show $ rfc882 e)
        meta ! httpEquiv "expires" ! content (toValue $ show $ expireDate e)
        meta ! name "keywords" ! content "adrien haxaire, programming geomechanics"
        meta ! name "keywords" ! content (toValue $ show $ entryTitle e)
        meta ! name "keywords" ! content (toValue $ show $ entryTags e)
        link ! type_ "text/css" ! rel "stylesheet" ! media "all" ! href "base.css"
        H.title $ toHtml ("Programming Geomechanics | " ++ entryTitle e)

The fuction expireDate is just some formatting on the date to fit the requirements of the http-equiv attribute. You can see that it is quite simple up to now. I could try to factor out some bits and pieces, but I'll do the polishing later.

Now that the head is defined, we can define the template for the body, taking the contents of the body as argument:

htmlBody :: Html -> Markup
htmlBody contents = H.body $ do
                      entete
                      contents
                      htmlFooter
                      googleAnalytics

Here, entete, htmlFooter and googleAnnalytics are necessary boilerplate for the navigation and the banner, the footer with the licence and the Google Analytics script. Now comes the best part: we can compose heads and body to generate the templates for the entries and the other pages:

htmlTemplate :: String -> Html -> Html
htmlTemplate pageTitle contents = docTypeHtml ! lang "en" $ do
                                    htmlHead pageTitle
                                    htmlBody contents

and

entryTemplate :: Entry -> Html
entryTemplate e = docTypeHtml ! lang "en" $ do
                    entryHead e
                    htmlBody $ entryContents e

Nice, isn't it? That's flexible, simple and easy to troubleshoot, which is something you want when writing html. The entryContents function is just wrapping up in a div the text of the blog entry. It also includes the javascript code for the Disqus comments.

To write my entries on the disk, I use the standard writeFile IO function, calling renderHtml to generate the output string:

writeEntry :: Entry -> IO ()
writeEntry e = writeFile filename (renderHtml $ entryTemplate e)
    where
      filename = "public/" ++ entryUrl e ++ ".html"

To apply it to all the blog entries located in the entries folder, I list the files in that directory, I create Entry from the markdown file, then apply the writeEntry to all of them.

markdownEntries :: IO [String]
markdownEntries = do 
    es <- getDirectoryContents "entries/" 
    return $ L.map (\x -> "entries/" ++ x) (filterMarkdown es)
      where 
        filterMarkdown = L.delete "." . L.delete ".." . L.filter (L.isSuffixOf ".md")


entries :: IO [Entry]
entries = do
    mds <- markdownEntries 
    rmds <- mapM readFile mds
    return $ L.map entry rmds


updateEntries :: [Entry] -> IO ()
updateEntries = mapM_ writeEntry

I am quite sure the entries function can be turned into a one-liner, I'll investigate it; at that time I simply wanted something that works. Edit: I've just found it:

entries :: IO [Entry]
entries = liftM (L.map entry) (markdownEntries >>= mapM readFile)

I forgot to mention how to create an Entry from a file. The entry function wraps the different parsers and yields an Entry from a string, the contents of the markdown file. I use Parsec for that (this will be the topic of a future blog post).

If we do not consider the boilerplate needed for the head of the template, you might acknowledge that it's quite simple, clean and small. I'd like to add here that in other frameworks, the templates are in separate files, with specific templating system. Here, everything holds in one file. That's quite nice to maintain and to get the global picture of it. And I really do like the concept of my blog being only one file.

That's all for the conversion of the markdown entries. The index page is the last entry, without title. It already pays to have decomposed the templates because I want the title and the meta tags to remain unchanged, at least if I understood some basic SEO. So let's just apply the html template to the last entry, that's straightforward.

updateIndex :: [Entry] -> IO ()
updateIndex es = let filename = "public/index.html"
                     contents = entryContents $ maximum es
                 in writeFile filename (renderHtml $ htmlTemplate "" contents)

I will skip the RSS feed and the sitemap as they are mainly boilerplate. They have some dynamics in them, as they are updated depending on the number of entries. This is also the case for the archive page, so let's explain this one instead. Good practice is to get away from the IO monad as soon as possible, to work with pure functions. It is just a write operation, so it might not seem so risky. The point is, in Perl I was opening the file and writing directly in it. Lots of things could happen before that was finished. I prefer to reduce the IO to its minimum, i.e. flushing a string in a file. For this, I create a wrapper around the archiveContents function:

updateArchive :: [Entry] -> IO ()
updateArchive es = let filename = "public/archive.html"
                       contents = archiveContents es
                   in writeFile filename (renderHtml $ htmlTemplate " | Archive" contents)

In the archiveContents function, we take advantage of the monadic behaviour of blaze-html by using forM_, which acts as a for loop, on the function archiveLine that writes one line for each entry:

archiveContents :: [Entry] -> Html
archiveContents es = let ses = reverse $ L.sort es
                     in do 
                       H.div ! A.id "contents" ! A.class_ "container" $ do 
                          p "Previous posts:"
                          forM_ ses archiveLine


archiveLine :: Entry -> Markup
archiveLine e = do 
  p $ do 
    a ! href (toValue $ absoluteUrl e) $ toHtml (entryTitle e)
    toHtml (", " ++ (publishedOn e))

That was really an eye-opener for me. It is much more than appending strings. I could have had the same effect with Perl by using the for loop to create a string then flush it too in one print statement. The difference is that in Perl, it felt awkward to do so. In Haskell it seems natural. Run away from the IO monad, and write functions with predictible behaviour. It also shows that the blaze-html library is well thought as this is easily done using monadic operations. To generate my archive page, it only takes three small functions. I could have made a single bigger one, but I prefer small pieces that do one thing but well than confusing longer ones.

To use the runhaskell command to run is as a script, I gather all the updates for my blog in the main function.

main :: IO () 
main = do
  es <- entries
  updateEntries es
  updateIndex es
  updateArchive es
  updateRSS es
  updateSitemap es

In my web server, I replaced the call to the Perl script in the post-receive hook by this new Haskell script, after sourcing my bashrc file to load my custom Haskell install on the server. It's funny to call it a Haskell script. That seems so diminishing. But not at all, to the contrary. This shows that Haskell is also well suited for those kind of applications. Little scripts that used to fall under the realm of Perl are also simple and small using Haskell. But most of all, this is a very good way to learn lots in Haskell. The basic parts, simple IO, parsing files, etc, having something that does the job. Doesn't need to be shiny, just an answer to a simple need, moving my blog from Django to static html files. A good way to understand monads is to use them, using IO or blaze-html or Parsec. I'm really happy to have this very small piece of code working because it is a real application that will do something for me and also because it demystifies Haskell for me. I used to have this idea of etheric libraries, not really tangible, as the one I am writing, and that needs many pieces to be useful. This project makes Haskell more concrete to me. And that's a good step.

A few week-ends ago I wanted to clean up my Django-powered blog. But it went wrong, and even if everything was under version control, I decided not to use Django for it anymore. Don't get me wrong here, I still think it is a great framework and I use it for the website of a friend; it is also a nice occasion to play around with Python. However, for my personal blog, I did not want to use a framework anymore, and even less a CMS.

I ended up with plain static html files. But I am not sadistic so I came up with this solution: write entries using markdown then convert them to html. I'd still need something to update my website automatically. Let's then just use a post-receive hook to run the script. This engine, if I may use this word, is then two, and only two things:

1. a script to update the blog when there is a new entry

2. a post-receive hook to automate it

I chose git for convenience, but I could have used darcs as well. I know I am not the first one to have this idea, I think the gitit wiki does it too, but it is not quite widespread. Which is understandable when you see how easy it is to have a blog nowadays. You can argue that I will always need ssh access to my web sever to upload a blog post. That's true, but anyway I only write them from my laptop. But the main point behind this choice is to get back to the basics and learn more about how a sitemap and a rss feed work, write clean pages, not the ones generated automatically by a CMS or give away my raw blog entries in a database somewhere. I'm quite sure it is possible to retrieve them back, but the time needed to find out how would be the same as writing the full engine.

It took me one full saturday, using Perl, to get most of it working. Messy and clumsy, but enough to go live by the evening. I cleaned it up since, and you can browse it here if you are curious. Nothing incredible, a bit naive sometimes, but my whole blog stands in 200 lines of Perl. And that's quite good. This is simple, efficient, robust and fun. I learnt a lot in crafting the rss feed and the sitemap.

I drop the idea of enabling comments for now, I'll see how to add them in due time. I'm quite curious about how a raw post request works and how to incorporate reader interaction in this static system. I'd like to have the comments directly written into the html page, but I suspect I'll need some javascript here.

The last thing I need to explain: the post-receive hook and how to set up git on the webserver. I found a tutorial that explained exactly what I wanted to do. I just added a call to the update.pl script and that's all.

So once again, going minimalistic has brought me lots of satisfaction and some knowledge. The funny thing, and it occurs to me more and more often, is that I start to understand the bare concept faster than when using a 'simplified' indirect approach, with metaphors, examples, etc. Seems I am getting better at programming after all.

PS: if you have looked at the github page, you may have seen a file named update.hs... that's for soon.

I came to ArchLinux in the mindset of taking more control over my OS, but also to move away from the eye-candy-yet-bloated desktop environments. So when I installed Arch I also installed Gnome 3, while I got used to the OS. Gnome 3 is nice, and I enjoyed using it. Still, my laptop is old, has a chipset instead of a proper graphics card so it was slow. The more important point is that I no longer appreciate this cpu expensive eye-candiness. I want speed and simplicity.

I have then replaced it with Xmonad. Being written in Haskell is not the only seducing argument. Is is simple, lightweight and fast. I removed all the Gnome things I could, from gdm to nautilus, and I use a slightly tweqked default configuration. No toolbar, no taskbar, no notification area, not even an xmobar. Nothing. I use dzen2 for notifications with the urgentHook, it works fine. I rebound the mod key from alt to super, switch desktop with super + arrow, close a window with super+`, defined a .xmodmap to replace capslock with control, set the focus color to black, and that's mainly it. Ah I added some more lines to my .xinitrc, like the dropbox daemon, the wallpaper (!), unclutter, etc. In the end, that's minimalistic, simple, fast and fun! I love not having window borders anymore.

Going further with this approach, I started replacing the GUI applications with their CLI counterpart. Exit Thunderbird, hello Mutt. No more Rhythmbox, instead the combo mpd + ncmpc. Nautilus... well... I am getting better at the cli. Eye of Gnome? xv or feh. In the end that's it, I don't have that many applications on my laptop. I have defined lots of aliases, like 'music' for ncpmc, some directories shortcuts, etc. Takes a bit of time to get used to it, but dear! I don't regret it.

I guess next step is to create a commandlinefu profile :)

Everything should be made as simple as possible, but not simpler. A. Einstein

Last week I decided to move to ArchLinux.

I wasn't excited at all with the release of Oneiric, as it was all about unity, and nothing more. The ubuntu button moved inside the dock, not in the top level bar, etc. I upgraded from Natty and everything went flawless as usual. But when I saw I had to use unity, I just got bored of having things decided for me. Of course I could have tried to use gnome-shell instead, or put KDE. I have a latop with a video chip, so Ubuntu was running slowly, and last time I tried KDE 4 I thought my laptop was about to melt. So instead of reinstalling a fresh Ubuntu 11.10, I just opted for a new distro, simple and lightweight, to have my laptop at full speed again. There are plenty of lightweight distros. Debian and Ubuntu based as well. I've heard lots of good points for ArchLinux in the Haskell mailing lists. But most of all, it just looked so fun. ArchLinux is a rolling distro, meaning that you can update your packages when a new version of the package is out, which is way more frequent than every six month. I think this is very nice; I like to have the latest version of the softwares I use. If I find a bug, then I just fill it instead of complaining about it. So let it be ArchLinux.

Here we go:

• read the installation guide,
• grab the install image,
• put it on a usb stick,
• read the installation guide again,
• backup all my data,
• format and partition my hard drive with a live gparted cd for the new install,
• open another laptop to check the installation guide if needed,
• plug the usb and reboot

The installation went flawlessly. It reminded me of my first install of a fedora core 5. There are some config file to edit manually, the ones with the scary name, such as /etc/rc.conf. Actually it was much simpler than I thought. I did not have network at the beginning because I put wrong information in the config file. Set up to be automatically determined for me worked better. I installed it with a cbale and the battery plugged by the way. This simplified lots of things. The funny thing is that you do not have Gnome or KDE, you do not have X at all. You have no user other than root, no sudo. And that's excellent. You install exactly what you want. I just wanted to have it working for starters, so I installed emacs, sudo, added a user, installed X and Gnome 3 with Gnome Shell. I'll go to simpler and lighter when I am more used to ArchLinux. Reboot, some problems once or twice with my ~/.xinit and after that, everything was alright. Total time, 2 hours I think. Next time will be 30 min I think, as now I know how to do it.

First remark, may it be Gnome 3 and Gnome-Shell, that's pretty fast, even on my laptop! More than Unity for sure. That's exactly one thing I was looking for when coming to ArchLinux. I did not install the whole desktop environment; didn't want evolution, tomboy, etc. Keep it simple, manageable. My laptop is for home use, so I do not need that many things in it. That's a really nice desktop environment. Still don't know why Ubuntu dropped it. I was used to my four virtual desktops making a 2x2 square, so I'm still not completely used to the vertical line. Anyway, Alt-Tab is always faster. I installed some simple and basic things like evince, file roller, etc. The package manager, pacman, is quite nice and often adds advices for installing other packages, or configuring a new package. By the way, this does not take that long. Mostly a couple of minutes when you stumble upon a file you cannot open, or half an hour if you want to add some programs you know you'll need, like an email client, Gimp, git, svn, the haskell-platform, etc. There are thousands of unofficial packages in the AUR, the ArchLinux User Repositories, that can be installed simply. I installed Dropbox in few minutes and enabled it manually by adding it to my ~/.xinitrc file.

The promise of ArchLinux is kept and true. It is simple because it does not decide everything for you. Once you edited some important config files more than once, you get used to it, and best of all, you understand them. I have learned more on GNU/Linux in one week than in the last year. Which is why I also wanted to move to ArchLinux. By the way, Archlinux is fine for newcommers too if they want to learn GNU/Linux and are not afraid of playing around with the terminal. In the end, it is true that editing directly the config file is simpler than accessing it through a menu for administrators with an application we may not want to spend 15 minutes to find, not knowing what it will do. All this ease of use and simplicity in ArchLinux comes also from the documentation on the ArchLinux wiki. Everything is written thoroughly.

In conclusion, I am more than happy to have made the switch to ArchLinux. It is an insteresting distro, simple to use, and fun. Of course Ubuntu remains a good distro as well; but if you want to understand linux better, to give a new youth to your computer, and know a bit more what's inside a linux OS, then you should definitely give it a try.

For some time I was looking at a functional language to learn, as it is another approach on solving the problems we encounter every day. I started to look at Erlang, as it is used for CouchDB. Still, it is more network oriented, and I wanted something more general. I also thought of Lisp and Scheme. Then I stumbled upon an article from Simon Peyton-Jones, "On the importance of being the right size: the challenge of conducting realistic experiments". I then took the firm decision of learning a functional language, and that this language shall be Haskell.

My motivations are partly summarized in Why Haskell matters. First, functional programming opens a different approach on programming. This will give me an other look on the way to program with imperative languages. Second, all the advertisement on side-effect free programs is interesting, as I mentioned in a previous post. Now every function I write in Fortran will be at least pure. The laziness of Haskell didn't strike me at the first time, it was not a strong point to convince me. I see now why they emphasize on it. The same with the strong typing, by the way. One thing which seduced me is the elegance of functional programs, and the one in Haskell more particularly. I like the quicksort algorithm they describe because it focuses more on the algorithm than in its implementation itself. I have read that several times: "write what you want to do, and not how you want to do it". This is really enjoyable.

But one of the most important point is the community. I felt at home there, with people contributing, helping, and putting efforts on writing elegant and efficient programs. I will find many places, links and people to learn more on computer science, functional programming in general, with a hogh level for a newbie as I am in this field.

As I was looking for a book to learn it, I found Real World Haskell, which is free online. I then decided to buy a paper copy of the book, as I prefer to read on paper, and to contribute to the work of the authors. 700 pages which will keep me busy for a while. And this is a good thing: I did not want a sparse book that you can read only once (cf. PragProg and co.).

So, here I am, starting from nearly scratch, as I have to forget about many habits I have developped with imperative languages. And this is good. Dear, I should have done that long time ago.

In Fortran, a keyword I haven't used enough so far is PURE. We want functions but also many subroutines to avoid side-effects. To ensure this, Fortran let us add the keyword PURE in front of a procedure declaration in order to tell the compiler that it does not contain any side-effect.

As I keep forgetting the list of things to avoid in a PURE procedure, I write them down here in order to find them quickly too. Acccording to Wikipedia, the procedure should:

• alter no global variable,
• perform no I/O,
• contain no saved variables (i.e. no SAVE attribute),
• not alter any of its arguments if the procedure is a function.

The first point is easy to tackle, in the idea that global variables should be used for constants (to avoid magic numbers for example), or in some rare occasions.

The second one avoids debugging with print statements. However, we can either remove the PURE keyword when debugging, or use unit tests.

The third one is not that difficult too, as the SAVE attribute can either be avoided with another design for the procedure or put in a wrapper subroutine for example.

The last one can be summarized by declaring all the variables as INTENT(IN).

To me, this appears more as common sense than restrictive conditions. At least, with the statement, the compiler can help us writing better code. I still need to find the exhaustive list of the conditions for a pure procedure, though.