briancarper.net (λ) (Tag: C_sharp)

C# annoyance of the day

Wed, 31 Oct 2007 01:39:25 -0700

Those annoyances just keep coming, right? Consider this Ruby code:

class Parent
  def foo
    puts @var
  end
end

class Child1 < Parent
  def initialize
    @var = 'bar'
  end
end

class Child2 < Parent
  def initialize
    @var = 'baz'
  end
end

Child1.new.foo
Child2.new.foo

This works fine. Note that the Parent class itself doesn't have a @var instance variable. If you tried to instantiate a Parent and call Parent#foo, it would not work properly (unless getting a nil is your idea of proper). Ideally, Parent should be an "abstract" class like C# or Java provide; it's not really a complete class definition, it's more of a framework for children. Though it could be a Module instead of a Class, I made it a Class because I want to compare it to C# which doens't have Modules.

Assuming the programmer knows enough not to try to call Parent#foo, the above works fine in all cases. That's because Ruby has a "What I don't know won't hurt me" philosophy. Parent#foo has no idea whether a @var instance variable exists or not, and it doesn't care. The Parent class could be re-opened later, after all, and a @var added. Or as in this case, a child could make the instance variable. Parent#foo crosses that bridge when it comes to it, and crosses its fingers and hopes there's a @var waiting for it by the time you call Parent#foo.

In C#, I'm pretty sure you can't do the above. In a parent class, if you try to play with an instance variable, that instance variable must exist in the parent class. Even if the parent class is abstract, there must be what amounts to not much more than a placeholder in the parent class for every instance variable that's accessed in a the parent class's methods. Even if you know to be REALLY CAREFUL to make sure all your children define a "var" so that the parent's method always has one to use, and even if you never directly instantiate the parent class (if it's abstract, you can't instantiate it anyways) the compiler isn't going to trust you to do the right thing. If the parent uses a "var', the parent must have a "var" spelled out in the code.

Maybe there's some way to make this work in C#, maybe I don't know enough about the language. But the solutions I found are:

Make a "var" instance variable in the parent class, and initialize it to some garbage value. Then make sure to change that value in the child classes. I hate doing this because the instance variable SHOULD NOT EXIST in the parent class. It should never be used. If I don't create it in my child classes, I don't want my child classes to accidentally use the garbage value of that instance variable in the parent class.
Instead of using instance variables, make an abstract method, e.g. "getVar()", in the parent class, and then in the child classes have that abstract method return a value. This works fine, the abstract method is enough to keep the parent class happy. But this is somewhat obfuscated. And it raises the important question of why I can be allowed to do this kind of thing with method dispatch, but not instance variable lookup? It's an inconsistency in the language.

A language like Java or C# (Java's evil step-brother) is chock-full of arbitrary rules and limitations like this. You have a small (by Ruby or Lisp standards) subset of very rigid constructs available to you, and if those constructs can't fit together the way you want, you certainly can't bend them; instead you build a mess to get yourself as close as you can, and then you have to do backflips to navigate through it. Whereas in Ruby or even moreso in Lisp, you have little bits of things that fit together in extremely arbitrary ways, and you can build really exciting and precise things out of those bits so that the end result does EXACTLY what you want, the way you want.

Is there a way in C# to declare an abstract INSTANCE VARIABLE? "abstract int var;"? I never even thought to try that today. If it does work or if there's something equivalent, I stand corrected. But today I ended up going with the second solution above.

Redemption, sadly.

Mon, 29 Oct 2007 20:48:35 -0700

Today I rammed smack up against a brick wall in my C# endeavors. The problem at hand was something that seems pretty simple: Randomly shuffle an array. Anyone who knows Ruby knows that this is super easy. Here's one way:

arr.sort_by { rand }

How do you do this in C#? Search google for some tips and view the abject horror of a verbose and non-orthogonal weak language. Read if you dare. Find the shuffle routine in this labyrinth of code, and feel the pain. Have some more if you like. ...cringe. Then read this one. And then read on Wikipedia why this last solution is pretty much totally wrong. And why the Ruby one above is very much right.

So a lot of people wrote a lot of C# code, much of it ugly, to solve this problem, so what? You can find bad code in any language. My point is, to borrow a mantra from the world of Lisp, not all programming languages are created equal. Sure, all programming languages are equally powerful in the Turing-complete sense; you could write a Ruby interpreter in C# and solve the above problem that way. But there are things about some languages that make it much more difficult to solve some problems than it would be in other languages. Passing around blocks in Ruby makes it super easy to solve a problem like randomly shuffling an array. In C#, Java, etc. you'd at the very least have to make some kind of object that represents a sorting algorithm, some kind of method that takes and uses such an object, and you'd also have to worry about all the type compatibility between all of the above. Or I could use some kind of delegate method, which is C#'s version of function pointers, from what little I read. Both of those solutions are a lot more code than I really want to write to solve such a simple problem.

