Project Euler is a collection of maths-based puzzles which can be solved programmatically, ranging in difficulty from easy to “very”. I’ve been using them to teach myself Haskell.

For example, problem 1 (a very easy problem) involves summing all the multiples of 3 and 5 below 1000:

main = print $ sum $ filter match [1..999]
  where match x = x `mod` 3 == 0
               || x `mod` 5 == 0

All problems have a “one minute rule” – all solutions should be computable using less than one minute of a standard PC’s time. Each solution results in an integer value, which is used to determine whether your solution is correct or not.

Many of the problems seem simple, but turn out to be too large to solve with a “brute-force” approach – a clever algorithm is required – and that “aha” moment when you finally figure it out is very satisfying.

In summary: if you enjoy problem-solving, or want a series of puzzles with which to learn a new language, I thoroughly recommend Project Euler.

Sadly I don’t have backups any newer than May 2010, so a few articles and comments are gone. It’s been a busy year. A new baby doesn’t leave much time for anything, and maintaining a blog that I didn’t think was even worth hacking wasn’t high on my list.

So…. don’t expect any posts for a while. Blogging takes enthusiasm, and I’ve none left.

Note: The code I’ve written here makes no attempt to be fast. In fact, the code I present here is a lot slower than the version I originally wrote, because I’ve decided to go for code simplicity. I’ll note any particularly slow bits of the code as I go along, but please don’t think the lack of performance is due to the language used.

I’m going to present this code backwards – starting from the bottom-most function, and working my way towards main.

The Mandelbrot Set is (in simplified terms) a way of categorizing points in the two-dimensional complex plane: some points are in the set, and some points are not. In the image above, the black pixels are in the Mandelbrot set.

The algorithm I’ve chosen to render the Mandelbrot set is the escape algorithm, which is probabilistic – it determines that points are likely to be in the set (or not), but it cannot say for certain. We must pick a trade-off between performance and accuracy.

import Data.Complex

mandelbrot c
    = iterate 0 0
  where iterate z i
            | i > maxIterations = Nothing
            | magnitude z > 2   = Just (i / maxIterations)
            | otherwise         = iterate (z^2 + c) (i+1)
        maxIterations = 100

Given a point c on the complex plain, we keep iterating until its distance from the origin is greater than two, or until we reach a set limit. If we reach the limit of maxIterations, we mark the point as being in the set, and return Nothing. If we escape, we return Just N, where N is a scaled value indicating the number of iterations required to escape. Strictly speaking, that number N is irrelevant to the set, but it allows us to draw pretty colors around the set. On each iteration, we set z’ to be z² + c.

Performance Note: Taking the magnitude of the current complex value is a very slow way of working out whether we’ve escaped or not – a much better way would be to escape if the absolute value of either the real or imaginary parts of the value exceed two.

Now that we can compute a value for any point on the complex plain, we’ll need to convert it to an RGB value.

import Graphics.UI.WX

toColor Nothing
    = rgb 0 0 0
toColor (Just i)
    = rgb r g b
  where r        = toByte (i * i)
        g        = toByte (i * i)
        b        = toByte (sqrt i)
        toByte d = floor  (d * 255)

Points in the set (Nothing) are colored black, while points not in the set are given a color ranging from white to blue, by squaring or square-rooting the scaled iteration count for each of the red, green, and blue components.

Performance Note: Again, using a square-root function here is very slow. It would be far better to use some form of lookup-table to assign colors.

When I wrote the original version of this program, the output appeared very pixellated. I decided to add 4x anti-aliasing to smooth things out a bit. Essentially, for each point in the image, I pick four sub-pixel points, get the color for each, then average them.

colorMandelbrot aa (x,y)
    = averageColors $ map color aa
  where color (ax,ay) = toColor $ mandelbrot ((x + ax) :+ (y + ay))

averageColors cs
    = rgb (tx colorRed  )
          (tx colorGreen)
          (tx colorBlue )
  where tx f = (sum $ map f cs) `div` length cs

The colorMandelbrot function takes a list of offsets for anti-aliasing, as well as an x-y point in the complex plane. That gets converted to a complex number using the ‘:+‘ constructor.

