Programming Language Comparison

Welcome back ;), long time no see.

Well, what can I say, blogging isn't my strong point, but from time to time something really cool comes up - so here we go.

In my new job I'm getting a little closer to the processor (programming-wise) than I thought, so instead of signing the rest of my days to C I thought I'd have a look around for some alternatives.

C, as we know, is now a bit over 30 years old, there has been some ;) development in language and compiler construction since then - although it seems to be a problem to get that across to the other project members. So how can we compare programming languages? There is performance, sure, never forget that, but that's not all:

What I found was an objective development-speed test. It was set up to convince people that Java doesn't help at all compared to C++ and it was adapted by many other people. The original test is a published (thus: not publicly accessible) paper, but there is a follow-up here. There, it's used as an argument to use Lisp instead of Java (as I said, performance shouldn't be completely off the table...).

What they do have are believable development time studies (done on 12 programmers):
C++: 3 t0 25 hours
Java: 4 to 63 hours
LISP: 2 to 8,5 house
Also, C++ and Java programs are extremely large (around 300 lines).

So, of course, I did the test in C# and ended up with 51 lines after 65 minutes. So that's a pretty good language, I think.

And speaking of good languages: Finally, there is a modern language for low-level development: 'D' (see here). It has almost too many language features, but it's a big improvement for low-level developers since it's almost as fast as C. Development time for the test problem was 75 minutes for 55 lines of D. I think that language I could get to like it.

Tune in for more,

B.

On the (Imagine Cup) road again

This monday - finally - I found the time to check back to thespoke and look at the just opened IC categories Algorithm and IT. Last year I only did Visual Gaming, so this year I wanted to see what else goes on - before turning back to my VG solution and start adapting it to this years SDK.

IT is clearly not my area of choice, never really looked at Win2003 and Active Directory, looks like it's not really part of every day developer life.

Algorithm on the other hand sounded really exciting. The one thing I'm really disappointed about is the fact that the algorithms you need to build for Herbert are extremely specific to Herbert and have nothing to do with the 'real world' of algorithm development. First of all, algorithms in 'h' are judged by code size - seriously, in today's computer world, who cares how big a core algorithm is compared to the massive load of multimedia data? Second, they encourage to send Herbert on very long, detouring (and for the most part indefinite) tours around the map - so even if the program looks really smart, the path Herbert will follow definitely won't.
So after going to the International Olympiade in Informatics in 2001 and 2002 I know there are much better ways of testing people's algorithm skills than to let them send robots through an artificial maze.

So after getting side-tracked by those invitationals a bit I finally returned to my first (and so far only) love in the Imagine Cup, Visual Gaming. The contest itself still runs with the same slow motion as last year (Richard promised a final SDK (for the .Net RTM) on the 1st of December and we are still left with the Beta-2-SDK), but if there is one thing we learned last year it's that complaining about this sort of thing doesn't help. So I won't list all the holes in the SDK and instead say that I started adopting my solution from last year to .Net 2.0 (RTM ;)), and got the path planner up and running with the blood streams. With some new plans to deal with the NanoNeuros when I get home from Dubai it should produce at least the same quality as it did last year. (And then I'll have plenty of time to do all the tweaking that was cut short the deadline last time).

Playing around with Avalon

Just back from my trip to New Zealand I was pleasantly surprised to finally find a CTP of Sparle, the 'Expression Interface Designer' for Avalon (äh, WPF). Get it here.

It's a great tool. Although it's very easy to draw some rectangles and buttons really getting into it would not have been possible without some examples (mainly the tutorial, the flickr browser and Peter Blois' math problems (see here)).

There is one interesting thing I discovered going through Peters code: If you use the MouseMove event, make sure you don't do a computation every time but use a Stopwatch to only do work every 20ms or so. Otherwise Avalon will hammer MouseMove events at you until the framerate completely breaks down. If you're interested, there is a tweaked and sped-up version of the VectorField here.

It is still quite possible to crash Sparkle and I had to disassemble and recompile FlickrFX.dll to add piped downloading to make it fun from Australia, but I can honestly say I love it. Especcially the fact that you can work on the same project with Sparle and VS 2005 in parallel, getting all the design benefits from Sparkle and all the code acrobatics from VS whithout even the hint of a problem is fascinating!

I'm still in the process of getting my feet wet with the whole CLR Object data binding thing, still havent figured out what exactly I have to do to a class so it shows up in Sparkle List of databinding classes...

More to come. B.