A tweet about some C# code rewritten in F# got me interested yesterday. If you know a little F# it’s easy get sucked into thinking that having much fewer lines of code, and less noise generally makes F# code automatically better, cleaner, easier to read than C#. But, of course, that’s only true for people who know enough F# to read it. When I see very smart C# devs unable to decipher what the F# code is doing, that gets me very interested.
The Problem When you want to unit test a method it’s usually pretty simple. Call the method, pass it it’s parameters and assert against it’s return value, or some other property of the object that may have changed. What happens when a method doesn’t return a value, or update some property? What happens when it leads (perhaps after some delay) to an event firing, or a callback getting called? Events firing and callbacks getting called are very similar, but subtly different, so I’ll cover them both.
This week at our FunctionalKats meetup in Dublin, we tackled a simple programming task the Luhn checksum algorithm. The challenge was to try and make the code readable. I rattled off some code that worked, but I wasn’t at all happy with it. It implemented the problem as described. Partitioning the numbers into two groups and dealing with each group in turn. let Luhn s = let double x = x*2 let sumDigits = function | 18 -> 9 | n when n > 9 -> n%9 | n -> n let odds, evens = s |> Seq.
Grap The Code Mastermind, is a code breaking game for two players. A “Code Maker” creates a secret sequence of colour pegs. A “Code Breaker” must break the code by taking guesses and working with the feedback from the Code Maker. Feedback is given using Black and White Pegs. A correct colour in the correct position is acknowledged with a Black Peg A correct colour in the wrong position is acknowledged with a White Peg The position of these pegs is not significant.
Here’s a problem I come across all the time in legacy code and I have been guilty of it myself in the past. This isn’t going to be rocket science, but, apparently, this stuff doesn’t go without saying. Normal caveats about this being a simplified contrived example apply. Take a look at this code static void Main(string[] args) { PrintTradeBalance(); Console.ReadKey(); } Oh! to have code this simple right? It’s pretty clear what it does, it prints a trade balance, whatever that is.
I am growing increasingly frustrated with C#. I think the reason for that may be my exposure to languages like F#. In many ways my feelings for C# are quite similar to feelings I had about VB.Net when I was first exposed to C#. It’s taken me a while to figure out what it is that I find irritating about C# and I think I’m ready to call it. The problem with C# is exactly the same problem I had with VB.
I like Kata’s, I’ve get a lot out of them, but if I’m truly honest, they don’t really address one area of programming where I think I need practice, and that is in working with Legacy Code. In pondering this problem I came to the conclusion that I need a way of doing deliberate practice for legacy code work, and some variation of the Kata idea seems like it might work.
Back in 1995 I sat in a large ballroom to listen to politicians from the North and South of Ireland talk about the peace process, which at that time was far from a sure thing. A story, told by one of the Unionists stuck in my head. He told of how he had been involved in selling a ceasefire to loyalist paramilitaries and one of the questions that he was faced with was.
One session at NDC that really kicked my grasp of functional programming up a few notches was Vagif Abilov’s discussion of Conway’s Game Of Life using F#. I’m not going to rehash the rules of Game Of Life here, if you aren’t familiar with them then read this. Vagif’s source code is on github and his slides are on slideshare. His stuff is well worth a look, but don’t look yet.
Copyright (c) 2018-2024, Devjoy Ltd.
Template by Bootstrapious. Ported to Hugo by DevCows