Picking anti-alias offsets makes use of the scaling function. It picks arbitrary neighbour pixels, and scales them to find the actual distance between them. I’ve hard-coded the zoom and translation parameters here to show the whole set, but you could tweak them to display different parts off the set.

import Control.Applicative

antialias w h
    = (,) <$> [-xo,xo] <*> [-yo,yo]
  where (x0,y0) = scale 0 0 w h
        (x1,y1) = scale 1 1 w h
        xo      = (x1-x0) / 3
        yo      = (y1-y0) / 3

scale x y w h
    = ( dbl (x - w `div` 2) / 100.0 / zoom + offsetX
      , dbl (y - h `div` 2) / 100.0 / zoom + offsetY )
  where dbl v   = fromIntegral v
        zoom    =  1.8
        offsetX = -0.5
        offsetY =  0.0

The operators ‘<$>‘ and ‘<*>‘ are just being used here to produce combinations of coordinates – a list comprehension or ‘do’ block would have worked just as well.

As we move up the code, we move away from the mathematical description of the set, towards the messy realities of actually drawing it in a window. I’m going to render the set as a bitmap, and to create that bitmap, I need to create a stream of color data. I’ll create the color data from a stream of coordinate data.

bitmapOrderCoordinates w h
    = map ( \(y,x) -> scale x y w h) $ (,) <$> [1..h] <*> [1..w]

For a given bitmap width and height, this function gives a list of the actual complex plane coordinates to color. The x and y values might seem like they’re the wrong way around, but that’s necessary to get the data stream order correct.

Finally, I can actually create the bitmap:

createImage sz
    = imageCreateFromPixels sz $ map (colorMandelbrot aa) coords
  where coords = bitmapOrderCoordinates w h
        aa     = antialias w h
        w      = sizeW sz
        h      = sizeH sz

So I now have a bitmap ready to be drawn. For simplicity, I’m just going to draw it to a fixed-size window.

main
    = start mainWindow

mainWindow
    = do f <- frameFixed [text     := "Mandelbrot Set"]
         p <- panel f    [on paint := onPaint]
         set f           [layout   := minsize (sz 600 500)
                                            $ widget p]

onPaint dc rect
    = do img <- createImage $ rectSize rect
         drawImage dc img pointZero []

So there we go. Fancy improving my code? Here’s a few ideas:

• See just how fast you can make this code.
• Allow the user to resize the main window.
• Allow the user to zoom in/out and pan around – possibly add some controls to allow this.
• Fix the application not responding while rendering the set.
• Experiment with variations on the Mandelbrot set – try different powers or variations on the iteration z’ <- z² + c.

At this stage we are able to take a string, tokenize it, and then build a tree representing the expression. We now need to be able to reduce the tree down to a single value (or error).

Expression Reduction

reduce :: (MonadError ExprError m) => ExpressionTree -> m Int

We’re returning an Int, but as before, the context for this return value is an error state.

The reducer is a really simple recursive function. Leaf values in the tree (numbers) are their own value:

reduce (Node (NNumber _ v) _)
    = return v

Operator nodes recursively reduce their left and right child nodes, then apply the operator:

reduce (Node (NOperator p _ op) (lhs:rhs:[]))
    = do x <- reduce lhs
         y <- reduce rhs
         case op x y of
             Right v -> return v
             Left m  -> throwError $ ExprErrorAt m p

At this point we’re “collapsing” the error context. Previously we just defined it as any type that satisfied the ‘MonadError‘ interface. In this function, we force it to be the ‘Either‘ type by expecting the return value to be either ‘Right‘ (success) or ‘Left‘ (failure). Type inference sorts everything out nicely here.

Main Loop

Everything I’ve presented here has been ‘pure’ – free of side effects. That’s all well and good, and it lets us reason about the program, but ultimately we have to deal with the computer and the user, and that’s all about side-effects. The main function is the only bit of impure code in this whole example:

main = interact $ unlines . map (unlines . formatResult) . lines

The period operator is the function composition operator, so we read from right to left.

In other words: convert the input to a list of lines, process each one through ‘formatResult‘ (our function), concatenate our multi-line output, and concatenate again to produce a single string for output. The standard function ‘interact‘ handles all the messy business of reading and writing from the console streams.

Examples

2 + 3 * 4
14

