Tag Archives: clojure

Time in a database

For some applications, the ability to be able to trace the different states during the lifetime of data can be very important. Especially when it comes to debugging. This is mostly relevant for data stored in a database, but could potentially also be interesting for in memory data structures. Luckily many databases today support this as change data capture. I would add to the article that the capturing the user as part of the change can be very effective.

I have recently been involved in the development of two systems where this pattern has been employed to great success. One where this was implemented in hand, and one where CDC in SQL server was used. The hand implemented solution had some special requirements that meant we did this in hand, and it also doesn’t tie us to a particular db. While not free at all, once it is up and running, it provides an invaluable tool for reasoning about the data.

I was very pleasantly surprised when datomic was announced with a time model as one of the core concepts. I really think that in this age where storage is so cheap, that we can’t afford to threat data as mutable.

Language design

When talking to people about the benefits of clojure often people point out that most modern languages have evolved to “support” the functional paradigm with lambda functions. The argument is that one can stay in the familiar safe environment of imperative programming and use the functional constructs when they fit the problem better. That is a very valid and good strategy but I’ll show in the following that it brings a whole lot of accidental complexity with it. Some of this is specific to the way .NET is implemented and some are a clash of the functional paradigm with the imperiative.

Exhibit 1:

My favorite example is what has been known in the office as the lambda bug. Coming from a background of having been coding in C++ for a couple of years, we switched to python in the last semesters of University. The lambda bug manifests itself when one combines two classical constructs of two different programming models: for-loop iteration and closures:

foreach (var i in list)
save_callback_function_for_later_use(x => System.Console.WriteLine(i));

Given that list contains the numbers 1,2,3,4,5 guess what the code will print when all the callback functions are called?

Exhibit 2:

In C# events seems to have been programmed to a pre-functional model and never updated when they added functional constructs. The interface for an event is += for adding events and -= for removing. This is all fine for point-and-click GUI programming. Meaning it works good on something like event += somefunc; and not event += delegate { use_the_power_of_closures_Luke ) 🙁

To add injury to insult, events doesn’t even support something like clear().

Exhibit 3:

In clojure all the seq library is lazy. Thus once one has figured that out (I must say it took a little while for me), everything behaves as would be expected. In C# some things are lazy (linq) while others are not. Imagine list contains 1,2,3. Then the following works:

var changed = list.ConvertAll(x => x * 2);
list.Clear();
list.Add(something)
list.AddRange(rest);

But the following doesn’t work because it behaves lazy:

var rest = observablelist.where(x => x != 1);
observablelist.Clear();
observablelist.Add(something)
observablelist.AddRange(rest);

Try guessing what the outcome of running the code above will be. I’ll confess that it was different from what I expected it to be.

Again it’s mixing two styles of programming, functional lazy code with imperative mutable objects.

Finally, my argument is that a language with clean design principles, even with relatively steep learning curve, far outweights the complexity of industry standard languages in the long run.

mucomp released into the wild

Today I’m happy to announce that the world is one audio player richer! This is a personal project of mine that I have been working on for a little while. It’s written in clojure and javascript (jQuery) and uses alsaplayer as the audio player. I probably won’t have much time to hack on it, so consider this a code dump that hopefully someone else will find useful and play/run/do-whatever with. As for maturity I use it almost daily and it’s pretty stable. There are some known bugs and kinks (mostly due to that its using alsaplayer and that the java inotify library is buggy).

Programming nirvana part 4: the repl

A repl is a very important tool in the arsenal of a programmer. It allows one to test bits and pieces of code and then assembling that into a running program. Examples of this includes the excellent firebug utility for firefox and various shells (like the python shell). There has even been tries to bring a repl to C#, but the languages is not at all designed for this purpose, so it’s a crude hack at best.

Often developing using the repl consists of a lot of copy pasting back and forth between then editor and the repl. Moving the repl into the editor makes this even less painful, but I would argue that in order to fully embrace a repl one has to have something like lisp, or a very good editor (that I havn’t seen yet). In lisp it’s very easy to take parts of a function and evaluation only that part simply by finding the right parenthesis and evaluation that. Using Emacs and SLIME it’s a simple two-key-gesture.

But one can take it one step further. Why not simply start your program as a repl, instead of adding a repl to your program. That way also the running state of the program can be determined. But in order for that to work, one has to be able to redefine functions without stopping the program. Clojure allows that, and it’s the key that makes it all work.

Programming in clojure is a process of organically growing your program in a bottom-up fashion where the running state of the program allows one to inspect, debug and fix programs all without shutting it down.

The best way to do this is to start up a repl in a seperate process and then to connect to that process, that way one can always disconnect and reconnect again when the need arises.

Programming nirvana part 3: avoid relational databases

This is actually a blog post I have been meaning to write for quite a while not, but I just never got around to it. Relational databases are ubiquitous in programming. Whether it’s mainframes, application programming or even phones now a days everyone stores persistent data in a database. Recently there has been some talk about non-schema databases and there’s a myriad different implementations of them, but why the sudden interest?

  • Database has at least two things that makes it less than ideal for agile development. First one being types, especially if the types propagate out into the application code (*cough* Microsoft). The second being based on a schema, which means that one has to make all the choices up front.
  • Databases are really built for a single machine, and even though all the big database vendors has replication support, it still seems like a bad solution if one really wants scalability. There are a lot better ways of doing scalability now a days (a distributed hash tables comes to mind).
  • Databases are meant to be standardized, but in reality they are not. They all have different syntax to do common things.
  • It has been said that when you build a DSL, then sooner or later it will turn into a (bad) full-fledged programming language. What if instead the data was simply part of the program and you could manipulate it as you are used to? Functional languages makes this much easier and possible. Especially a programming language that is built with concurrency in mind.