If you enjoy reading these exercises then please buy Crista’s book to support her work.
Style 6 – Code Golf
- As few lines of code as possible
Well, cover your eyes folks, this one ain’t pretty…
The lines are so long that you have to click on the image to view it in full just to be able to read the original source code properly…
But, but, but, it does solve the term frequency problem in only 3 lines of code! 3 lines!
3 unbelievably hard to read lines of code
And that’s where this style falls down, the pursuit for brevity often comes at the expense of readability.
It can also be argued that what we have done here is rearranging the steps in fewer lines without necessarily reducing the number of steps. That is, we haven’t reduced the number of things that needs to be kept in our head in order to understand what this piece of code is doing to solve the problem.
On this note, APL’s syntax is often described as unreadable, but I think the problem is not readability but rather familiarity. Its syntax and built-in abstractions are both alien to most developers, and very different to what they’re used to.
When I was learning API, there were a few mental hurdles that I needed to jump through:
- glyph-based function names
- functions have monadic (i.e. prefix) and dyadic (i.e. infix) forms
- everything works on matrices as well as scalars
- precedence always flow from right-to-left, except when braces are used
once I built up some familiarity with the language I actually found APL pretty easy to read.
You can find all the source code for this exercise here.