(12+34)*(56+78)
6164

123 / (4 - 4)
** Error in expression:
**   123 / (4 - 4)
**       ^
** Reason: division by zero

123 +
** Error in expression:
**   123 +
**        ^
** Reason: expected a value

I’m going to rush through this section because frankly it’s rather dull, and also because my code seems to be rather stodgy and ugly. Hopefully I’ll get some more comments about how to improve it.

Firstly we need to define various types: for the nodes of the tree, and for various intermediate stages:

data ExpressionNode
    = NNumber Int Int
    | NOperator Int String (Int -> Int -> Either String Int)

type ExpressionTree = Tree ExpressionNode
type ParseResult = (ExpressionTree, [Token])
type NodeResult = (ExpressionNode, [Token])

The top-level parse routine attempts to parse an expression, and complains if there’s anything left over at the end:

parse :: (MonadError ExprError m) => [Token] -> m ExpressionTree
parse ts = do (et, lo) <- parseExpression ts
              case lo of
                  []        -> return et
                  otherwise -> throwExprError lo "unexpected token"

By “expression” I mean a sequence of sums (plus or minus), since they are the lowest precendence:

parseExpression ts = parseSum ts

Next in precedence are products (multiply or divide):

parseSum     ts = parseInfix parseProduct isSumOperator     ts
parseProduct ts = parseInfix parseValue   isProductOperator ts

We can share the code for these since they’re all infix operators:

parseInfix parse pred ts = do (lhs, ts1) <- parse ts
                              parseInfix' lhs ts1 parse pred

parseInfix' lhs ts parse pred
    | pred ts   = do (op, ts1)  <- parseOperator ts
                     (rhs, ts2) <- parse ts1
                     parseInfix' (Node op [lhs, rhs])
                                 ts2 parse pred
    | otherwise = return (lhs, ts)

Values are either a number, or an entire sub-expression in parentheses:

parseValue (TNumber p x : ts) = return (Node (NNumber p x) [], ts)
parseValue (TOpenBracket p : ts)
    = do (exp, ts1) <- parseExpression ts
          case ts1 of
             (TCloseBracket _ : ts2) -> return (exp, ts2)
             otherwise               -> throwExprError ts1 msg
      where msg = "expected a closing bracket"
parseValue ts = throwExprError ts "expected a value"

We need to be able to identify operators. I’ve cheated a little and hard-coded the precedence levels:

parseOperator ts
    = do case ts of
             (TOperator p op : ts1) ->
                 return (NOperator p op (oper op), ts1)
             otherwise              ->
                 throwExprError ts "expected an operator"
      where oper s = snd $ fromJust $ find (\n -> fst n == s) operators

isProductOperator ts = isOperator ts ["*", "/"]
isSumOperator     ts = isOperator ts ["+", "-"]

isOperator (TOperator _ op : ts) ops = op `elem` ops
isOperator _                     _   = False

I also have a utility function to handle errors in the token stream:

throwExprError (t:ts) s
    = throwError $ ExprErrorAt  s (position t)
throwExprError []     s
    = throwError $ ExprErrorEOL s

Lexing

Lexical analysis converts a string into a stream of tokens. We need to define the kinds of tokens that can be present, and their values.

data Token = Tx
           | TOpenBracket  { position :: Int }
           | TCloseBracket { position :: Int }
           | TOperator     { position :: Int, operator :: String }
           | TNumber       { position :: Int, int :: Int }
           deriving (Show)

The first one, Tx, is a special token used to reset the lexer’s state machine when a space is encountered – to enable us to distinguish between “23″ (a single number token) and “2 3″ (two number tokens).

Our expression syntax is so simple we can figure out the token type from a single character:

createToken x p
    | isDigit x    = return $ TNumber       p $ read [x]
    | x == '('     = return $ TOpenBracket  p
    | x == ')'     = return $ TCloseBracket p
    | x `elem` ops = return $ TOperator     p [x]
    | otherwise    = throwError $ ExprErrorAt "unknown token" p
    where ops = concat $ map fst operators

The dollar functions being used are the right-associate operator: return $ TNumber p $ read [x] is equivalent to return (TNumber p ( read [x])). It’s another readability thing.

Note that we’re storing the string position at each stage of tokenization – this is so that we can report errors later on.

