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
profiling

Profiling multithreading applications

I’ve written about profiling before in the general case. But when it comes to multithreading, there are a few more factors to consider such as lock contention and cache invalidation that affect performance. And this is where mutrace (mutex profiler) comes into the picture. The profiler has a very low overhead compared (no perceived delay for me) to other solutions and gives quite nice results. I tested it on My Media System (C++) and Nemo (C#) and got interesting results for both. I knew more or less what the results for mms would be, but the results for Nemo was a bit suprising. The lock contention was significantly higher than for mms, even though I didn’t really use a multithreaded design for Nemo. So I guess it comes from the mono platform itself. Sadly it seems that mono programs aren’t compiled with -rdynamic, so the results that one gets are quite hard to decipher.

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
Blog

Scoping rules in c#

What a dull subject. Exactly so because it’s supposed to be a done deal, I don’t hear many people arguing about scope rules anymore. That is why I was so suprised when the compiler complained about some perfectly valid code I had written.  At first I thought it was only a peculiarity of the way closures are implemented in c#, but as I dug deeper, the scoping rules of c# seems to be… well just annoyingly stupid. Lets start with a simple case:

OleDbCommand command = SQLServer.CreateCommand();

if (true)

{

OleDbCommand command = SQLServer.CreateCommand();

}

I don’t think many people would argue that is just bad programming practice, but look what happens if we just change it a little:

if (true)

{

OleDbCommand command = SQLServer.CreateCommand();

}

OleDbCommand command = SQLServer.CreateCommand();

This fails with the exact same error. Apparently the command of the if statement prevents the other command from being declared, but since you can use command anymore this is just plainly wrong.  Furthermore closures behave the same way:

VoidFunction t = delegate

{

OleDbCommand command = SQLServer.CreateCommand();

}

OleDbCommand command = SQLServer.CreateCommand();

Please note that the closure has just been declared. For more discussion of the examples see this thread on stackoverflow.  I followed up with a question of why the language guys at microsoft would have made such a bonehead mistake and there wasn’t any good reason in my mind.  I’m still puzzled why the compiler wouldn’t just issue a warning, but maybe warnings is one of those things they hated about C++ and decided it was just easier to swing the big No-hammer and be done with it.