Category: boo

Categories
boo c# cpp profiling Programming

The problem with static typing in programming languages

I remember reading in Paul Grahams excellent hackers and painters book, about how he liked the language he worked in to be dynamically typed as it provided him with more flexibility. The first time I read it I was still very much entrenched in the bondage and discipline language C++, and as so I found the statement wrong, but at the same time interesting. There had to be some deeper insight into this. A couple of years later, which would be the present day it just dawned on me that the biggest problem with statically typed languages are not the typing, you can get used to that. Its rather the fact that it becomes very hard to refactor the code afterwards. And worse, it shifts the burden of figuring out the right data structures and the right types to the beginning of the coding process instead of afterwards. Thus going directly against the good programming practice of writing for clarity first and only rewriting code if it has been deemed inefficient by a profiler.

Python is dynamically typed and after spending a year programming (this was about two years ago) in it I still found the fact that the types where missing to be quite disturbing. Especially the fact that you could have a branch in your program that had a small spelling error and only failing after you had run the program for several hours maybe. Or worse shipped it off to the customer. I realize now that this was mostly contributed to the fact that I was still coding Python as if I was coding c++. Something that the last two programming books (common lisp and programming erlang) I have been reading really have put to light.

There are tricks you can use in statically typed languages that can make the program easier to refactor later on. The var symbol introduced in C# 3.0, using typedefs in C++ and actually the whole standard library in C++ has had this covered quite nicely with the use of iterators. Still I think that maybe something like the duck types in boo brings about some interesting mix of the two styles. My very limited experiences with the boo so far has not been enough to determine if they the implicit type system does more harm that good. I sometimes find myself cursing over the fact that the system can’t detect the types for me, and at other times are happy that the system has found some trivial errors for me for free.

Categories
.net boo Books c# lisp Programming

Finished reading Practical Common Lisp

Finally got through the mighty Practical Common Lisp tome. The style of the book is written in a nice mix of theory and practice (with relevant and good examples). My friend Lau asked me why on earth I would want to read a book on Lisp? A fair question since Lisp is really old, actually measured in computer time it might even be called ancient. But I had two main motivations for reading the book, to become a better programmer and secondly to better understand new language features introduced in languages like Boo and C#. Just look at the new LINQ features in C# 3.0 and specifically this video.

I wholeheartedly recommend this book to anyone interesting in a good programming book.

Categories
boo c# lisp Programming python

The power of lisp part 2

As mentioned earlier, lisp is incredible at abstracting away small everyday stuff you write over and over. A good example is this way one has to define a local variable in order to make variables sucked into a delegates from the surroundings static in C#. As mentioned briefly in this blog post, one needs to change the loop to read like the following code for it to print 0 to 9 instead of 10 times 9:

foreach (int i in numbers) {

        int j = i;

        l.Add(delegate() { System.Console.WriteLine(j); };
}

In lisp one would see that this is a pattern and simply abstract it away like this. As one can see, the macro static-loop is more or less exactly the same as the pattern which luckily made it quite easy to write.

(defmacro static-loop ((i container) &body body)
 (with-gensyms (j)
  `(loop for ,j in ,container do
    (let ((,i ,j))
     ,@body))))

The only small trick is the with-gensyms macro which prevents leaking the temporary variable j into the scope of where it will be substituted into. So in that regard the macro is even nicer than rolling your own temp variable hack 🙂

For reference the python example works the same way, but allows one to use the lambda function to redefine variables, although one must note that the static-loop solution is more general in that it will make the loop variable local for the whole scope and not just for one lambda function. Funny thing is that I had originally written it like this, which actually worked, although that means that the closure binding is not only by reference but by name.

I tried writing the macro in boo but I failed. Apparently their macro support is still quite new and there’s close to no examples to draw inspiration from. If anyone could help me out with the solution please mail it to me or even better add it as a comment.

Categories
boo Books Programming

The power of lisp part 1

Lately I’ve been reading the book Practical Common Lisp. My earlier experience with lisp was at the university where I briefly touched lisp in the form of the Scheme dialect. After having read Paul Grahams excellent Hackers and Painters twice, I thought it would probably be a good idea to see if lisp lived up to the hype. After seeing Practical Common Lisp being recommended by bamboo of boo fame and seeing this google tech talk I was convinced that the book was the best way to see all the wonderful stuff lisp has to offer.

So far I’ve been quite impressed with some of the things one can do in the language in a very elegant way. And I suddenly understand why closures work the way it does in C# and python. The problem with moving stuff from a really dynamic language like lisp to a static language like C# is that not everything fits just as fine and you’ll find yourself wondering why the hell code like this returns 10 times 9 instead of 0 to 9. Another thing is that I often find myself remembering small code idioms that just completely goes away when one can build abstractions so easily. The first example is if you want to break out of a double loop. A situation more often that one would think.

I C# one could write a double loop something like this. Notice the introduction of the found variable which is needed to make sure that the loop doesn’t do needless work. Even with an anonymous function it’s quite ugly (and the same is true for a goto solution :)). In lisp it would look something like this (my first common lisp program :-)). The abstraction is in the block concept and in the generalized return construct return-from.

Edit: Can be simplyfied to this:

(let ((l (list (list 1 2 3 4) (list 5 6 7))))
  (loop named outer for i in l do
	(loop for j in i do
	      (when (= j 3)
		(format t "found value, yeah!")
		(return-from outer)))))