Since tokens can span multiple characters, I need to be able to combine them:

combineTokens (TNumber   p x) (TNumber   _ y)
    = [TNumber p (x * 10 + y)]
combineTokens (TOperator p x) (TOperator _ y)
    = [TOperator p (x ++ y)]
combineTokens x               y
    = [x, y]

Only numbers and operators combine in a special way. Everything else (the third line) simply becomes a list of two tokens.

Haskell makes heavy use of pattern matching: you can define a function several times, with each definition matching a different pattern. This avoids provides extremely strong typing, avoids ‘if’ statements, and enhances readability. The underscores in the above function are unused matches – they match anything, and indicate the value matched isn’t used.

Finally, we can put all of this together: lexer’ is a recursive function which handles characters one-by-one, and lexer simply calls that with an appropriate starting state.

lexer :: (MonadError ExprError m) => String -> m [Token]
lexer s = lexer' s 0 Tx []

lexer' []       _ _  ts = return ts
lexer' (' ':xs) p _  ts = lexer' xs (p + 1) Tx ts
lexer' (x:xs)   p Tx ts = do tok <- createToken x p
                             lexer' xs (p + 1) tok (ts ++ [tok])
lexer' (x:xs)   p s  ts = do tok <- createToken x p
                             ctok <- return
                                      $ combineTokens (last ts) tok
                             more <- if null ts
                                       then return [tok]
                                       else return
                                                  (init ts ++ ctok)
                             lexer' xs (p + 1) tok more

