A twist of lemon

A twist of lemon

Rate This
  • Comments 25

I was browsing the archive of design notes from the early days of the C# language the other day. Apparently whoever was editing the notes back then had a sense of humour. (UPDATE: It was Scott, just as I suspected.) I stumbled across this note from May 1999:


We considered a proposal to rename short, int, and long to short, tall, and grande. More thought on this issue is required; we will revisit this issue on Friday.


And yet the notes for the following Friday say nothing of it. Someone dropped the ball.

It’s not too late. I propose in the same vein that we rename float, double and decimal to singleshot, doubleshot and quadrupleshot. byte can be cappuccino. And of course the BigInteger in the new math library can be half double decaffeinated half-caf with a twist of lemon.

  • So it finally happens that C# comes in different flavors

  • how about:

    Small , big and OMG?

  • Why only address the number types? Let's solve the big problem and make the language skinnable. Now you can have C# look like C, Java, Assembler, or Malbolge. You can have Easter, Halloween, and Christmas skins. You can download the .NET 5.0 skin before the release of .NET 4.0. This would really open the door to a world of unlimited possibilities.

  • How about Hobbit, Orc and Troll?

  • @Daniel

    Common Lisp can only be invented once, unfortunately. You've got to love reader macros...

    As a side note, writing an IDE with code completion for that would sure be fun!

  • I kinda woulda been ok with the exceedingly-boring bool, char, int8, int16, int32, int64, float32, float64. I'm sure types like byte, short, int, long, float, and double make some programmers feel right snuggly and warm as if they were home at last, but the sense of security backfires the first time you try to match native code's LONG against c#'s long in a P/Invoke signature. And trying to explain to a non-C developer what a double is a double of, and what a long is longer than, and what a short is shorter than. Floats and ints are tricky enough already. No need for coffee to add to the confusion.

  • @Doug - Upvote.  I agree int8, int16, etc. would have been better and clearer.  Why over-complicate things with short and long.

  • I think I saw in F# that all data types are going away anyway...

    Maybe step one is change them all to int∞

    And eventually just Object, or was it Variant?

  • > I kinda woulda been ok with the exceedingly-boring bool, char, int8, int16, int32, int64, float32, float64. I'm sure types like byte, short, int, long, float, and double make some programmers feel right snuggly and warm as if they were home at last, but the sense of security backfires the first time you try to match native code's LONG against c#'s long in a P/Invoke signature. And trying to explain to a non-C developer what a double is a double of, and what a long is longer than, and what a short is shorter than. Floats and ints are tricky enough already. No need for coffee to add to the confusion.

    Well, the type names aren't just C by now. It's also C++ and Java at least, and then there are plenty exotic languages using them, such as D.

    Yeah, I always found "float" and especially "double" cheesy terms (why oh why did they kill pre-existing "long float" when writing ANSI standard for C? it made perfect sense...), but by now there's over 30 years of history with those two; and with "short" and "long", over 40 (Algol-68). Trying to find a better replacement is like doing the same for "heap" or "hash". It's just not worth it.

    int32 - given how often it is used, it would be quite a handful to type. I wouldn't mind just int for that (and it matches the usual C++ meaning, too), with int8/16/64 for the rest of them. It's actually how F# does that - you get two shorthands, int=System.Int32, and float=System.Double. And then you have int8/int16/int32/int64, the u-prefixed unsigned varieties, and float32/float64. Makes sense... just not in a curly braces family language.

    All that said... it's not like you can't use System.Int32 and friends directly in C# if you really want clarity. So if you have problems with matching P/Invoke sigs, make it a rule that you only use full integer type names - such as Int32 - in them, and never keywords.

  • How about these renamings:

    float -> not_suitable_for_monetary_arithmetic

    double -> still_not_suitable_for_monetary_arithmetic

Page 2 of 2 (25 items) 12