One more vote for functional languages

I’ve been doing a lot of work on startup anti-patterns recently so it seems fitting that I look at other things through that lens.

Every few months I fall into the same debugging anti-pattern:

1. I start using a debugger to track down a difficult-to-pin-down issue.
2. I set up a watch expression to look at some complex data structure.
3. The debugger evaluates the watch expression outside its intended scope, which (sometimes) creates a side effect that cannot be observed directly at the time it happens.

one_tricky_problem + one_semi_random_problem == frustration

Yesterday, it happened when I was debugging a VBA script that’s part of my automation of tax preparation. Don’t ask: it seemed like a good idea a long time ago and is probably the main reason I occasionally use my old Windows machine.

The VBA Dictionary class will auto-create elements for any key it doesn’t have a value for. Therefore, a watch expression such as:

myClass.myDictionary(myKey)

can easily create a Nothing value with an Empty  key when myClass is in scope and when myKey is a Variant not in scope.

The previous time I experienced a similar problem was in Ruby when the watch expression had a side-effect on a cache whose logic I was trying to debug.

Eventually, I hope to develop a sixth sense for this debugging anti-pattern. In the meantime, I don’t like my options: (a) not use a debugger or (b) live with paranoia about watch expressions.

Alternatively, I could embrace functional programming languages without side effects. I wonder what their debuggers are like…

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.