Blog of Anders Rune Jensen » c#

Programming nirvana part 4: the repl

Anders Rune Jensen — Thu, 28 Jan 2010 19:51:33 +0000

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 2: be agile

Anders Rune Jensen — Wed, 13 Jan 2010 21:28:29 +0000

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.

Go

Anders Rune Jensen — Wed, 11 Nov 2009 09:19:34 +0000

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

Python scoping

Anders Rune Jensen — Mon, 09 Nov 2009 10:30:08 +0000

Last friday, Lau discovered an interesting edge case of python. Something that at first appeared to be a bug, but later revealed a deeper truth about the scoping of Python. I guess coming from a C++ background spoils one in some regards. Scoping in C++ is simple and uniform, I have never in many years of programming C++ got bitten by the scope of the language, something that I also can’t say about C#.

The problem boils down to how Python treats local variable and global variables. The following example, stolen and modified from here, shows the edge case in its most simple form:

a, b = (1, 2)

print(a, b)

def test():
    print(a)
    print(b)    # (A)
    #b=1       # (B)

test()

(A) works as long as (B) is commented out. The strange thing is that changing (B) into += produces the same result. Actually it is the case that += a global variable will never work, unless you have declared it in the local scope first. This comes back to the way Python threats variables in the local scope. The following link has more examples to illustrate how scoping works and also how this is different in Python 3k. As explained on Stackoverflow, using the dis functionality sheds some light on strange cases like these. All this said, the scoping has one good thing going for it. The following is quite useful and perfectly legal in Python:

i = 0
def ex1():

   if i < 0:

      b = 10

   else:

      b = 20

   print b
ex1()

Profiling multithreading applications

Anders Rune Jensen — Fri, 25 Sep 2009 12:16:51 +0000

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.

On designing libraries

Anders Rune Jensen — Thu, 14 May 2009 10:01:15 +0000

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.

Scoping rules in c#

Anders Rune Jensen — Fri, 02 Jan 2009 15:32:12 +0000

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.