Categories
c#

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.

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

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.