Category: Programming

Categories
Programming

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).

Categories
Programming

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.

Categories
Programming

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.
Categories
Programming

Programming nirvana part 2: be agile

In part 1 I made the very brief argument that compiling sucks. I really like that cartoon since there is a lot of truth to it. Compiling sucks mainly because it breaks flow. There has been several tries to fix it by lowering the time it takes to compile but in the end, it’s still the same loop: write, compile, “debug”.

There is another layer to it as well, one that dynamic languages doesn’t necessarily imply: Developing a program should be having a running program that can be used while it is being written. This is one of the pillars of agile programming. Step one in achieving this goal is to separate the UI from the backend. Web is a natural way to do this.

Django comes very close to achieving this with it’s automatic reloading on change, but the biggest problem is that it’s not able to automatically migrate the most basic model changes. On the other hand Django has many other things going for it so it is by no means a bad choice. But there might be a better one lurking in the dark.

Categories
Programming

Programming nirvana part 1: avoid compilation

I have been meaning to write about a new project I have been working on in my spare time for a while now. It’s a project where I wanted to maximize the fun I had doing it, learn something new and to do something that I can use. Sadly I have been putting it off since enumerating all the reasons feels like quite a daunting task.  So instead of writing everything in one big blog post I’ll just do shorter posts. One for each argument. First one is pretty simple.

Categories
Programming

Go

Google released a new system programming language. I wonder if the names of Robert Pike and Ken Thomsen will make it more appealing to C people 🙂

It’s clearly meant to go head to head with C++. The two most interesting design decisions to me is their take on OO (feels like templates done right and no crappy inteheritance in the ordinary sense) and concurrency which looks a lot like Erlang because it’s CSP. Both of these things make it feel very functional.

So many languages to tinker with and so little time 😉 Oh yeah and it doesn’t run on Windows yet 🙂

Categories
Programming

On designing libraries

I recently finished up a big project at IOLA which used two major components: Javascript and c# (.NET). It was interesting for me to see the big difference in the libraries for these platforms. For Javascript we used the excellent jQuery library. For .NET we used the very buggy Devexpress library. jQuery, like Javascript, is very simple. .NET on the other hand is overload with interfaces and concepts. What is interesting of course is that this philosophy shines through in libraries build on top of both platforms.

Devexpress is overloaded with concepts and the size of the library is just insane, the latest release is 221MB excluding kitching sink. Compared to jQueries 19KB. jQuery on the other hand focuses on a simple core with just the right amount of abstractions (very lispy), and delegates specific functionality to plugins, such as flot. The difference of course in part comes from the fact that jQuery is an open source project, while devexpress is a commercial project.

You just have to look at the release notes for each of these projects in order to see the difference. jQuery focused on making their already working code faster and fixing bugs. While devexpress spend most of their time added a number of new features. The problem is that in a commercial project fixing bugs doesn’t pay up as well as implementing new features. Or at least that used to be the case. In the era of google that simply is not true. Anyone can put in devexpress and find out if the library sucks (which it to a large degree does) or if it rocks. The sooner they realise that small is the new big, the sooner we will start getting better libraries.

Categories
Programming

Closures

I had a real “aha moment” today while coding some javascript. Let me first start this post with a quote:

The venerable master Qc Na was walking with his student, Anton.  Hoping to
prompt the master into a discussion, Anton said "Master, I have heard that
objects are a very good thing - is this true?"  Qc Na looked pityingly at
his student and replied, "Foolish pupil - objects are merely a poor man's
closures."

  Chastised, Anton took his leave from his master and returned to his cell,
intent on studying closures.  He carefully read the entire "Lambda: The
Ultimate..." series of papers and its cousins, and implemented a small
Scheme interpreter with a closure-based object system.  He learned much, and
looked forward to informing his master of his progress.

  On his next walk with Qc Na, Anton attempted to impress his master by
saying "Master, I have diligently studied the matter, and now understand
that objects are truly a poor man's closures."  Qc Na responded by hitting
Anton with his stick, saying "When will you learn? Closures are a poor man's
object."  At that moment, Anton became enlightened.

When I first read this some time ago I thought I understood it. I did not I now understand and my aha moment today proved that. I have written way too little pure functional programming to really appreciate and use the power of closures. Not to say that objects are useless. That’s exactly the point of the quoted text. Just that the ability to define closures inside closures inside closures is a really really powerful concept. The idea is that sometimes code gets repeated in a function inside a class. Typically you pull that into a helper function and stick it on the class, but sometimes the function is so specialized that it has no livelihood in the class. Secondly the ability to bind local objects to closures, and use those closures as state is another aspect of closures that is immensely powerful.

Categories
jvm Programming

Clojure

This is perhaps one of the most interesting talks I have heard in a long time. The talk is about a modern implementation of lisp for the jvm which is designed for concurrency.

Categories
Programming ruby

Beautiful code = proportionality, integrity and clarity?

Writing beautiful code is such an elusive subject. I’ve never been able to put into words what makes code great, it’s sort of these things that just is. I even read a book on it once, and while it had some quite tricks and hacks along the way, I never really thought I got closer to a definition of what beautiful code is.

I saw this talk about beautiful code yesterday. The talk is from a ruby conference and starts a little slow, but around 18 minutes in, it gets really interested. His main thesis of the talk is that beautiful code can be defined using only three measuring sticks: proportional – 200 lines to read a simple file (Hello C)?, integrity – does it actually do what it’s supposed to do and in a reasonable fashion (speed, memory usage etc.) and finally clarity – can you grok the code again quickly 2 years after you wrote it in the first place (Hello Perl). Each one of these must be balanced.

Can beautiful code really be captured by three such simple rules? Rules that individually seems to be far from beautiful, instead much more functional in nature.