That first line (beginning “lexer ::” introduces so many new concepts I don’t know where to start. Let’s give it a bash:

• The double colon introduces a type signature. Until now I’ve been lazy and let the compiler figure out the types of the various functions, but for this one I needed to define it explicitly.
• The single arrows separate arguments and return types – so the C function “int foo( char a, double b)” would have a Haskell equivalent of “foo :: Char -> Double -> Int“.
• Monads… think of them as a context to a computation. I want to return a list of Tokens (i.e. [Token]), but there could be an error along the way, so the context of that return value is in terms of an error state, which I have specified to be of type ExprError. So I define a type variable ‘m‘ (defined before the arrow ‘=>‘), and use it to specify the context for my return value.

Next post: parsing the token stream into an expression tree.

Getting Started

I’ve picked a really simple task – an interactive expression evaluator. I’ll be able to type expressions such as “(1 + 2) * 3″, and expect the answer 9. I’ll also cover error-handling. For this example I’m not going to use any standard Haskell parsing libraries, such as Parsec or Alex/Happy – instead I’m going to hand-code the lot.

If you’d like to give Haskell a whirl, the easiest way is to download the Haskell Platform – it should have everything you need to get started, and is available for Windows, Mac, and Linux.

A note of caution: I’m going to present my code in explanation order, not necessarily the order it’s present in the file. I’m also going to gloss over many Haskell subtleties – I’m presenting this in the style of “lies-to-programmers”.

Top Level

I’m going to write this evaluator “properly”, and hence there will be three phases: lexical analysis, parsing, and reduction.

evaluate s = do tokens <- lexer s
                tree   <- parse tokens
                result <- reduce tree
                return result

Here I’m defining a function, evaluate, which takes one argument, s. It calls functions for each of the three phases, and returns the final result. Note that in Haskell, functions are called without parentheses – so the equivalent to the C-style “f(x, y)” would be “f x y“. Also note that indentation is important – the four statements from “do” onwards belong to the “do” block.

If you’ve never worked with Haskell before, I bet you’re thinking “slow, untyped, scripting language”. Purge your brain of those thoughts – Haskell is compiled to machine code (although it can be interpreted), and is extremely strongly typed – more so than C# or C++. The Haskell compiler uses type inference to work out a function’s type if you don’t supply a type definition.

That result value is going to be a Int, so I need to convert it to a String if I’m going to display it on screen. I also promised error-handling, so we need to cover that, too.

formatResult s = case result of
                     Left e  -> formatError s e
                     Right r -> [ show r ]
                 where result = evaluate s

Left and Right are constructors for Either – an error state is represented by Left, and a normal state by Right. (Incidentally, note that types and constructors begin with an uppercase letter, while everything else begins with a lowercase one).

Arrows going left, arrows going right, equals signs… we need a bit of clarity:

• ‘=‘ defines a function: in the example immediately above, we define two functions: formatResult (which takes one parameter), and result (which takes none – a value if you like).
• ‘->‘ is part of the case statement – it separates the patterns from the case expressions.
• ‘<-‘ is part of the do statement – it binds expressions on the right to values on the left.

‘do‘ blocks are both powerful and difficult to explain – involving the daunting M-word – but for now we’ll just say that they allow sequential operations to be specified, and also support error/exception handling.

Error Handling

OK, enough chat, back to the code. We need to support error states:

data ExprError = ExprErrorAt  { reason :: String, start :: Int }
               | ExprErrorEOL { reason :: String }

instance Error ExprError where
  noMsg    = ExprErrorEOL "unknown error"
  strMsg s = ExprErrorEOL s

formatError s e = map ("** " ++) $
                      [ "Error in expression:"
                      , "  " ++ s
                      , "  " ++ replicate (offset e) ' ' ++ "^"
                      , "Reason: " ++ reason e
                      ]
                   where offset (ExprErrorAt  _ start) = start
                         offset (ExprErrorEOL _)       = length s

I’ve defined a new data constructor, ExprError, which represents an error at a specific character position, or at the end of the expression. I’ve also made it a member of the Error class, so that it works with the ‘do‘ blocks.

Finally, I define formatError, used by formatResult, which prints some error text (prefixed with asterisks), the expression, and a caret at the offending character. Note the use of pattern-matching in the last two lines – they define a function ‘offset‘ which determines the position at which to place the marker. Underscores represent matches that we don’t care about.

As this article is getting a little long, I’ll end with a quick definition of some static data: the operators supported by this evaluator, and their associated operations. These are represented as a list (square brackets) of pairs (round brackets). Note that the operations are complicated a little by the need to support error-handling.

operators = [ ("+", oper (+))
            , ("-", oper (-))
            , ("*", oper (*))
            , ("/", (\ x y -> if y == 0
                              then Left "division by zero"
                              else Right (x `div` y))) ]
            where oper op = (\ x y -> Right (op x y))

Haskell allows any function taking two arguments to be used in infix form by placing it within backticks – hence “x `div` y” is equivalent to “div x y“. It’s just a readability thing.

Next article I’ll move onto lexical analysis – converting a string into a stream of tokens.

Looking through some of the submissions on the site, I was struck by how… well… random most of them are. Without meaning to be rude, they just look like someone went through the list, randomly assigning colors. Many many programmers believe coding and graphic design are polar opposites – that if you’re a coder, you must necessarily suffer from “programmer art”, and hence that it’s pointless to ever try to learn better design skills. I completely disagree with this diagnosis.

I’m going to use only one design rule for this color scheme – consistency: keep similar things similar, and make different things different.

Basics

I’ve already decided to create a “dark” theme, so the background will be black. I also want to highlight important or dangerous elements of the source, and downplay incidental aspects. This idea will modify each of the colors chosen, and help suggest colors where there is no clear choice. Each choice will be reflected as far as is possible across many file types – for example, a C# comment should probably be the same color as an XML one, a JavaScript one, etc.

I’m also going to make use of color shades. I know Visual Studio has to cater for people using low-color displays, remote desktop, and those with reduced vision, but its use of primary colors leaves it looking a little dated. Color shades can be used to bring the look a little more up-to-date, and to group related elements, while still being able to distinguish between them.

Comments – Green

Comments have always been green in Visual Studio, and I’m going to keep them that way – a vibrant green, made bold, to catch the eye. (If comments aren’t important, then why are you writing them?) Comment hyperlinks and the text in #region blocks also match.

Literals – Blue

String literals are red in the standard Visual Studio color scheme, but I wanted to reserve that color for errors and the like. In my mind strings are blue (don’t ask me why) so I’ve chosen a light blue for strings.

With consistency in mind, what else should match this?

• String literals are blue, so why not other literals, such as integers? The common color will highlight “magic values” in code.
• We’ll need to colorize XML and HTML, so we can make attribute values blue too.
• JavaScript and SQL obviously have literals.
• I’ve also chosen to see CSS values as literals – they go blue too. (You could easily argue the toss about that though).

Keywords – Gray

Since the background is black, ‘unadorned’ text will be white – a nice easy choice. How about keywords?

I want to make them a different color – so I can tell when I’ve typed ‘retrun’ for the billionth time – but I don’t consider them to be “core” code. I think of them as scaffolding around my identifiers. (Perhaps I’m a LISPer at heart). I’ve chosen to keep them a neutral color, but a dimmer shade, so they fade out – hence gray.

Types – Yellow/Orange

Colorizing types is handy as it again allows me to see when I’ve mis-typed something. I want them to stand out (so a dim color is out), and I don’t want them confused with anything else – so reds, greens, and blues are gone. Yellows and light oranges seem a good choice – close enough to the normal white text, but sufficiently different to catch the eye. I’ve chosen a light orange for types, and highlighted interface types as yellow. (I figure that looking at how interfaces are defined and used is often a good way to understand the structure of a body of code – hence the slightly more eye-catching color).

(Oddly enough, this doesn’t seem to work for types in C++ – they always seem to come out white. Not sure why.)

Errors, Warnings, and Oddities – Red

This was an easy color to choose – red (for me) means stop and think. There are a few code constructs that I wanted to highlight as either dangerous or needing attention:

• Compiler errors and warnings;
• Preprocessor directives;
• Breakpoints.

Editor Overlays – Purple/Dark Blue

Visual Studio now highlights parts of the source depending on where youyr cursor is – it highlights matching braces, and will also display all usages of the symbol at the caret. These display can change rapidly, so shouldn’t be too distracting. I’ve chosen a dark purple, which is subtly visible, but which blends in with the black background.

We need a related color for the selection too, so I’ve chosen dark blue.

Omissions

There’s still quite a few entries in the colors list I haven’t filled out – the main areas being:

• VB.NET;
• XSLT
• IntelliTrace
• Test Coverage

If you fancy addressing these omissions and sending me back an updated settings file, I’ll be happy to credit you.

Conclusion & Download

So there you go. Obviously color schemes are very personal (and contentious). I think I’ve done a pretty good job; you might well think otherwise. Even if you don’t like this particular scheme, I hope you’ll agree that setting a few design principles in place before assigning colors can help you choose (and use) the colors effectively.

Sadly there’s no way to upload my settings to StudioStyles, and I’m too lazy to re-do all the work by hand. Until they allow that option, I’ll host the settings from here:

Download hackification.vssettings

Save this file somewhere, then use Tools -> Import and Export Settings… to merge them in.

Top 25 Most Dangerous Programming Mistakes

http://www.codinghorror.com/blog/2009/01/top-25-most-dangerous-programming-mistakes.html

Summary article listing the 25 most dangerous (in terms of security impact) programming mistakes. Even if you’re aware of all of these, it’s worth re-familiarizing yourself (and your co-workers) with them.

Microsoft runs fuzzing botnet, finds 1,800 Office bugs

http://www.computerworld.com/s/article/9174539/Microsoft_runs_fuzzing_botnet_finds_1_800_Office_bugs

No, not that sort of botnet. Microsoft are using a distributed computer system to generate random changes to Office files, in an attempt to discover buffer overruns and other vulnerabilities in the file format parser.

Much ado about NULL: An introduction to virtual memory

http://blog.ksplice.com/2010/03/null-pointers-part-i/

Down-to-the-metal article explaining pointers, memory mapping, and virtual memory. Worth reading as it covers the basics that we rarely think about.

Amazing feats of Clang Error Recovery

http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html

Clang is the new up-and-coming C/C++ open-source compiler. If you’ve ever worked with C++, you’ll know how cryptic and downright useless the error messages emitted by most compilers are. Clang is attempting to address that weakness.

Good Math, Bad Pointer Math / C Is Not Assembly

http://james-iry.blogspot.com/2010/04/good-math-bad-pointer-math.html
http://james-iry.blogspot.com/2010/04/c-is-not-assembly.html

A deep-dive into the intricacies of C pointers, and how they relate to the C standard. If you’re interested in writing portable and correct C code, this is worth a read.

Underscore.js

http://documentcloud.github.com/underscore/

Not so much an article as a useful download – Underscore.js (named after the identifier used to access the functions) provides a suite of functional programming constructs for JavaScript.

What’s wrong with extending the DOM

http://perfectionkills.com/whats-wrong-with-extending-the-dom/

JavaScript allows any objects to be extended, either on a per-object or per-type basis. The popular Prototype library used this mechanism – and subsequently found it to be a bad idea. Prototype 2.0 is moving away from  this technique – read this article for a clear explanation why.

The ASP.NET Web Development Horror

http://www.codingthewheel.com/archives/asp-net-web-development-horror

I’ve recently started (belatedly) playing with ASP.NET MVC 2, and it’s a breath of fresh air compared to “classic” ASP.NET. (Presumably “classic” ASP is now “classic classic ASP”). If you’ve not been able to articulate why ASP.NET wasn’t up to scratch, this well-written and funny article will help. How can you not read an article containing the phrase “tricksy little hobbits doing obscene things in the cupboards”?

Use C# dynamic typing to conveniently access internals of an object

http://igoro.com/archive/use-c-dynamic-typing-to-conveniently-access-internals-of-an-object/

I’ve linked to Igor’s blog before – the articles are clear, well-written, and well-laid-out. This article suggests a new use for one of .NET 4.0′s new features, dynamic types.

A Brief, Incomplete, and Mostly Wrong History of Programming Languages

http://www.cvaieee.org/html/humor/programming_history.html

I like to end on a light note, so here’s a couple of funnies. If you’ve ever wondered about this history of various programming languages, this article is completely incorrect.

First among SQLs

http://www.theregister.co.uk/2010/04/20/verity_stob_sql/

If you’re ever bored at work, you can do far worse that read Verity Stob’s collection of articles. They’re tongue-in-cheek, deadpan, and scarily accurate.

Microsoft turns 35: Best, worst and most notable moments

http://www.computerworld.com/s/article/print/9173238/Microsoft_turns_35_Best_worst_and_most_notable_moments

An interesting look back at Microsoft’s history. Love ‘em or hate ‘em, you have to acknowledge the mark they’ve made on the IT industry. You’ll almost certainly know everything in this article, but it’s a nice summary all the same.

Windows Phone 7 Series: the complete guide

http://www.engadget.com/2010/03/18/windows-phone-7-series-the-complete-guide/

The details of Microsoft’s upcoming mobile OS were released recently, and this is a nice summary article. The graphical appearance of the OS looks very fresh and modern – could Microsoft have turned a corner, design-wise?

Building a Windows Phone 7 Twitter Application using Silverlight

http://weblogs.asp.net/scottgu/archive/2010/03/18/building-a-windows-phone-7-twitter-application-using-silverlight.aspx

Given the familiarity of the coding environment for Windows Phone 7, I could be tempted to wish for one, instead of wishing for an iPhone.

Programming Windows Phone 7 Series

http://www.charlespetzold.com/phone/

If like me you like to read an old-fashioned book in the bath instead of reading articles on-line, Charles Petzold is preparing one. Here’s a sneaky preview in PDF format.

New, But Not So Obvious, Features in .NET 4.0

http://galilyou.blogspot.com/2010/03/new-but-not-so-obvious-features-in-net.html

.NET 4 is with us, and there are plenty of new, headline features. Here’s a few that barely get a footnote – but which are interesting nonetheless.

Hello from a libc-free world! (Part 1)

http://blog.ksplice.com/2010/03/libc-free-world/

Why would a single-line program produce a larger-than-expected executable? Where does that excess baggage come from? And if you wanted to ditch the standard core libraries, how would you go about it?

Visualizing Usage of the Firefox Menu Bar

http://blog.mozilla.com/faaborg/2010/03/23/visualizing-usage-of-the-firefox-menu-bar/

Interviews with Average Programmers

http://blogs.citytechinc.com/sanderson/?p=290

I’ve been reading “Coders at Work” recently, a collection of interviews with great programmers. What would an interview with a coder like you or me be like?

5 Stages of Programmer Incompetence

http://coderoom.wordpress.com/2010/03/19/5-stages-of-programmer-incompetence/

Tongue-in-cheek article (mostly) about how we progress in the craft of coding. I can recognise aspects of myself in all of these.