Jon Skeet asks "Is C# 3 too big to learn from scratch?" I say "Absolutely"

 Jon Skeet wonders:

I’ve been looking at C# 3 in a fair amount of detail recently, and likewise going over the features of C# 2….I feel sorry for someone wanting to learn C# 3 from scratch. It’s becoming quite a big language….It’s often been said in the newsgroups (usually when someone has been moving from another language to C#) that C# itself only takes a few days to learn….I suspect it would be hard to do it any sort of justice in less than about 700 pages, which is a pretty off-putting size (at least for me).

You can’t learn C# in days unless you have a background in either C++ or Java. JavaScript won’t do it, because you have to learn about static typing, value and reference types, different inheritance model, different model for function objects / delegates / events. My book on C# 1.0 was over 900 pages and, although based on about the most successful structure for teaching Java, was inadequate for a true newcomer. That was before generics, which would take many pages to explain to the point of people “knowing” the idioms, much less lambdas and LINQ, which would be at least another 200.

To compile an object-oriented “Hello, World” in C# (1, much less 3) has a huge conceptual load: namespaces, classes, references, the difference between static and instance methods and variables (which, to really understand, requires a digression into the this pointer and v-tables, which opens a can of worms about how the CLR differs from the underlying memory model)…. think about how many concepts you have to understand to understand public static void main(string[] args)

That so many of us learned C# after knowing Java after knowing C++ after knowing C has perpetuated the myth that any of those languages are “learnable in days.” It’s just not so. I used to teach a hugely successful 5-day course on Java which worked great… as long as they weren’t COBOL programmers. I imagine I would face the exact same problems trying to teach newcomers coming from, say, ColdFusion or Flash. Of course some people would “get” it, but I guarantee that those people would be those who had primed themselves on C-derived syntax and object orientation.

Raymond Chen Says Backward Compatibility Does Not Affect Windows Performance

For weeks, I’ve been chewing over this post by Raymond Chen, in which he says:

[T]he real cost of compatibility is not in the hacks. The hacks are small potatoes. Most hacks are just a few lines of code (sometimes as few as zero), so the impact on performance is fairly low.

The idea of a non-backward compatible version of Windows is something that I’ve mused about (as has Alan Zeichick). I’m not going to pick an argument with Chen, of course, but I wonder if he’s not being a little disingenuous. Even a few lines of code in a core routine can have an effect if it affects cache behavior; okay, that’s niggling… But still, to say that a non-compatible version wouldn’t be much faster but to go on to say:

[T]he real cost of compatibility is in the design.

If you’re going to design a feature that enhances the window manager in some way, you have to think about how existing programs are going to react to your feature. These are programs that predate your feature and naturally know nothing about it. Does your feature alter the message order? Does it introduce a new point of re-entrancy? Does it cause a function to begin dispatching messages that previously did not? You may be forced to design your feature differently in order to accommodate these concerns. These issues aren’t things you can “take out”; they are inherently part of the feature design.

Well, yeah. But isn’t that kind of like saying “the real cost of compatibility is not how fast you can type in the code, it’s in the work.”?

Surely (well, not surely, but surely “likely”) a version of Windows where backwards compatibility was negotiable would have more flexibility for the type of redesign / refactoring which Windows will need for the manycore era? If nothing else, surely intuitively one would think that the very concept of the Windows message-loop (much less message ordering) would become highly problematic when trying to figure out how to exploit many cores.

Video game you control with piss (And it’s not "Sink the battleship"?)

The Piss-Screen is a pressure-sensitive inlay for urinals, to play a game with your pee. The game is displayed on a screen above the urinal. Link

The game development industry is the most miserable sector in the software development industry: lower pay, more bozos, worse management. And within that sector, marketing-driven games are the worst sub-sector. I’m trying to imagine the karma that one must accrue in order to program a marketing-driven urine-controlled videogame.