Big head, long tail

Here’s a graph of the population size of the one hundred largest urban areas in Canada: (Click on the graph for a larger version.) Notice how there is an enormous spiky “head” on this graph: Toronto, Montreal and Vancouver are quite large cities by any measure. Then there is an immediate sharp drop to a…

18

The Purpose, Revealed

Interestingly enough, no one correctly guessed why I needed code in the compiler to transform a method argument list into a form that batched up the side effecting expressions, stuck their values in variables, and then called the method with the side-effect-free variable references. There certainly were some fascinating ideas in the comments though! The…

8

Always write a spec, Part Two

Upon submitting that specification for review, even before seeing my code, Chris found a bug and an omission. The omission is that I neglected to say what happens when the ref variable is an index into a fixed-size array buffer. As it turns out, that case is also rewritten as a pointer dereference by the…

20

Always write a spec, part one

Joel had a great series of articles many years ago about the benefits of writing functional specifications, that is, specifications of how the product looks to its users. I want to talk a bit about technical specifications, that is, a specification of how something actually works behind the scenes. A while back, I described how…

27

Good Names

Imagine a door with an unusual handle. The handle is five feet off the ground and rotates upwards to open the door. The door has no lock. Is this a good door design? Sorry. That’s not an answerable question. The purpose of almost every door is to prevent something from going through it without preventing…

15

Future-Proofing A Design

Last time on FAIC a user asked for guidance on the potential pitfalls of refactoring an automatic property into a regular explicit property. This is just an example of a far more general problem: how can we design programs so that they are easy to get right when things inevitably change in the future? This…

9

The Future of C#, Part Two

Well, I intended to spend the last three weeks blogging about C# design process in anticipation of our announcements at the PDC, and then I got crazy busy at work and never managed to do so! As I’m sure you know by now, we have announced the existence and feature set of that hitherto hypothetical…

32

Arrays considered somewhat harmful

I got a moral question from an author of programming language textbooks the other day requesting my opinions on whether or not beginner programmers should be taught how to use arrays. Rather than actually answer that question, I gave him a long list of my opinions about arrays, how I use arrays, how we expect arrays to be…

63

What To Do When The Source Control Server Is Down

I have not forgotten about my series on method type inference; rather, the contrary. I have been thinking hard about how to change method type inference to be more accurate in a hypothetical world with covariant and contravariant interfaces, and this has led me to dig in even deeper to the method type inference specification and implementation. I’ve…

34

Method Hiding Apologia

Here’s some back-and-forth from an email conversation I had with a user a while back. Why should one avoid method hiding?  If there were no advantages and only disadvantages then we would not have added it to the language in the first place. C# implements hiding because hiding is frequently useful.   I therefore deny the…

25