Jon Skeet: Coding Blog : General

Where do you benefit from dynamic typing?

skeet — Tue, 17 Nov 2009 07:31:48 GMT

Disclaimer: I don't want this to become a flame war in the comments. I'm coming from a position of ignorance, and well aware of it. While I'd like this post to provoke thought, it's not meant to be provocative in the common use of the term.

Chapter 14 of C# in Depth is about dynamic typing in C#. A couple of reviewers have justifiably said that I'm fairly keen on the mantra of "don't use dynamic typing unless you need it" – and that possibly I'm doing dynamic typing a disservice by not pointing out more of its positive aspects. I completely agree, and I'd love to be more positive – but the problem is that I'm not (yet) convinced about why dynamic typing is something I would want to embrace.

Now I want to start off by making something clear: this is meant to be about dynamic typing. Often advocates for dynamically typed languages will mention:

REPL (read-eval-print-loop) abilities which allow for a very fast feedback loop while experimenting
Terseness – the lack of type names everywhere makes code shorter
Code evaluated at execution time (so config files can be scripts etc)

I don't count any of these as benefits of dynamic typing per se. They're benefits which often come alongside dynamic typing, but they're not dependent on dynamic typing. The terseness argument is the one most closely tied to their dynamic nature, but various languages with powerful type inference show that being statically typed doesn't mean having to specify type names everywhere. (C#'s var keyword is a very restricted form of type inference, compared with – say – that of F#.)

What I'm talking about is binding being performed at execution time and only at execution time. That allows for:

Duck typing
Dynamic reaction to previously undeclared messages
Other parts of dynamic typing I'm unaware of (how could there not be any?)

What I'm interested in is how often these are used within real world (rather than demonstration) code. It may well be that I'm suffering from Blub's paradox – that I can't see the valid uses of these features simply because I haven't used them enough. Just to be clear, I'm not saying that I never encounter problems where I would welcome dynamic typing – but I don't run into them every day, whereas I get help from the compiler every day.

Just as an indicator of how set in my statically typed ways I am, at the recent Stack Overflow DevDays event in London, Michael Sparks went through Peter Norvig's spelling corrector. It's a neat piece of code (and yes, I'll finish that port some time) but I kept finding it hard to understand simply because the types weren't spelled out. Terseness can certainly be beneficial, but in this case I would personally have found it simpler if the variable and method types had been explicitly declared.

So, for the dynamic typing fans (and I'm sure several readers will come into that category):

How often do you take advantage of dynamic typing in a way that really wouldn't be feasible (or would be very clunky) in a statically typed language?
Is it usually the same single problem which crops up regularly, or do you find a wide variety of problems benefit from dynamic typing?
When you declare a variable (or first assign a value to a variable, if your language doesn't use explicit declarations) how often do you really either not know its type or want to use some aspect of it which wouldn't typically have been available in a statically typed environment?
What balance do you find in your use of duck typing (the same method/member/message has already been declared on multiple types, but there's no common type or interface) vs truly dynamic reaction based on introspection of the message within code (e.g. building a query based on the name of the method, such as FindBooksByAuthor("Josh Bloch"))?
What aspects of dynamic typing do I appear to be completely unaware of?

Hopefully someone will be able to turn the light bulb on for me, so I can be more genuinely enthusiastic about dynamic typing, and perhaps even diversify from my comfort zone of C#…

Just how spiky is your traffic?

skeet — Mon, 16 Nov 2009 19:48:19 GMT

No, this isn't the post about dynamic languages I promise. That will come soon. This is just a quick interlude. This afternoon, while answering a question on Stack Overflow¹ about the difference between using an array and a Dictionary<string, string> (where each string was actually the string representation of an integer) I posted the usual spiel about preferring readable code to micro-optimisation. The response in a comment - about the performance aspect - was:

Well that's not so easily said for a .com where performance on a site that receives about 1 million hits a month relies on every little ounce of efficiency gains you can give it.

A million hits a month, eh? That sounds quite impressive, until you actually break it down. Let's take a month of 30 days - that has 30 * 24 * 60 * 60 = 2,592,000 seconds². In other words, a million hits a month is less than one hit every two seconds. Not so impressive. At Google we tend to measure traffic in QPS (queries per second, even if they're not really queries - the search terminology becomes pervasive) so this is around 0.39 QPS. Astonished that someone would make such a claim in favour of micro-optimisation at that traffic level, I tweeted about it. Several of the replies were along the lines of "yeah, but traffic's not evenly distributed." That's entirely true. Let's see how high we can make the traffic without going absurd though.

Let's suppose this is a site which is only relevant on weekdays - that cuts us down to 20 days in the month. Now let's suppose it's only relevant for one hour per day - it's something people look at when they get to work, and most of the users are in one time zone. That's a pretty massive way of spiking. We've gone down from 30 full days of traffic to 20 hours - or 20 * 60 * 60 = 72000 seconds, giving 14 QPS. Heck, let's say the peak of the spike is double that - a whopping 28 QPS.

Three points about this:

28 QPS is still not a huge amount of traffic.
If you're really interested in handling peak traffic of ~28 QPS without latency becoming huge, it's worth quoting that figure rather than "a million hits a month" because the latter is somewhat irrelevant, and causes us to make wild (and probably wildly inaccurate) guesses about your load distribution.
If you're going to bring the phrase "a .com" into the picture, attempting to make it sound particularly important, you really shouldn't be thinking about hosting your web site on one server - so the QPS gets diluted again.
Even at 28 QPS, the sort of difference that would be made here is tiny. A quick microbenchmark (with all the associated caveats) showed that on my laptop (hardly a server-class machine) I could build the dictionary and index into it 3 times 2.8 million times in about 5 seconds. If every request needed to do that 100 times, then the cost of doing it 28 requests per second on my laptop would still only be 0.5% of that second - not a really significant benefit, despite the hugely exaggerated estimates of how often we needed to do that.

There are various other ways in which it's not a great piece of code, but the charge against premature optimization still stands. You don't need to get every little ounce of efficiency out of your code. Chances are, if you start guessing at where you can get efficiency, you're going to be wrong. Measure, measure, measure - profile, profile, profile. Once you've done all of that and proved that a change reducing clarity has a significant benefit, go for it - but until then, write the most readable code you can. Likewise work out your performance goals in a meaningful fashion before you worry too much - and hits per months isn't a meaningful figure.

Performance is important - too important to be guessed about instead of measured.

¹ I'm not linking to it because the Streisand effect would render this question more important than it really is. I'm sure you can find it if you really want to, but that's not the point of the post.

² Anyone who wants to nitpick and talk about months which are a bit longer or shorter than that due to daylight saving time changes (despite still being 30 days) can implement that logic for me in Noda Time.

Noda Time gets its own blog

skeet — Fri, 13 Nov 2009 19:54:48 GMT

I've decided it's probably not a good idea to make general Noda Time posts on my personal blog. I'll still post anything that's particularly interesting in a "general coding" kind of way here, even if I discover it in Noda Time, but I thought it would be good for the project to have a blog of its very own, which other team members can post to.

I still have plenty of things I want to blog about here. Next up is likely to be a request for help: I want someone to tell me why I should love the "dynamic" bit of dynamic languages. Stay tuned for more details :)

What's in a name (again)?

skeet — Thu, 05 Nov 2009 20:01:05 GMT

I have possibly foolishly decided to stop resisting the urge to port Joda Time to .NET. For those of you who are unaware, "use Joda Time" is almost always the best answer to any question involving "how do I achieve X with java.util.Date/Calendar?" It's a Java library for handling dates and times, and it rocks. There is a plan to include a somewhat redesigned version in some future edition of Java (JSR-310) but it's uncertain whether this will ever happen.

Now, .NET only gained the ability to work with time zones other than UTC and the local time zone (using only managed code) – it has a bit of catching up to do. It's generally easier to work with the .NET BCL than the Java built-in libraries, but it's still not a brilliant position to be in. I think .NET deserves good date/time support, and as no-one else appears to be porting Joda Time, I'm going to do it. (A few people have already volunteered to help. I don't know how easily we'll be able to divvy up the work, but we'll see. I suspect the core may need to be done first, and then people can jump in to implement different chronologies etc. As a side-effect, I may try to use this project as a sort of case in terms of porting, managing an open source project, and properly implementing a .NET library with useful versioning etc.)

The first two problems, however, are to do with naming. First, the project name. Contenders include:

Joda Time.NET (sounds like it would be an absolutely direct port; while I intend to port all the tricky bits directly, it's going to be an idiomatic port with appropriate .NET bits. It's also a bit of a mouthful.)
Noda Time (as suggested in the comments and in email)
TonyTime (after Tony the Pony)
CoffeeTime
TeaTime
A progression of BreakfastTime, CoffeeTime, LunchTime, TeaTime, DinnerTime and SupperTime for different versions (not a serious contender)
ParsleySageRosemaryAndThyme (not a serious contender)
A few other silly ones too

I suspect I'm going to go for CoffeeTime, but we'll see.

The second problem is going to prove more awkward. I want to mostly copy the names given in Joda Time – aside from anything else, it'll make it familiar to anyone who uses Joda Time in Java (such as me). Now one of the most commonly used classes in Joda is "DateTime". Using that name in my port would be a Bad Idea. Shadowing a name in the System namespace is likely to lead to very disgruntled users who may prove hard to regruntle before they abandon the library.

So what do I do? Go for the subtly different DateAndTime? Tie it to the library with CoffeeDateTime? Change it to Instant? (It'll derive from AbstractInstant anyway – assuming I keep the same hierarchy instead of moving to a composition model and value types.)

Obviously this is a decision which the "team" can make, when we've got one… but it feels like a decision which is lurking round the corner in a hostile way.

What I find interesting is that these are two very different naming problems: one is trying to name something in a relatively arbitrary way – I know I want something reasonably short and memorable for the overall name, but beyond that it doesn't matter too much. The other is trying to nail a very specific name which really has to convey its meaning clearly… but where the obvious name is already taken. Also interestingly, neither is a particularly good example of my most common issue with naming: attempting to come up with a two or three word noun for something that actually needs a whole sentence to describe it adequately.

Oh well – we'll see what happens. In another blog post I'll suggest some of the goals I have in terms of what I'm hoping to learn from the project, and how I'd like it to progress. In other words, expect a work of complete fiction…

If you're interested in helping out with the project, please mail me directly (rather than adding comments here) and as soon as I've set the project up, I'll invite you to the mailing list.

UPDATE: I've already got a few interested names, which is great. Rather than be dictatorial about this, I'll put it to a vote of the people who are willing to help out on it.

MVP Again

skeet — Fri, 30 Oct 2009 21:14:09 GMT

I'm delighted to be able to announce that I'm now an MVP again.

Google has reconsidered the situation and worked out a compromise: I now receive no significant gifts from Microsoft, and I'm not under NDA with them. While that precludes me from a lot of MVP activities, it removes any concerns to do with Google's Code of Conduct. Basically my MVP status is truly just a token of Microsoft's recognition of what I've done in the C# community - and that's fine by me.

When I announced that I'd been advised not to seek renewal, I was amazed at the scale of the reaction in the comments, other blog posts, Twitter and personal email. I was touched by the response of the community. I really love working at Google, and the fact that we could figure out a solution to this situation is definitely one of the things that makes Google such an awesome place to work. Oh, and did I mention that we're hiring? :)

Anyway, the basic message of this post is: thanks to the community for caring, thanks to Google for reconsidering, and thanks to Microsoft for renewing my award. And they all lived happily ever after...

MVP no more

skeet — Thu, 01 Oct 2009 05:21:27 GMT

It's with some sadness that I have to announce that as of the start of October, I'm no longer a Microsoft MVP.

As renewal time came round again, I asked my employer whether it was okay for me to renew, and was advised not to do so. As a result, while I enjoyed being awarded as an MVP, I've asked not to be considered for renewal this year.

This doesn't mean I'm turning my back on that side of software development, of course. I'm still going to be an active member of the C# community. I'm still writing the second edition of C# in Depth. I'm still going to post on Stack Overflow. I'm still going to blog here about whatever interesting and wacky topics crop up.

I just won't be doing so as an MVP.

Thanks to all the friends I've made in the MVP community and Microsoft over the last 6 years, and I wish you all the best.

Keep in touch.

Recent activities

skeet — Thu, 03 Sep 2009 23:08:00 GMT

It's been a little while since I've blogged, and quite a lot has been going on. In fact, there are a few things I'd have blogged about already if it weren't for "things" getting in the way.

Rather than writing a whole series of very short blog posts, I thought I'd wrap them all up here...

C# in Depth: next MEAP drop available soon - Code Contracts

Thanks to everyone who gave feedback on my writing dilemma. For the moment, the plan is to have a whole chapter about Code Contracts, but not include a chapter about Parallel Extensions. My argument for making this decision is that Code Contracts really change the feel of the code, making it almost like a language feature - and its applicability is almost ubiquitous, unlike PFX.

I may write a PFX chapter as a separate download, but I'm sensitive to those who (like me) appreciate slim books. I don't want to "bulk out" the book with extra topics.

The Code Contracts chapter is in the final stages before becoming available to MEAP subscribers. (It's been "nearly ready" for a couple of weeks, but I've been on holiday, amongst other things.) After that, I'm going back to the existing chapters and revising them.

Talking in Dublin - C# 4 and Parallel Extensions

Last week I gave two talks in Dublin at Epicenter. One was on C# 4, and the other on Code Contracts and Parallel Extensions. Both are now available in a slightly odd form on the Talks page of the C# in Depth web site. I no longer write "formal" PowerPoint slides, so the downloads are for simple bullet points of text, along with silly hand-drawn slides. No code yet - I want to tidy it up a bit before including it.

Podcasting with The Connected Show

I recently recorded a podcast episode with The Connected Show. I'm "on" for the second 2/3 of the show - about an hour of me blathering on about the new features of C# 4. If you can understand generic variance just by listening to me talking about it, you're a smart cookie ;)

(Oh, and if you like it, please express your amusement on Digg / DZone / Shout / Kicks.)

Finishing up with Functional Programming for the Real World

Well, this hasn't been taking much of my time recently (I bowed out of all the indexing etc!) but Functional Programming for the Real World is nearly ready to go. Hard copy should be available in the next couple of months... it'll be really nice to see how it fares. Much kudos to Tomas for all his hard work - I've really just been helping out a little.

Starting on Groovy in Action, 2nd edition

No sooner does one book finish than another one starts. The second edition of Groovy in Action is in the works, which should prove interesting. To be honest, I haven't played with Groovy much since the first edition of the book was finished, so it'll be interesting to see what's happened to the language in the meantime. I'll be applying the same sort of spit and polish that I did in the first edition, and asking appropriately ignorant questions of the other authors.

Tech Reviewing C# 4.0 in a Nutshell

I liked C# 3.0 in a Nutshell, and I feel honoured that Joe asked me to be a tech reviewer for the next edition, which promises to be even better. There's not a lot more I can say about it at the moment, other than it'll be out in 2010 - and I still feel that C# in Depth is a good companion book.

MoreLINQ now at 1.0 beta

A while ago I started the MoreLINQ project, and it gained some developers with more time than I've got available :) Basically the idea is to add some more useful LINQ extension methods to LINQ to Object. Thanks to Atif Aziz, the first beta version has been released. This doesn't mean we're "done" though - just that we think we've got something useful. Any suggestions for other operators would be welcome.

Manning Pop Quiz and discounts

While I'm plugging books etc, it's worth mentioning the Manning Pop Quiz - multiple choice questions on a wide variety of topics. Fabulous prizes available, as well as one-day discounts:

Monday, Sept 7th: 50% of all print books (code: pop0907)
Monday, Sept 14: 50% off all ebooks (code: pop0914)
Thursday, Sept 17: $25 for C# in Depth, 2nd Edition MEAP print version (code: pop0917) + C# Pop Quiz question
Monday, Sept 21: 50% off all books (code: pop0921)
Thursday, Sept 24: $12 for C# in Depth, 2nd Edition MEAP ebook (code: pop0924) + another C# Pop Quiz question

Future speaking engagements

On September 16th I'm going to be speaking to Edge UG (formerly Vista Squad) in London about Code Contracts and Parallel Extensions. I'm already very much looking forward to the Stack Overflow DevDays London conference on October 28th, at which I'll be talking about how humanity has screwed up computing.

Future potential blog posts

Some day I may get round to writing about:

Revisiting StaticRandom with ThreadLocal<T>
Volatile doesn't mean what I thought it did

There's a lot more writing than coding in that list... I'd like to spend some more time on MiniBench at some point, but you know what deadlines are like.

Anyway, that's what I've been up to and what I'll be doing for a little while...

Language proliferation

skeet — Tue, 12 May 2009 16:54:47 GMT

I've always been aware that .NET supports multiple languages (obviously) and that Microsoft has been experimenting with this to some extent. It's only recently struck me just to what extent this is the case though.

Here's a list - almost certainly incomplete - of .NET languages from Microsoft alone.

C#
VB (or VB.NET if you wish)
C++/CLI
F#
IronPython
IronRuby
Spec#
M (with Oslo)
Axum
Managed JScript
PowerShell
Cω
J# (not shipping any more, I believe)

Some of these are research languages which are more important for the ideas they've contributed to more mainstream ones at a later date than for anything else – but there's still a lot of effort represented in the list.

In addition, there are third party languages targeting .NET, such as Boo, IronScheme and Scala. (Wikipedia lists loads of them.)

Now, think back to the time before .NET. Was Microsoft actively experimenting with languages back then? Plenty of people were trying things against the JVM, but Sun was pretty much absent from that party. .NET seems to be a "missing ingredient" that has allowed smart folk at Microsoft to let their imaginations loose in ways which they couldn't previously. (Of course, not everyone in the language business at MS started there: Jim Hugunin was hired by Microsoft precisely because of his work on IronPython.)

I wonder how long this will continue.

Tower of Babel, or land of polyglots?

What does this mean for the average developer? Currently, if you're writing a non-web application in .NET, you really only need to know a single language – and any of them will do. (Plus potentially SQL of course…) Compare this with web developers who have to be intimately familiar with HTML, CSS and JavaScript – and the differences between various implementations.

How long will it be before backend developers are expected to know a dynamic language, a static OO language and a functional language? Does the benefit of mixing several languages in a project worth the impedance mismatch and the increased skillset requirements? I'm not going to make any predictions on that front – I can certainly see the benefits of each of these approaches in certain situations. They've been designed to play well together, but there are bound to be limitations and oddities: times when you need to change how you write your F# so that it's easily callable from C#, for example.

Whether or not you learn multiple languages to a professional level is one thing, but becoming familiar with them is a different matter. In the course of co-authoring Functional Programming for the Real World (where "co-author" is a bit of a stretch title - I've played more of an editorial role really, with the added bonus of picking on Tomas whenever I felt he was perhaps a little harsh towards C#) I've learned to appreciate many of F#'s qualities, but I don't really know the language. If someone asked me to write a complete application in it (rather than just a toy experiment) I'd be reaching for books every other minute. I hope I'll learn more over the course of time, but I doubt that I'll ever be sufficiently experienced in it to put it on my CV. The same goes for IronPython, although I'm considerably more likely to need Python at work than I am F#. (Python is one of the three "approved" languages at Google, along with Java and C++.) None of this means that time spent in these languages is wasted: I'll be able to apply a lot of what I've learned about F# to my C# coding, even if it will make me pine for things like pattern matching and asynchronous workflows periodically.

I think it's pretty much a given that these days we all need to bring a wide range of technologies to bear in most jobs. While it used to be just about feasible in the .NET 1.1 days to have a pretty good grasp of all the major aspects (ASP.NET for sites and web services, ADO.NET, WinForms, Windows services, class libraries, interop) it's just impossible these days. We learn something new when we need to - but usually against the background of a familiar language. How well would we cope if we had to learn whole new languages (to the level of being able to use them for production code) as often as we have to learn new libraries?

This worries me a little. I'm pleased to see that C# 4 is a much smaller change than the previous versions were. Admittedly I'd rather have had immutability support than dynamic, but that's just me... and that's the problem, too. While I worry about our ability to actually learn everything that's becoming available, it's all good stuff. Can there be "too much of a good thing"?

What I really don't want to see is developers having to know multiple languages, and everyone knowing them poorly. I'm a big believer in having a thorough understanding of your language, so that even if everything else is new, you can rely on your understanding of that aspect of your code. It would be a shame if the pressure of knowing many languages turned many of us into cargo cult programmers. The utopia would be for us all to turn into language renaissance developers. I suspect the reality will be somewhere between the two.

Still, as long as I get to keep helping authors write about languages I know almost nothing about, I'm sure I'll be happy...

Breaking Liskov

skeet — Mon, 16 Mar 2009 17:48:04 GMT

Very recently, Barbara Liskov won the Turing award, which makes it a highly appropriate time to ponder when it's reasonable to ignore her most famous piece of work, the Liskov Substitution (or Substitutability) Principle. This is not idle speculation: I've had a feature request for MiscUtil. The request makes sense, simplifies the code, and is good all round - but it breaks substitutability and documented APIs.

The substitutability principle is in some ways just common sense. It says (in paraphrase) that if your code works for some base type T, it should be able to work with subtype of T, S. If it doesn't, S is breaking substitutability. This principle is at the heart of inheritance and polymorphism - I should be able to use a Stream without knowing the details of what its underlying storage is, for example.

Liskov's formulation is:

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

So, that's the rule. Sounds like a good idea, right?

Breaking BinaryReader's contract

My case in point is EndianBinaryReader (and EndianBinaryWriter, but the arguments will all be the same - it's better to focus on a single type). This is simply an equivalent to System.IO.BinaryReader, but it lets you specify the endianness to use when converting values.

Currently, EndianBinaryReader is a completely separate class to BinaryReader. They have no inheritance relationship. However, as it happens, BinaryReader isn't sealed, and all of the appropriate methods are virtual. So, can we make EndianBinaryReader derive from BinaryReader and use it as a drop-in replacement? Well... that's where the trouble starts.

There's no difficulty technically in doing it. The implementation is fairly straightforward - indeed, it means we can drop a bunch of methods from EndianBinaryReader and let BinaryReader handle it instead. (This is particularly handy for text, which is fiddly to get right.) I currently have the code in another branch, and it works fine.

And I would have gotten away with it if it weren't for that pesky inheritance...

The problem is whether or not it's the right thing to do. To start with, it breaks Liskov's substitutability principle, if the "property" we consider is "the result of calling ReadInt32 when the next four bytes of the underlying stream are 00, 00, 00, 01" for example. Not having read Liskov's paper for myself (I really should, some time) I'm not sure whether this is the intended kind of use or not. More on that later.

The second problem is that it contradicts the documentation for BinaryReader. For example, the docs for ReadInt32 state: "BinaryReader reads this data type in little-endian format." That's a tricky bit of documentation to understand precisely - it's correct for BinaryReader itself, but does that mean it should be true for all subclasses too?

When I've written in various places about the problems of inheritance, and why if you design a class to be unsealed that means doing more design work, this is the kind of thing I've been talking about. How much detail does it make sense to specify here? How much leeway is there for classes overriding ReadInt32? Could a different implementation read a "compressed" Int32 instead of always reading four bytes, for example? Should the client care, if they make sure they've obtained an appropriate BinaryReader for their data source in the first place? This is basically the same as asking how strictly we should apply Liskov's substitutability principle. If two types are the same in every property, surely we can't distinguish between them at all.

I wonder whether most design questions of inheritance basically boil down to defining which properties should obey Liskov's substitutability principle and which needn't, for the type you're designing. Of course, it's not just black and white - there will always be exceptions and awkward points. Programming is often about nuance, even if we might wish that not to be the case.

Blow it, let's do it anyway...

Coming back to BinaryReader, I think (unless I can be persuaded otherwise) that the benefits from going against the documentation (and strict substitutability) outweigh the downsides. In particular, BinaryReaders don't tend to be passed around in my experience - the code which creates it is usually the code which uses it too, or it's at least closely related. The risk of breaking code by passing it a BinaryReader using an unexpected endianness is therefore quite low, even though it's theoretically possible.

So, am I miles off track? This is for a class library, after all - should I be more punctilious about playing by the rules? Or is pragmatism the more important principle here?

What's in a name?

skeet — Fri, 27 Feb 2009 11:29:00 GMT

T.S. Eliot had the right idea when he wrote "The naming of cats":

The Naming of Cats is a difficult matter,
It isn't just one of your holiday games
...
When you notice a cat in profound meditation,
The reason, I tell you, is always the same:
His mind is engaged in a rapt contemplation
Of the thought, of the thought, of the thought of his name:
His ineffable effable
Effanineffable
Deep and inscrutable singular Name.

Okay, so developers may not contemplate their own names much, but I know I've certainly spent a significant amount of time recently trying to work out the right name for various types and methods. It always feels like it's just out of reach; tauntingly, tantalisingly close.

Recently I've been thinking a bit about what the goals might be in coming up with a good name. In particular, I seem to have been plagued with the naming problem more than usual in the last few weeks.

Operations on immutable types

A while ago I asked a question on Stack Overflow about naming a method which "adds" an item to an immutable collection. Of course, when I say "adds" I mean "returns a new collection whose contents is the old collection and the new item." There's a really wide range of answers (currently 38 of them) which mostly seem to fall into four categories:

Use Add because it's idiomatic for .NET collections. Developers should know that the type is immutable and act accordingly.
Use Cons because that's the term functional programming has used for this exact operation for decades.
Use a new method name (Plus being my favourite at the moment) which will be obvious to non-functional developers, but without being so familiar that it suggests mutability.
Use a constructor taking the old collection and the new item.

Part of the reasoning for Add being okay is that I originally posted the question purely about "an immutable collection" - e.g. a type which would have a name like ImmutableList<T>. I then revealed my true intention (which I should have done from the start) - to use this in MiniBench, where the "collection" would actually be a TestSuite. Everything in MiniBench is immutable (it's partly an exploration in functional programming, as it seems to fit very nicely) but I don't want to have to name every single type as Immutable[Whatever]. There's the argument that a developer should know at least a little bit about any API they're using, and the immutability aspect is one of the first things they should know. However, MiniBench is arguably an extreme case, because it's designed for sharing test code with people who've never seen it before.

I'm pretty sure I'm going to go with Plus in the end:

It's close enough to Add to be familiar
It's different enough to Add to suggest that it's not quite the same thing as adding to a normal collection
It sounds like it returns something - a statement which just calls Plus without using the result sounds like it's wrong (and indeed it would be)
It's meaningful to everyone
I have a precedent in the Joda Time API

Another option is to overload the + operator, but I'm not really sure I'm ready to do that just yet. It would certainly leave brief code, but is that really the most important thing?

Let's look at a situation with some of the same issues...

LINQ operators

Work on MoreLINQ has progressed faster than expected, mostly because the project now has four members, and they've been expending quite a bit of energy on it. (I must do a proper consistency review at some point - in particular it would be nice to have the docs refer to the same concepts in the same way each time. I digress...)

Most of the discussion in the project hasn't been about functionality - it's been about naming. In fact, LINQ is particularly odd in this respect. If I had to guess at how the time has been spent (at least for the operators I've implemented) I'd go for:

15% designing the behaviour
20% writing the tests
10% implementation
5% writing the documentation (just XML docs)
50% figuring out the best name

It really is that brutal - and for a lot of the operators we still haven't got the "right" name yet, in my view. There's generally too much we want to convey in a word or two. As an example, we've got an operator similar to the oft-implemented ForEach one, but which yields the input sequence back out again. Basically it takes an action, and for each element it calls the action and then yields the element. The use case is something like logging. We've gone through several names, such as Pipe, Tee, Via... and just this morning I asked a colleague who suggested Apply, just off the top of his head. It's better than anything we'd previously thought of, but does it convey both the "apply an action" and "still yield the original sequence" aspects?

The old advice of "each method should only do one thing" is all very well, and it clearly helps to make naming simpler, but with situations like this one there are just naturally more concepts which you want to get across in the name.

Let's stay on the LINQ topic, but stray a bit further from the well-trodden path...

The heart of Push LINQ: IDataProducer

I've probably bored most of you with Push LINQ by now, and I'm not actively developing it at the moment, but there's still one aspect which I'm deeply uncomfortable with: the core interface. IDataProducer represents a stream of data which can be observed. Basically clients subscribe to events, and their event handlers will be called when data is "produced" and when the stream ends.

I know IDataProducer is an awful name - but so far I haven't found anything better. IObservable? Ick. Overused and isn't descriptive. IPushEnumerable? Sounds like the client can iterate over the data, which they can't. The actual event names (DataProduced/EndOfData) are okay but there must be something better than IDataProducer. (Various options have been suggested in the past - none of them have been so obviously "right" as to stick in my head...)

This situation is slightly different to the previous ones, however, simply because it's such a pivotal type. You would think that the more important the type, the more important the name would be - but in some ways the reverse is true. You see, Push LINQ isn't a terribly "obvious" framework. I say that without shame - it's great at what it does, but it takes a few mental leaps before you really grok it. You're really going to have to read some documentation or examples before you write your own queries.

Given that constraint, it doesn't matter too much what the interface is called - it's going to be explained to you before you need it. It doesn't need to be discoverable - whereas when you're picking method names to pop up in Intellisense, you really want the developer to be able to guess its purpose even before they hover over it and check the documentation.

I haven't given up on IDataProducer (and I hope to be moving Push LINQ into MoreLINQ, by the way - working out a better name is one of the blockers) but it doesn't feel like quite as much of a problem.

Read-only or not read-only?

This final example came up at work, just yesterday - after I'd started writing this post. I wanted to refactor some code to emphasize which methods only use the read-only side of an interface. This was purely for the sake of readability - I wanted to make it easier to reason about which areas of the code modified an object and which didn't. It's a custom collection - the details don't matter, but for the sake of discussion let's call it House and pretend we're modelling the various things which might be in a house. (This is Java, hence House rather than IHouse.)

I'm explicitly not doing this for safety - I don't mind the fact that the reference could be cast to a mutable interface. The point is just to make it self-documenting that if a method only has a parameter in the non-mutating form, it's not going to change the contents of the house.

So, we have two interfaces, like this:

public interface NameMePlease
{
    Color getDoorColor();
    int getWindowCount();

    // This already returned a read-only collection
    Set<Furniture> getFurniture();
}

public interface House extends NameMePlease
{
    void setDoorColor(Color doorColor);
    void setWindowCount(int windows);
    void addFurniture(Furniture item);
}

Obviously the challenge is to find a name for NameMePlease. One option is to use something like ImmutableHouse or ReadOnlyHouse - but the inheritance hierarchy makes liars of both of those names. How can it be a ReadOnlyHouse if there are methods in an implementation which change it? The interface should say what you can do with the type, rather than specifying what you can't do - unless part of the contract of the interface is that the implementation will genunely prohibit changes.

Thinking of this "positive" aspect led me to ReadableHouse, which is what I've gone with for the moment. It states what you can do with it - read information. Again, this is a concept which Joda Time uses.

Another option is to make it just House, and change the mutable interface to MutableHouse or something similar. In this particular situation the refactoring involved would have been enormous. Simple to automate, but causing a huge check-in for relatively little benefit. Almost all uses are actually mutating ones. The consensus within the Google Java mailing list seems to be that this would have been the preferred option, all things being equal. One interesting data point was that although Joda Time uses ReadableInstant etc, the current proposals for the new date/time API which will be included in Java 7, designed by the author of Joda Time, don't use this convention. Presumably the author found it didn't work quite as well as he'd hoped, although I don't have know of any specific problems.

Conclusion

You'll probably be unsurprised to hear that I don't have a recipe for coming up with good names. However, in thinking about naming I've at least worked out a few points to think about:

Context is important: how discoverable does this need to be? Is accuracy more important than brevity? Do you have any example uses (e.g. through tests) which can help to see whether the code feels right or not?
Think of your audience. How familiar will they be with the rest of the code you're writing? Are they likely to have a background in other areas of computer science where you could steal terminology? Can you make your name consistent with other common frameworks they're likely to use? The reverse is true too: are you reusing a familiar name for a different concept, which could confuse readers?
Work out the information the name is trying to convey. For types, this includes working out how it participates in inheritance. Is it trying to advertise capabilities or restrictions?
Is it possible to make correct code look correct, and buggy code look wrong? This is rarely feasible, but it's one of the main attractions of "Plus" in the benchmark case. (I believe this is one of the main selling points of true Hungarian Notation for variable naming, by the way. I'm not generally a fan, but I like this aspect.)

I may expand this list over time...

I think it's fitting to close with a quote from Phil Karlton:

There are only two hard things in Computer Science: cache invalidation and naming things.

Almost all of us have to handle naming things. Let's hope most of us don't have to mess with cache invalidation as well.

Answering technical questions helpfully

skeet — Tue, 17 Feb 2009 17:50:11 GMT

I'm unsure of whether this should be a blog post or an article, so I'll probably make it both. I've probably written most of it before in Stack Overflow answers, but as I couldn't find anything when I was looking earlier (to answer a question about Stack Overflow answers) I figured it was time to write something in a medium I had more control over.

This is not a guide to getting huge amounts of reputation on Stack Overflow. As it happens, following the guidelines here is likely to result in decent rep, but I'm sure there are various somewhat underhand ways of gaining reputation without actually being helpful. In other words, I'm not going to explain how you might game the system, but just share my views on how to work with the system for the benefit of all involved. A lot of this isn't specific to Stack Overflow, but some of the advice isn't applicable to some forums.

Hypocrisy warning: I'm not going to claim I always follow everything in this list. I try, but that's not the same thing - and quite often time pressures will compromise the quality of an answer. Oh, and don't read anything into the ordering here. It's how it happened to come out, that's all.

Read the question

All too often I've written what I thought was a great answer... only to reread the question and find out that it wasn't going to help the questioner at all.

Now, questions are often written pretty badly, leaving out vital information, being vague about the problem, including lots of irrelevant code but leaving out the crucial bit which probably contains the bug, etc. It's at least worth commenting on the question to ask for more information, but just occasionally you can apply psychic debugging to answer the question anyway. If you do have to make assumptions when writing an answer, state them explicitly. That will not only reduce the possibility of miscommunication, but will also point out the areas which need further clarification.

Code is king

I can't believe I nearly posted this article without mentioning sample code.

Answers with sample code are gold... if the code is appropriate. A few rules of thumb:

Make sure it compiles, assuming it's meant to. This isn't always possible - for example, I often post at work from a machine without .NET on it, or on the train from a laptop without Java. If you can't get a compiler to make sure your code is valid, be extra careful in terms of human inspection.
Snippets are okay, but complete programs rock. If you're not already comfortable with writing short console apps, practise it. Often you can write a complete app in about 15 lines which doesn't just give the solution, but shows it working. Imagine the level of confidence that gives to anyone reading your answer. Get rid of anything you don't need - brevity is really helpful. (In C# for example that usually means getting rid of [STAThread], namespace declarations and unused using directives.)
Take a bit of care over formatting. If possible, try to prevent the code wrapping. That's not always realistically feasible, but it's a nice ideal. Make sure the spacing at least looks okay - you may want to use a 2-space indent if your code involves a lot of nesting.
If you skip best practices, add a comment. For example, you might include // Insert error handling here to indicate that production code really should check the return value etc. This doesn't include omitting the STAThread attribute and working without a namespace - those are just reasonable assumptions and unlikely to be copied wholesale, whereas the main body of the code may well be. If your code leaks resources, someone's production code may do so as well...

Code without an explanation is rarely useful, however. At least provide a sentence or two to explain what's going on.

Answer the question and highlight side-issues

Other developers don't always do things the way we'd like them to. Questions often reflect this, basically asking how to do something which (in our view) shouldn't be attempted in the first place. It may completely infeasible, or it may just be a really bad idea.

Occasionally, the idea is so awful - and possibly harmful to users, especially when it comes to security questions - that the best response is just to explain (carefully and politely) why this is a really bad thing to do. Usually, however, it's better to answer the question and give details of better alternatives at the same time. Personally I prefer to give these alternatives before the answer to the question asked, as I suspect it makes it more likely that the questioner will read the advice and take it on board. Don't forget that the more persuasive you can be, the more likely it is they'll abandon their original plans. In other words, "Don't do this!" isn't nearly as useful as "Don't do this because..."

It's okay to guess, but be honest

This may be controversial. I've certainly been downvoted twice on SO for having the temerity to post an answer without being 100% sure that it's the right one - and (worse?) for admitting as much.

Sometimes there are questions which are slightly outside your own area of expertise, but they feel an awful lot like a situation you've been in before. In this kind of case, you can often write an answer which may well help - and would at least suggest something for the questioner to investigate a a possible answer to their problem. Sometimes you may be way off base, which is why it's worth explaining in your answer that you are applying a bit of educated guesswork. If another answer is posted by an expert in the topic, it may well be worth the questioner trying their solution first... but at least you're providing an alternative if they run out of other possibilities.

Now, somewhat contradictory...

Raise the overall accuracy level

It should go without saying that a correct answer is more helpful than an incorrect one. There are plenty of entirely inaccurate answers on Stack Overflow - and on newsgroups, and basically every online community-based resource I've ever seen. This isn't surprising, but the best ways to counter it are:

Challenge inaccurate information
Provide accurate information yourself

One of the key aspects of this is to provide evidence. If you make an objective statement without any sort of disclaimer about your uncertainty, that should mean you've got good reason to believe you're correct. That doesn't necessarily mean you need to provide evidence, but as soon as there's disagreement, evidence is king. If you want to assert that your code is faster than some other code, write a benchmark (carefully!). If you want to prove that an object can be collected at a certain point in time, write a test to show it. Short but complete programs are great for this, and can stop an argument dead in its tracks.

Another source of evidence is documentation and specifications. Be aware that they're not always accurate, but I generally believe documentation unless I have a specific reason to doubt it.

Provide links to related resources

There have been a few questions on Stack Overflow as to whether it's appropriate to link to other resources on the web. My own opinion is that it's absolutely appropriate and can add a lot of value to an answer. In particular, I like to link to:

MSDN and JavaDoc documentation, or the equivalent for other platforms. With MSDN URLs, if they end in something like http://msdn.microsoft.om/foo(VS80).aspx, take the bit in brackets out of the URL (leaving http://msdn.microsoft.om/foo.aspx in this case). That way the link will always be to the most recent version of the documentation, and it doesn't give WMD as many problems either.
Language specifications, in particular those for C# and Java. I generally link to the Word document for the C# spec, which has the disadvantage that I can't link to a specific section, and it won't just open in the browser. On the other hand, I find it easier to navigate than the MSDN version, and I've seen inaccuracies in MSDN.
My own articles and blog posts (unsurprisingly :)
Wikipedia
Other resources which are unlikely to become unavailable

The point about the resources not becoming unavailable is important - one of the main arguments against linking is that the page might go away in the future. That's not a particularly compelling argument for most reference material IMO, but it is relevant in other cases. Either way, it's worth including some sort of summary of what you're linking to - a link on its own doesn't really invite the reader to follow it, whereas a quick description of what they'll find there provides more incentive.

One quick tip: In Chrome I have an MSDN "search engine" set up and in Firefox a keyword bookmark. In both cases the URL is http://msdn.microsoft.com/en-us/library/%s.aspx - this makes it easier to get to the MSDN page for a particular namespace, type or member. For example, by typing "msdn system.io.fileinfo" I get straight to the FileInfo page. It doesn't work for generics, however. At some point I'd like to make this simpler somehow...

Care about your reader: spelling, grammar and style matter

I'm lucky: I'm a native English speaker, and I have a reasonably good natural command of English. Having said that, I still take a certain amount of care when writing answers: I'll often rewrite a sentence several times until I feel it works. I've noticed that answers with correct spelling and grammar are generally upvoted more than ones with essentially the same content but less careful presentation.

I'm not recommending style over substance; I'm saying that both are important. You could be putting forward the most insightful comment in the world, but if you can't communicate it effectively to your readers, it's not going to help anyone. Having said that...

A time-limited answer may be better than no answer at all

I answer Stack Overflow questions in whatever spare time I have: waiting for a build, on the train, taking a break from editing etc. I frequently see a question which would take a good 15 minutes or more to answer properly - but I only have 30 seconds. If the question already has answers, there's probably no sensible contribution I can make, but if the question is completely unanswered, I sometimes add a very short answer with the most important points I can think of at the time.

Ideally, I'd then go back later and edit the answer to make it more complete - but at least I may have given the questioner something to think about or an option to try. Usually these "quickies" are relatively fruitless, but occasionally I'll come back to find that the answer was accepted: the slight nudge in the answer was all that was required. If I'm feeling diligent at that point I'll still complete the answer, but the point is that a brief answer is usually better than nothing.

Don't be afraid to delete (or edit heavily) useless answers

It's almost inevitable that if you post enough answers, one of them will be less than helpful. It may start off being a good one, but if a later answer includes all the information from your answer and more, or explains it in a better way, it's just clutter.

Likewise if you make a wild stab in the dark about the cause of a problem, and that guess turns out to be wrong, your answer could become actively unhelpful. Usually the community will let you know this in comments or voting, but sometimes you have to recognise it on your own.

Be polite

It's a shame that I have to include this, and it's even more of a shame that I need to take better notice of it myself. However boneheaded a question is, there's no need to be rude. You can express your dismay at a question, and even express dismay at someone failing to read your answer properly, without resorting to inflammatory language. In the end, no-one really wins from a flame war. Remember that there's a real person at the other end of the network connection, and they're probably just as frustrated with you as you are with them. If things are getting out of hand, just write a polite note explaining that you don't think it's productive to discuss the topic any more, and walk away. (This can be surprisingly difficult advice to heed.)

Next time I get too "involved" in a question, could someone please direct me to this point? And don't take "But I'm right, darnit!" as an excuse.

Don't "answer and run"

Sometimes an answer is very, very nearly spot on - but that final 1% is all the difference between the reader understanding fully and having a dangerous misunderstanding of the topic.

Stack Overflow makes it pretty easy to see comments to your answers: monitor this carefully so you can respond and clarify where appropriate. Many web forums have an "email me if this thread is upated" option - again, this is useful. It's really frustrating (as a questioner) to be left hanging with an answer which looks like it might solve a real headache, if only you could just get the ear of the author for a moment.

Having said all of this:

Have fun

In my experience the most useful users are the ones who are obviously passionate about helping others. Don't do it out of some misguided sense of "duty" - no-one's paying you to do this (I assume) and no-one can reasonably complain if you just haven't got the time or energy to answer their question. Save yourself for a time when you can be more enthusiastic and enjoy what you're doing. Go ahead, have a cup of coffee and watch a Youtube video or something instead. You don't have to check whether there are any new questions!

Benchmarking: designing an API with unusual goals

skeet — Mon, 02 Feb 2009 20:10:21 GMT

In a couple of recent posts I've written about a benchmarking framework and the results it produced for using for vs foreach in loops. I'm pleased with what I've done so far, but I don't think I've gone far enough yet. In particular, while it's good at testing multiple algorithms against a single input, it's not good at trying several different inputs to demonstrate the complexity vs input size. I wanted to rethink the design at three levels - what the framework would be capable of, how developers would use it, and then the fine-grained level of what the API would look like in terms of types, methods etc. These may all sound quite similar on the face of it, but this project is somewhat different to a lot of other coding I've done, mostly because I want to lower the barrier to entry as far as humanly possible.

Before any of this is meaningful, however, I really needed an idea of the fundamental goal. Why was I writing yet another benchmarking framework anyway? While I normally cringe at mission statements because they're so badly formulated and used, I figured this time it would be helpful.

Minibench makes it easy for developers to write and share tests to investigate and measure code performance.

The words in bold (or for the semantically inclined, the strong words) are the real meat of it. It's quite scary that even within a single sentence there are seven key points to address. Some are quite simple, others cause grief. Now let's look at each of the areas of design in turn.

Each element of the design should either clearly contribute to the mission statement or help in a non-functional way (e.g. make the project feasible in a reasonable timeframe, avoid legal issues etc). I'm aware that with the length of this post, it sounds like I'm engaging in "big upfront design" but I'd like to think that it's at least informed by my recent attempt, and that the design criteria here are statements of intent rather than implementation commitments. (Aargh, buzzword bingo... please persevere!)

What can it do?

As we've already said, it's got to be able to measure code performance. That's a pretty vague definition, however, so I'm going to restrict it a bit - the design is as much about saying what isn't included as what is.

Each test will take the form of a single piece of code which is executed many times by the framework. It will have an input and an expected output. (Operations with no natural output can return a constant; I'm not going to make any special allowance for them.)
The framework should take the tedium out of testing. In particular I don't want to have to run it several times to get a reasonable number of iterations. I suspect it won't be feasible to get the framework to guess appropriate inputs, but that would be lovely if possible.
Only wall time is measured. There are loads of different metrics which could be applied: CPU execution time, memory usage, IO usage, lock contention - all kinds of things. Wall time (i.e. actual time elapsed, as measured by a clock on the wall) is by far the simplest to understand and capture, and it's the one most frequently cited in newsgroup and forum questions in my experience.
The benchmark is uninstrumented. I'm not going to start rewriting your code dynamically. Frankly this is for reasons of laziness. A really professional benchmarking system might take your IL and wrap it in a timing loop within a single method, somehow enforcing that the result of each iteration is used. I don't believe that's worth my time and energy, as well as quite possibly being beyond my capabilities.
As a result of the previous bullet, the piece of code to be run lots of times needs to be non-trivial. The reality is that it'll end up being called as a delegate. This is pretty quick, but if you're just testing "is adding two doubles faster or slower than adding two floats" then you'll need to put a bit more work in (e.g. having a loop in your own code as well).
As well as the use case of "which of these algorithms performs the best with this input?" I want to support "how does the performance vary as a function of the input?" This should support multiple algorithms at the same time as multiple inputs.
The output should be flexible but easy to describe in code. For single-input tests simple text output is fine (although the exact figures to produce can be interesting); for multiple inputs against multiple tests a graph would often be ideal. If I don't have the energy to write a graphing output I should at least support writing to CSV or TSV so that a spreadsheet or graphing tool can do the heavy lifting.
The output should be useful - it should make it easy to compare the performance of different algorithms and/or inputs. It's clear from the previous post here that just including the scaled score doesn't give an obvious meaning. Some careful wording in the output, as well as labeled columns, may be required. This is emphatically not a dig at anyone confused by the last post - any confusion was my own fault.

Okay, that doesn't sound too unreasonable. The next area is much harder, in my view.

How does a developer use it?

Possibly the most important word in the mission statement is share. The reason I started this project at all is that I was fed up with spending ages writing timing loops for benchmarks which I'd then post on newsgroups or Stack Overflow. That means there are two (overlapping) categories of user:

A developer writing a test. This needs to be easy, but that's an aspect of design that I'm reasonably familiar with. I'm not saying I'm good at it, but at least I have some prior experience.
A developer reading a newsgroup/forum post, and wanting to run the benchark for themselves. This distribution aspect is the hard bit - or at least the bit requiring imagination. I want the barrier to running the code to be really, really low. I suspect that there'll be a "fear of the unknown" to start with which is hard to conquer, but if the framework becomes widely used I want the reader's reaction to be: "Ah, there's a MiniBench for this. I'm confident that I can download and run this code with almost no effort."

This second bullet is the one that my friend Douglas and I have been discussing over the weekend, in some ways playing a game of one-upmanship: "I can think of an idea which is even easier than yours." It's a really fun game to play. Things we've thought about so far:

A web page which lets you upload a full program (without the framework) and spits out a URL which can be posted onto Stack Overflow etc. The user would then choose from the following formats:

Single .cs file containing the whole program - just compile and run. (This would also be shown on the download page.)
Test code only - for those whole already have the framework
Batch file - just run it to extract/build/run the C# code.
NAnt project file containing the C# code embedded in it - just run NAnt
MSBuild project file - ditto but with msbuild.
Zipped project – open the project to load the test in one file and the framework code in other (possibly separate) .cs files
Zipped solution – open to load two projects: the test code in one and the framework in the other

A web page which which lets you upload your results and browse the results of others

Nothing's finalised here, but I like the general idea. I've managed (fairly easily) to write a "self-building" batch file, but I haven't tried with NAnt/MSBuild yet. I can't imagine it's that hard - but then I'm not sure how much value there is either. What I do want to try to aim for is users running the tests properly, first time, without much effort. Again, looking back at the last post, I want to make it obvious to users if they're running under a debugger, which is almost always the wrong thing to be doing. (I'm pretty sure there's an API for this somewhere, and if there's not I'm sure I can work out an evil way of detecting it anyway.)

The main thing is the ease of downloading and running the benchmark. I can't see how it could be much easier than "follow link; choose format and download; run batch file" - unless the link itself was to the batch file, of course. (That would make it harder to use for people who wanted to get the source in a more normal format, of course.)

Going back to the point of view of the developer writing the test, I need to make sure it's easy enough for me to use from home, work and on the train. That may mean a web page where I can just type in code, the input and expected output, and let it fill in the rest of the code for me. It may mean compiling a source file against a library from the command line. It may mean compiling a source file against the source code of the framework from the command line, with the framework code all in one file. It may mean building in Visual Studio. I'd like to make all of these cases as simple as possible - which is likely to make it simple for other developers as well. I'm not planning on optimising the experience when it comes to writing a benchmark on my mobile though - that might be a step too far!

What should the API look like?

When we get down to the nitty-gritty of types and methods, I think what I've got is a good starting point. There are still a few things to think about though:

We nearly have the functionality required for running a suite with different inputs already - the only problem is that we're specifying the input (and expected output) in the constructor rather than as parameters to the RunTests method. I could change that... but then we lose the benefit of type inference when creating the suite. I haven't resolved this to my satisfaction yet :(
The idea of having the suite automatically set up using attributed methods appeals, although we'd still need a Main method to create the suite and format the output. The suite creation can be simplified, but the chances of magically picking the most appropriate output are fairly slim. I suppose it could go for the "scale to best by number of iterations and show all columns" option by default... that still leaves the input and expected output, of course. I'm sure I'll have something like this as an option, but I don't know how far it will go.
The "configuration" side of it is expressed as a couple of constants at the moment. These control the minimum amount of time to run tests for before we believe we'll be able to guess how many iterations we'll need to get close to the target time, and the target time itself. These are currently set at 2 seconds and 30 seconds respectively - but when running tests just to check that you've got the right output format etc, that's far too long. I suspect I should make a test suite have a configuration, and default to those constants but allow them to be specified on the command line as well, or explicitly in code.
Why do we need to set the expected output? In many cases you can be pretty confident that at least one of the test cases will be correct - so it's probably simpler just to run each test once and check that the results are the same for all of them, and take that as the expected output. If you don't have to specify the expected output, it becomes easier to specify a sequence of inputs to test.
Currently BenchmarkResult is nongeneric. This makes things simpler internally - but should a result know the input that it was derived from? Or should the ResultSuite (which is also nongeneric) know the input that has been applied to all its functions? The information will certainly need to be somewhere so that it can be output appropriately in the multiple input case.

My main points of design focus around three areas:

Is it easy to pick up? The more flexible it is, with lots of options, the more daunting it may seem.
Is it flexible enough to be useful in a variety of situations? I don't know what users will want to benchmark - and I don't build the right tool, it will be worthless to them.
Is the resulting test code easy and brief enough to include in a forum post, with a link to the full program? Will readers understand it?

As you can see, these are aimed at three slightly different people: the first time test writer, the veteran test writer, and the first time test reader. Getting the balance between the three is tricky.

What's next?

I haven't started rewriting the framework yet, but will probably do so soon. This time I hope to do it in a rather more test-driven way, although of course the timing-specific elements will be tricky unless I start using a programmatic clock etc. I'd really like comments around this whole process:

Is this worth doing?
Am I asking the right questions?
Are my answers so far headed in the right direction?
What else haven't I thought of?

Programming is hard

skeet — Thu, 29 Jan 2009 20:28:22 GMT

One of the answers to my "controversial opinions" question on Stack Overflow claims that "programming is so easy a five year old can do it."

I'm sure there are some aspects of programming which a five year old can do. Other parts are apparently very hard though. Today I came to the following conclusion:

If your code deals with arbitrary human text, it's probably broken. (Have you taken the Turkey test recently?)
If your code deals with floating point numbers, it's probably broken.
If your code deals with concurrency (whether that means database transactions, threading, whatever), it's probably broken.
If your code deals with dates, times and time zones, it's probably broken. (Time zones in particular are hideous.)
If your code has a user interface with anything other than a fixed size and a fixed set of labels (no i18n), it's probably broken.

You know what I like working with? Integers. They're nice and predictable. Give me integers, and I can pretty much predict how they'll behave. So long as they don't overflow. Of have an architecture-and-processor-dependent size.

Maybe you think I'm too cynical. I think I'm rather bullish, actually. After all, I used the word "probably" on all of those bullet points.

The thing that amazes me is that despite all this hardness, despite us never really achieving perfection, programs seem to work well enough most of the time. It's a bit like a bicycle - it really shouldn't work. I mean, if you'd never seen one working, and someone told you that:

You can't really balance when it's stationary. You have to go at a reasonable speed to stay stable.
Turning is a lot easier if you lean towards the ground.
The bit of the bike which is actually in contact with the ground is always stationary, even when the bike itself is moving.
You stop by squeezing bits of rubber onto the wheels.

Would you not be a touch skeptical? Likewise when I see the complexity of software and our collective failure to cope with it, I'm frankly astonished that I can even write this blog post.

It's been a hard day. I achieved a small victory over one of the bullet points in the first list today. It took hours, and I pity my colleague who's going to code review it (I've made it as clear as I can, but some things are just designed to mess with your head) - but it's done. I feel simultaneously satisfied in a useful day's work, and depressed at the need for it.

RFID: What I really want it for

skeet — Sat, 24 Jan 2009 19:28:40 GMT

This isn't really coding related, but it's technology related at least. There's been a lot of fuss made about how great or awful RFID is and will be in the future, in terms of usefuless and privacy invasion respectively. There's one use which I haven't seen discussed, but which seems pretty obvious to me - but with further enhancements available.

Basically, I want RFID on clothes to tell me useful stuff. Suppose each item of clothing were uniquely tagged, and you had a bunch of scanners in your home linked up to one system which stored metadata about the clothes. Suddenly the following tasks become easier:

Working out which wash cycle to use for a whole washing basket. Can't see the dark sock hidden in the white wash? The RFID scanner could alert you to it. Likewise tumbledrying - no need to check each item separately, just attach the scanner over the tumbledryer door and wait for it to beep as you try to put something in which shouldn't be tumbled.
Separating clothes to put them away after they're clean and dry. Admittedly this is more of a chore for our household than others (with twin boys and an older brother, where some items of clothing could belong to any of them) but it would be really, really useful for us.
Remembering who you've borrowed which clothes from. Kids grow out of clothes very quickly; we have a number of friends who lend us clothes from their children, and likewise we lend plenty of clothes to them and others. You've then got to remember what you borrowed from who, which can become tricky when you've got a loft full of bags of clothing. Wouldn't it be nice to just "label" all the clothes in a bag with the owner's name when you first receive them, and then just pass a scanner near everything quickly later on?

The privacy issues of all of this would have to be worked out carefully (as the simplest solution would allow your movements to be traced just by which clothes you're wearing) but if it does end up being possible, I'll be hugely grateful for this.

(Next up, benchmarking of for vs foreach in various situations. In other words, back to our regular schedule :)

Quick rant: why isn't there an Exception(string, params object[]) constructor?

skeet — Fri, 23 Jan 2009 21:42:52 GMT

This Stack Overflow question has reminded me of something I often wish existed in common exception constructors - an overload taking a format string and values. For instance, it would be really nice to be able to write:

throw new IOException("Expected to read {0} bytes but only {1} were available",
requiredSize, bytesRead);

Of course, with no way of explicitly inheriting constructors (which I almost always want for exceptions, and almost never want for anything else) it would mean yet another overload to copy and paste from another exception, but the times when I've actually written it in my own exceptions it's been hugely handy, particularly for tricky cases where you've got a lot of data to include in the message. (You'd also want an overload taking a nested exception first as well, adding to the baggage...)

Stack Overflow reputation and being a micro-celebrity

skeet — Thu, 15 Jan 2009 22:39:18 GMT

I've considered writing a bit about this before, but not done so for fear of looking like a jerk. I still think I may well end up looking like a jerk, but this is all stuff I'm interested in and I'll enjoy writing about it, so on we go. Much of this is based on experiences at and around Stack Overflow, and it's more likely to be interesting to you if you're a regular there or at least know the basic premises and mechanics. Even then you may well not be particularly interested - as much as anything, this post is to try to get some thoughts out of my system so I can stop thinking about how I would blog about it. If you don't want the introspection, but want to know how to judge my egotism, skipping to the summary is probably a good plan. If you really don't care at all, that's probably a healthy sign. Quit now while you're ahead.

What is a micro-celebrity?

A couple of minutes ago, I thought I might have been original with the term "micro-celebrity" but I'm clearly not. I may well not use the term the same way other people do, however, so here's my rough definition solely for the purposes of this post:

A micro-celebrity is someone who gains a significant level of notoriety within a relatively limited community on the internet, usually with a positive feedback loop.

Yes, it's woolly. Not to worry.

I would consider myself to have been a micro-celebrity in five distinct communities over the course of the last 14 years:

The alt.books.stephen-king newsgroup
The mostly web-based community around Team17's series of "Worms" games (well, the first few, on the PC only)
The comp.lang.java.* newsgroups
The microsoft.public.dotnet.languages.csharp newsgroup
Stack Overflow

The last has been far and away the most blatant case. This is roughly how it goes - or at least how it's gone in each of the above cases:

Spend some time in the community, post quite a lot. Shouting loudly works remarkably well on the internet - if you're among the most prolific writers in a group, you will get noticed. Admittedly it helps to try hard to post well-written and interesting thoughts.
After a while, a few people will refer to you in their other conversations. For instance, if someone in the Java newsgroup was talking about "objects being passed by reference", another poster might say something like "Don't let Jon Skeet hear you talking like that."
Play along with it, just a bit. Don't blow your own trumpet, but equally don't discourage it. A few wry comments to show that you don't mind often go down well.
Sooner or later, you will find yourself not just mentioned in another topic, but being the topic of conversation yourself. At this point, it's no longer an inside joke that just the core members of the group "get" - you're now communal property, and almost any regular will be part of the joke.

One interesting thing you might have noticed about the above is that it doesn't really take very much skill. It takes a fair amount of time, and ideally you should have some reasonable thoughts and the ability to express yourself clearly, but you certainly don't have to be a genius. Good job, really.

How much do you care?

This is obviously very personal, and I'm only speaking for myself (as ever).

It's undeniably an ego boost. Just about every day there's something on Stack Overflow to laugh about in reference to me. How could I not enjoy that? How could it not inflate my sense of self-worth just a little bit? I could dismiss it as being entirely silly and meaningless - which it is, ultimately - but it's still fun and I get a kick out of it. And yes, I'm sorry to say I bore/annoy my colleagues and wife with the latest Stack Overflow news, because I've always been the selfish kind of person who wants to talk about what they're up to instead of asking the other person about their interests. This is an unfortunate trait which has relatively little to do with the micro-celebrity business.

One very good thing for keeping my ego in check is that at Google, I converse with people who are smarter than me every day, whether at coffee, breakfast, lunch or just while coding. There's no sense of anyone trying to make anyone else feel small, but it's pretty obvious that I'm nothing special when it comes to Google. Now, I don't want to put on too much false modesty - I know I have a reasonable amount of experience, and I happen to know two very popular platforms reasonably well (which really helps on Stack Overflow- being the world's greatest guru on MUMPS isn't going to get you much love), and perhaps most importantly I can communicate pretty well. All of these are good things, and I'm proud of my career and particularly C# in Depth...

... but let's get real here. The Jon Skeet Facts page isn't really about me. It's about making geek jokes where the exact subject is largely irrelevant. It could very easily have been about someone else with little change in the humour. Admittedly the funniest answers (to my mind) are the ones which do have some bearing on me (particularly the one about having written a book on C# 5.0 already) - but that doesn't mean there's anything really serious in it. I hope it's pretty obvious to everyone that I'm not a genius programmer. I'd like to think I'm pretty good, but I'm not off-the-charts awesome by any means. (In terms of computer science, I'm nothing special at all and I have a really limited range of languages/paradigms. I'm trying to do something about those, but it's hard when there's always another question to answer.)

It's worth bearing in mind the "micro" part of micro-celebrity. I suspect that if we somehow got all the C# developers in the world together and asked them whether they'd heard of Jon Skeet, fewer than 0.1% would say yes. (That's a complete guess, by the way. I have really no idea. The point is I'm pretty sure it's a small number.) Compared with the sea of developers, the set of Stack Overflow regulars is a very small pond.

What I care far more about than praise and fandom is the idea of actually helping people and making a difference. A couple of days ago I had an email from someone saying that C# in Depth had helped them in an interview: they were able to write more elegant code because now they grok lambda expressions. How cool is that? Yes, I know it's all slightly sickening in a "you do a lot of good work for charity" kind of way - but I suspect it's what drives most Stack Overflow regulars. Which leads me on to reputation...

What does Stack Overflow reputation mean to you?

In virtually every discussion about the Stack Overflow reputation system and its caps, I try to drop in the question of "what's the point of reputation? What does it mean to you?" It's one of those questions which everyone needs to answer for themselves. Jeff Atwood's answer is that reputation is how much the system trusts you. My own answers:

It's a daily goal. Making sure I always get to 200 is a fun little task, and then trying to get accepted answers is a challenge.
It's measurable data, and you can play with graphs and stats. Hey we're geeks - it's fun to play with numbers, however irrelevant they are.
It's an indication of helpfulness to some extent. It plays to my ego in terms of both pride of knowledge and the fulfillment of helping people.
It's useful as an indicator of community trust for the system to use, which is probably more important to Jeff than it is to me.
It's a game. This is the most important aspect. I love games. I'm fiercely competitive, and will always try to work out all the corners of a game's system - things like it being actually somewhat useless getting accepted answers before you've reached the 200 limit. I don't necessarily play to the corners of the game (I would rather post a useful but unpopular answer than a popular but harmful one, for serious questions) but I enjoy working them out. I would be interested to measure my levels of testosterone when typing furiously away at an answer, hoping to craft something useful before anyone else does. I'm never going to be "macho" physically, but I can certainly be an alpha geek. So long as it doesn't go too far, I think it's a positive thing.

I sometimes sense (perhaps inaccurately) that Jeff and Joel are frustrated with people getting too hung up about reputation. It's really unimportant in the grand scheme of things - rep in itself isn't as much of a net contribution to the world's happiness as the way that Stack Overflow connects people with questions to people with relevant answers really, really quickly. But rep is one of the things that makes Stack Overflow so "sticky" as a website. It's not that I wouldn't answer questions if the reputation system went down - after all, I've been answering questions on newsgroups for years, for the other reasons mentioned - but the reputation system certainly helps. Yes, it's probably taking advantage of a competitive streak which is in some ways ugly... but the result is a good one.

One downside of the whole micro-celebrity thing - and in particular of being the top rep earner - is that various suggestions (such as changing the rep limit algorithm and introducing a monthly league) make me look really selfish. It's undeniable that both of the suggestions work in my favour. I happen to believe that both work in the community's favour too, but I can certainly see why people might get the wrong idea about my motivation. I don't remember thinking of any suggestions which would work against my personal interests but in the interests of the community. If I do, I'm pretty sure I'll post them with no hesitation.

Summary

Yes, I like the attention of being a micro-celebrity. It would be ridiculous to deny it, and I don't think it says much more about me than the fact that I'm human.

Yes, I like competing for reputation, even though it's blatantly obvious that the figure doesn't reflect programming prowess. It's part of the fuel for my addiction to Stack Overflow.

With this out of the way, I hope to return to more technical blog posts. If anything interesting comes up in the comments, I'll probably edit this post rather than writing a new one.

How much do you care about blog tags?

skeet — Fri, 07 Nov 2008 17:09:50 GMT

Occasionally I feel that my collection of tags is somewhat lacking. For instance, I've been thinking of adding "language design" and "public speaking" tags - and then going through previous posts and retagging where appropriate.

However, I'd rather not do this if no-one actually uses tags in the first place. I know that I find the tags on Eric Lippert's blog incredibly handy when I'm going back to look for a particular article, but I suspect that's mostly because Eric's blog is so quotable in the first place.

Would it help any of you for me to be more comprehensive and historically accurate with my tags? If so, I'll go ahead... otherwise I'll waste some more time on Stack Overflow :)

Jaffa bugs

skeet — Thu, 06 Nov 2008 17:15:57 GMT

Currently I'm working on a problem found by one of our testers. Unfortunately, it's hard to reproduce. Inspired by the fact that yesterday our micro-kitchen had jaffa cakes in, I propose that if we're going to be frustrated by bugs like this, we might as well at least mock them.

I propose that we call them jaffa bugs, and will work hard to promote this jargon until it takes over the world. Insert evil laugh here.

(Just in case the etymology here isn't clear, see the Wikipedia "Only Fools and Horses" entry.)

DotNetRocks interview

skeet — Tue, 07 Oct 2008 16:33:49 GMT

Last Monday evening I had a chat with the guys from DotNetRocks, and today the show has gone live.

I wouldn't claim to have said anything particularly earth-shattering, and regular readers will probably be familiar with many of the themes anyway, but I thoroughly enjoyed it and hope you will too. Amongst other things, we talked about:

Protocol buffers
Implicit typing and anonymous types
Why it doesn't bother me that Office hasn't been ported to .NET
C# 4
My wishlist for C#
Threading and Parallel Extensions
Working for Google
How to learn LINQ
C# in Depth

Feedback welcome. And yes, I know I sound somewhat like a stereotypical upper-class idiot at times. Unfortunately there's not a lot I can do about that. Only the "idiot" part is accurate :)

New addiction: Stack Overflow

skeet — Sun, 28 Sep 2008 07:23:08 GMT

This may be old news to many readers, but there's a relatively new development Q&A site called Stack Overflow. I'm not generally a fan of web forums as opposed to newsgroups, but Stack Overflow just works. In particular, the post/answer editor is better than anything similar that I've seen. I'll readily admit that the reputation side of things appeals to my ego - which and I suspect it's one of the main reasons it's so popular. Developers tend to be somewhat egotistical :)

One of the aims of the site is to end up as the pseudo-canonical resource for development questions: sort of a development Wikipedia. Only time will tell whether or not that will actually happen. In particular the fact that early answers are more likely to be read (and voted on) than later ones which have perhaps taken a lot of research and cover the topic more thoroughly. It's still in public beta, so there's lots of room for tweaking (and even after launch things could still change, of course).

Just another site to suck up my time...