Scheme

So I read an article on learning to program. It annoyed me. Here's a quote:

"My first class in computer programming was an elective course in BASIC back in sixth grade."

Wait what? A class? Why on earth take a class on programming? Just read a book like a normal child! I did.

"We were asked to [...] master the rules of syntax."
"I never wanted to take another computer course again."

Learning the syntax is kind of necessary to enable actually doing anything with the language. Granted, you don't have to learn it all at once but I doubt the author was really as interested as she tries to let on.

"my junior year in high school [...] We jumped right into the syntax of Pascal"
"Even after two years of studying Pascal, I still can't remember all the rules."

Again, what's with the classes? I learned Pascal on my own. Now I'm not calling the author dense, although I kind of want to. She apparently suffered from having terrible teachers which is not her fault. Try reading a book though!

The author goes on to say, that as a senior she willingly learned Scheme on her own out of interest. Suddenly everything was made clear to her and at long last she understood recursion etc.

In her opinion the differentiating factor was the amazing and awesome language Scheme. The way I see it, learning on her own out of interest, as opposed to rote memorization, finally enabled her to actually learn anything at all.

So now let's recap my own experience:

I learned BASIC and loved how it enabled me to create whatever I wanted. Then I learned Pascal and enjoyed the new found possibilities immensely. I then learned Assembly, again on my own, and it was like being handed a lightsaber.

After that I finally took a class. It was on C++, and since I already had a good base in programming born out of a burning interest, I actually enjoyed that too and learned a lot. Also the teacher was enthusiastic and amusing, so I later took another of his classes, this time on Lisp/Scheme, but I found the language really awkward and pretty much useless.

So which is it? Is Scheme awesome or awkward? Or is the real question whether you're better off learning on your own or at school? Yeah that's rhetorical, I don't really care what you think.

WPF

I'm having a closer look at Windows Presentation Foundation applications today. Below is some of the code automagically generated for you by the IDE. This code is hidden away in the obj directory, presumably because it's part of the build process.

System.Uri resourceLocater;

Ah, and so now we know the real reason this code is hidden. Dudes, if you're going to generate code, learn to spell first please. Go ahead, I dare you to google the word "locater". Allow me to channel Mr. T as I deafeningly shout:

Did you mean: locator, fools?

So why am I nitpicking, you ask? Well, for one thing that's the entire point of this blog, but here's a a few friendly words of advice: Whenever you see a programmer misspelling variables, fear the code. If they can't spell correctly, or even worse, can't be bothered to spell correctly, then what else might they have gotten wrong? My money says a whole lot, most likely.

Also, it doesn't help anything that the properties window of the designer for WPF insists on using ClearType. Antialiasing is all well and fine for smoothing animated jaggies, but blurred fonts cause nothing but headaches. I already turned that bollocks off, so do me a favor and honor my system settings. And why is there a new properties window for WPF anyway? It positively reeks of summer intern.

Renaming is a built in refactoring tool in Visual Studio these days, but oh boy does it ever break stuff when applied in a WPF project. I guess that's what happens when half the "code" is glorified XML. Stop me if I'm wrong, but wasn't XML designed to be easy to traverse programmatically? How hard can it be to cascade the renaming of a variable? Maybe they haven't gotten around to it yet, or maybe developers at MS are perfectly satisfied with the automatic naming of their controls. I don't bother renaming Label1 any more than the next guy, but Window1 isn't exactly the model of readability.

And another thing, what's the point of declaring window properties and such in XML when it AFAICT just gets compiled into the executable anyway? I'd have thought avoiding a recompile was an attractive goal when splitting the code into declarative statements and binaries, but perhaps the main reason for this "paradigm shift" was luring the HTML-ers into application development. Poor souls.

Seems WPF still has some way to go. In summary, it's apparent that what MS has created here is basically a graphic designer's tool, and so I gleefully observe that any proper coder's job is still completely safe from peril. The vector graphics are cool though.

C#

Pascal was the first proper language I learned after BASIC, and my IDE of choice was Turbo Pascal, the creation of Anders Hejlsberg, the same man who has now brought us C#. I still rave nostalgically about the brilliant help system built into TP, but when it comes to C#, I have a slightly different view.

I don't hate C#, but I don't love it either. However, that doesn't mean I have a love-hate relation with the language, those emotions are far too strong. Rather, I consider it to be more of a like-dislike relation. Naturally, I focus on the dislikes. Here's the list:

Everything is classes, just like Java, and just like Java, it annoys me. What's wrong with the odd global helper procedure for those pointless-to-classify tasks? The same basic thing can obviously be accomplished by declaring public statics, but it's that much more bureaucratic framework code, just to please the OO fanatics who blindly believe that all globals are evil. The only thing that kind of design accomplishes is an abundance of classes called Library, Framework or System. Suggesting that I use a singleton instead won't improve my mood, either.

Then there's the mollycoddling. Bounds checking? Garbage collection? No pointers? (That last one is a lie of course, but I'll get into that in a bit.) Apparently it's much too deviously difficult or at least much too time consuming for me, a pitiful dev, but I'm pretty sure I can handle the memory management myself, thanks. In fact, I rather prefer to know what's going on under the hood, if I may.

These days, pointers are one of the devil's temptations. Only the most hardened of veterans may use them, and even then only if they incantate the keyword equivalent of a contamination suit, "unsafe". Much easier for the developer, indeed. But does that mean the language is void of pointers (pun not intended)? Au contraire!

In fact, most variables transcending the complexity of an integer that you might want to declare in C# are pointers, or "reference types", as it were. That is, they are pointers to objects. Have a look at this:

  MyClass c = new MyClass();
  someObject.SomeMethod(c);

That method call looks like it takes pass-by-value parameter to me. It does, in fact. It's a pass-by-value of a pointer to the object c. Of course, that means the object can be altered by the called method:

  void SomeMethod(MyClass x) //pass-by-value?
  {
    x.ChangeObjectsInternalState(); //oops
  }

Can someone explain to me how this is more clear than waving the red flag of pointers in order to signal that what's happening is really a pass-by-reference?

  void SomeMethod(MyClass * x); //unmistakable

Also, boxing doesn't improve on any of this.

Something that really has me gritting my teeth is the lack of support for variable shadowing. Googling the matter has informed me that shadowing "is confusing". Huh? I suppose the concept of polymorphism is also confusing for a beginner, but they didn't take THAT out of C#, now did they? How hard can it be to understand that any given variable exists in a, likewise given, scope? Why not skip templates as well? Oh but wait, C# didn't even implement their templates variety "generics" until version 2.0! What was up with that?

Speaking of stuff that's missing from C#, why won't optional parameters with default values be implemented until version 4.0? What is it they're so busy working on instead? Yeah I know, LINQ. As if anyone enjoys SQL so much that they actually want to be able to use it on arrays and linked lists. Get a grip.

There are other things besides LINQ that I fail to appreciate. WCF, for example. Tell me, why is it that I need another layer on top of Berkeley sockets? Maybe connect() is too difficult a concept to grasp? But then again, I don't really care about WSDL or SOAP or anything remotely connected (pun scornfully intended) to "web services".

In the end, I just prefer executables that don't come with a lot of extra luggage. My PC is perfectly able to run software without an extra layer on top of the already installed extra layer that is Windows. In fact, I'm one of those who longingly recall the days when each piece of software came on its own boot disk/tape/cartridge. Who in their right mind forces their users to download and install a virtual machine just to run their software? Sure, soon .NET will have insinuated its way into every Windows machine out there, but that won't stop me from despising the idea in the first place. Unfortunately, it's painfully obvious that bloat isn't exactly high on MS's priority list of concerns.