NOTE : read the rest of the series, or check out the source code.
I was at Joy of Coding earlier this year and one of the highlight for me was Crista Lopes’ keynote Exercises in Programming Style.
Crista demonstrated how a simple problem of calculating term frequency can be written in a plethora of ways, including:
- using shared mutable state in for loops
- using shared mutable state in procedures
- composing functions
- continuation passing style (CPS)
The point of these exercises is to allow you to see that there are many solutions to the same problem, and that each comes with a set of constraints that needs to be communicated.
I really enjoyed the talk and bought Crista’s book so I can go through all 33 approaches in my own time!
It’s taken me a little while to find the time to do this, but I was finally able to make a start last weekend. Over the next couple of weeks I hope to share with you my ports of Crista’s Python solutions in F# and my takeaways.
If you like what you see then please buy the book and support Crista’s work!
Style 1 – Good Old Times
This style was commonplace in early 50s when hardware limitations had some hard constraints.
- Very small amount of primary memory, typically orders of magnitude smaller than the data that needs to be processed/generated.
- No identifiers – i.e. no variable names or tagged memory addresses. All we have is memory that is addressable with numbers.
Get the source code here.
As you can expect, not being able to use identifiers really stops you in your tracks and made an otherwise simple task so much more complex (also makes you appreciate the work of language and hardware designers that came before us).
The implementation feels deeply unnatural due to the constraints we have imposed on ourselves, and that’s kinda the point of these exercises.
The absence of identifiers for instance, forces us to lump a bunch of global variables into an array that acts as our ‘primary memory’ for the program and forces you to remember which index corresponds to what.
This style is really at odds with how one would code in F# (probably even more so than Python!), as by design F# nudges you towards code in a functional style – using immutable values, recursion, using types to drive your program, etc.