A modern programming language that makes developers happier.

kotlinlang

About exercise 3.12 (Hard): this problem was a beast. I spent the allotted hour on it then looked at the solutions, all three of them. The first two (not demystified) were inscrutable. The demystified version was a God-send and reveals a mechanism for unraveling inscrutable FP solutions: use meaningful names rather than the terse `z` and `f` .

I am struggling still in trying to "demystify" the implementation of `foldRight()` in terms of `foldLeft()` Can someone suggest a better name for `f` . I think `acc` still works fine for `z`.

Hey <@U7JDATBK5> :wave: Using such short variable names is actually very common, and almost idiomatic in functional programming. The reason we do this is because of the small context that the function holds: these are the only variables in this context, so we don't need lengthy descriptive names. Think of `z` as zero value, `acc` as accumulator and `f` as function. In other places you will see things like `xs`, which represents a linked list. You will see this kind of naming convention again and again in most of the fp books around. Hope that helps a bit!

<@U1EBLL468> Nope. After 54+ years of writing software I now well understand that these conventions do more harm than good and here's why: the original developers are way comfortable with i, t, f, l, b etc. but 1) it turns out these convenient short names can be overloaded real fast (is i index or int?) and more importantly 2) the people likely to be working on this code years after it was first laid down won't have a clue about some decades old convention but they will easily resonate with index, leaf and branch. It's further compounded by the corollary to Moore's law that the number of new programmers doubles every five years. These new programmers don't want to listen to us old farts (I could not wait for the IBMer and other mainframe programmers to exit stage right...) So I learned from Djykstra''s famous "Goto Considered Harmful" paper (goto was as conventional as it got back then), that conventions are not necessarily a good thing and one must question them.  And I do, often getting the same kind of response that Professor Djykstra got (Donald Knuth was a good example of a reputable but wrong critic).

And while I'm ranting, put some damn tests in your books! Why is it that authors of programming books so often treat testing as an afterthought, if at all? (Rhetorical question of course)

And with that let me finish by thanking you for writing this book. It is great! Truly, it is one of the best books on FP that I have read (one of many) and built on a language that after 50+ odd predecessors is now my clear favorite. And please accept my apologies for giving you a hard time. :slightly_smiling_face:

&gt; And while I'm ranting, put some damn tests in your books! Why is it that authors of programming books so often treat testing as an afterthought, if at all? (Rhetorical question of course)
If you knew me, you really wouldn't say that I think tests are an afterthought.

The tests really don't belong in the book, as it would distract from the content, and besides, simply isn't the way Manning do it. Feel free to clone the GitHub repo where all the tests can be found.

As far as the naming convention goes, I'm not going to get involved in lengthy arguments but it really is the convention in FP circles. Cheers.

<@U1EBLL468> Thanks for the tip on the tests. That was very helpful.