There are a few different libraries that provide test assertions for F#. I went through a couple today and tried a trivial example in each.
Every so often I want to quickly sketch out what should be a simple diagram. Irrespective of what drawing program I use, I always seem to take much more time than I intend for a result that does not even remotely resemble what I want.
So I decided to give up and find a way to use hand-drawn sketches instead. Here’s the method I ended up with, based almost entirely on Marc Liberatore’s "Whiteboard Diagrams as PDFs" post and the wonderful ImageMagick and Potrace utilities.
My drawings still look fairly terrible, but at least they convey what I want them to and are quick to produce! :)
Apparently it can be a bit tricky to get some Haskell libraries working on Windows, in which case the Haskell Platform is a great way to get going with Haskell. For Mac and Linux the platform works too, but we can also just grab the latest GHC and Cabal (ooh, shiny!) and go from there.
tl;dr: Make invalid regular expression strings and attempts to access non-existent capture groups a compile-time error, thanks to the Regex type provider.
Either type, also called
Choice in F# parlance, is a way of representing a value that can be either one of two types. This can be extremely useful. For example, retrieving a date of birth from a textbox could be expressed as
Either<ParseException, DateTime>. In other words, the result is a value that is either a valid
DateTime, or is a
Being a hasty introduction this post is not going to do justice to how useful this type is, but hopefully some of its goodness will shine through despite my rambling prose. :)
Most of the time .NET GC just works. Occasionally when dealing with things like interop with unmanaged code, things go wrong. Things I learned today from this aforementioned going wrong include:
- Variable scope can be greater than the lifetime of the object it points to
- Mark-and-sweep GC marks objects for survival, not for collection
GC.KeepAlive(object)is a no-op
- Finalisers from collected objects can break active objects
- Use a release configuration build for reproducing GC issues, running without the debugger attached
- Non-deterministic finalisation makes me confused
One thing I’ve battled with in my OO, TDD adventures is useless abstractions. I find it very easy to churn out class like the
PaddedSingleWidgetList described below in an attempt to follow the Single Responsibility Principle and write testable code, but in doing so I end up with lots of classes that don’t really make much sense in isolation, and that are not inherently reusable. (Just me?)
Instead of my usual approach of splitting a problem in terms of somewhat arbitrarily chosen responsibilities, what if we divided it into the parts that need knowledge of specific types, and the parts that can have the specific types abstracted away?