In Perl, to do this kind of thing, you'd take the array, map it into a hash of array-element / random-number pairs, sort by the random numbers, and then re-map it into an array. More verbose than Ruby, but better than nothing. C# has Hashtables and ArrayLists, so why not try it the longhand Perl way? That's what I ended up trying in C# at work. At this point, I ran up against all the lovely limitations of statically typed languages. First I made a hash and tried to get a list of its keys and store them in a native array. You can't do that, because Hashtable returns an ICollection object, not a plain old array, and you can't cast one into the other. C# apparently retains some of the ridiculous Array vs. ArrayList, primitive type vs. object type bullcrap that comes from the world of Java. What reason is there to have a subset of things that are completely incompatible with another subset of nearly identical things? What reason is there to have such a thing built into the very foundation of a language? Java has the excuse (maybe) that they started off with a bunch of crap, and had to try to fix their crap without breaking all the code everyone already wrote using the old crap. What's C#'s excuse for copying this horrendously unwieldy mess?

I eventually got everything sorted out, and it didn't take THAT long, but sure it wasn't pretty. And it was silly, unnecessary work. The solution ended up being 20 or so lines of code to do what Ruby does in 13 characters much more elegantly.

Problem number two today came when I tried to printf a string, and strftime a DateTime. Now, there are what seem to be pretty widely accepted standards on how a formt string for how a printf-style function should look. %d, %s, %f, and so on. Similarly lots of languages have a strftime function that uses pretty standard tags to represent month, day, year, hour, minute, second etc. There are some variations between languages, but the general idea is similar enough that you can pick it up very quickly. In many cases you can drop C strings into Perl or Ruby or whatever, and it'll work just the same.

Well, of course, Microsoft craps all over those pseduo-standards. In C# rather than something like "%0.8d", you get something that looks like "{0,8:#}". Same deal for strings to format dates and times; they look nothing like the strftime I'm familiar with.

Why? Why does MS have to do everything differently than everyone else in the world? The choice of format strings is totally arbitrary, so why not use what every freaking other language in the world uses? Is it to keep MS-only programmers mentally tied into MS-only languages so that anything non-MS looks alien to them? Are the MS-style format strings any more powerful than printf-style? Not that I can tell; the C# ones give you special tags for "currency" and to comma-separated numbers, but couldn't they have just added a "%$" and "%," to the MS version of printf or something? Read this trash. I spent way too much time today reading through this small encyclopedia of documentation on MS-style format strings just to re-learn something I already knew very well.

C#... kind of doesn't suck?

Fri, 26 Oct 2007 18:50:05 -0700

At work recently (as in, yesterday) I was faced with the problem of re-writing a scientific app written in the mid-nineties. This thing was a full-screen DOS sort of app and today what with laptops and their widescreen huge-resolution displays, the program wasn't readable for the average human being. All it does is display text in different colors and take keyboard input.

So I got to pick a language to re-write this app from scratch. My first thought process was "Ruby!", but this app is a multi-threaded, GUI app running on Windows laptops that don't have Ruby installed, which is about the worst possible kind of program to try to write in Ruby, aside from maybe device drivers.

So I considered Java. A brief search reveals that even in present-day Java, you still apparently don't have the ability to easily compile Java programs to a native Windows exe. There are some Java compilers but they seem like hacks and many of them are non-free (as in money). Then I remembered that I've never seen an easy-to-use wysiwyg tool for building Java GUI apps. A google search turned up nothing, and the last version of Eclipse I used didn't let me do it either.

So then I decided oh well, I may as well bite the bullet and try C#. I've never used it before. There's a free version of Visual Studio called Visual Studio Express that you can download. (Note: I remember always wanting such a thing about 10 years ago in high school when I was just learning programming for the first time. Maybe if such a thing had been available for free back then, I would have been indoctrinated into the church of Microcrap early on rather than wandering in Linux. Their loss.)

I don't know what's missing in the free version of Visual Studio compared to the thousand dollar shyster version. The free version has a draggety-drop GUI builder, and it has the standard IDE with the auto-completion etc. It's no Vim, but it's better than anything I've ever tried to use to write Java, certainly. It's also better than writing Java in Vim, because writing Java in anything is pure unadulterated pain.

So far as the language itself, C# is noticeably more pleasant to deal with than Java, while at the same time being a blatant ripoff of it in almost every way. But some of the stupid Java annoyances are gone. For example C# doesn't make you catch every single exception that every single bit of code ever throws, which is a blessing. And it doesn't seem to try to force you to keep your files in certain kinds of directory trees. On the other hand, there are of course incredibly stupid limitations to C# for no reason I can tell. e.g. it doesn't support default parameters and doesn't allow constant arrays.

In any case, having never even seen a line of C# as of yesterday, I was able to almost finish my app in about 2 days with relatively little pain. And it's a native Windows app that can easily be deployed. If I ever find myself forced to write a Windows GUI app again (God help me) I'll probably start off with some form of .NET. If good GUI-builder tools or native-exe-producing compilers exist for Java, they need to be better advertised or something.

So given that it's Windows programming, i.e. automatically worse than almost everything else in existence, C# isn't bad, relatively speaking. I'd still rather be writing Ruby.