hp
toc

Decoupled fizzbuzz

2022-08-06, post № 262

programming, #haskell, #vim

Cogniscent of the baggage associated with this timeless kids-game-turned-into-interview-question, sparing its hiring efficacy and undeniable tedium when implemented again and again in yet another C imitation, I believe that the lack of its demise is in parts due to it being just shy of trivial with regards to all three pillars of imperative computing (control flow, i/o and data).
Contrasting a functional pearl — which is a dazzling S-Expression found out there in conceptual cosmos —, I want to describe fizzbuzz as an imperative nut: effortlessly consumable when bought already cracked and put into a bag on a store shelf, yet unexpectedly hard to crack into two clean halves by oneself. I feel its implementation often beckoning me, enticing me with forthcoming elegance, only to turn around and show its ugly face of cumbersomely construed i/o calls and disconcertingly intertwined execution paths.

Following an over-engineered approach in Haskell utilizing overlapping instances to not discriminate against index or periodicity (decoupled-fizzbuzz_overlapping-instances.hs), I chose to try the other extreme of thinking about both streams of different origins and only splicing them appropriately (decoupled-fizzbuzz_decoupled.hs). To further decrease apparent coupling, I finally hid the branching away inside a sort (decoupled-fizzbuzz_decoupled-ifless.hs):

main = mapM_ putStrLn . take 100
    $ zipWith3 (\n s z -> head . reverse . sort $ [show n, s ++ z])
               [1..] (cycle ["","","fizz"]) (cycle ["","","","","buzz"])

Fascinatingly, the often seen approach of leeching periodicity of off the indices’ arithmetic properties has vanished completely to the point of having two mutually oblivious data streams being merged based on their intrinsic willingness to provide non-empty data.

Thus born was the basis for a vim implementation of fizzbuzz. Not a vimscript implementation — which would presumably not bring anything new to the table — but in non-branching, linearily typed vim keystrokes (decoupled-fizzbuzz_decoupled.vim):

i1<Esc> qiyyp<C-A>q98@i
qfkAfizz<Esc>kkq32@f qb4jAbuzz<Esc>jq19@b
:%s/^\d*\ze[fb]<Enter>

It is not yet clear to me how to transform arbitrary branching decisions into decoupled blind text manipulation tasks, where every branch has somehow become an effect of a textual arbiter introduced for a niche action. However, I currently entertain hopes of coaxing vim-y edits into a scripting language more attuned to editing tasks and with less translational friction than traditional tools including regexp+ and fully-fledged Turing complete programs can offer. The Kolmogorov problem of fizzbuzz is in my view a convincing demonstration of the presence of untapped potential in this domain.

Jonathan Frech's blog; built 2024/04/13 20:55:09 CEST