The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

tempusfugit (144) [Avatar] Offline
#1
7.4.2 Comment (p.19smilie

"When we call the aggregation function with the current part (#1) we use the same name for the value to hold the new state. The new value hides the old one, and in this case that's a useful safety measure: it means we can't accidentally use the old state by mistake after we've computed the new state."

Well, actually whether that is useful is debatable. The code is open to criticism of sacrificing clarity for cleverness because you have to keep slapping your head when reading it to remind yourself that three occurrences of "state" actually mean "f state doc" - a new name like "nextState" doesn't have that problem.

[Clean Code p.25]
"In general programmers are pretty smart people. Smart people sometimes like to show off their smarts by demonstrating their mental juggling abilities. ... One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand."

I understand that the lesson of later bindings hiding previous ones is an important one - I'm just not sure that this is the best opportunity to apply that lesson.

BTW - my comments may sound negative, but they don't mean to be. I'm glad you wrote the book and I think it needed to be written and hopefully it will help lots of readers transition to a more "functional" mindset. Good work!
Tomas Petricek (160) [Avatar] Offline
#2
Re: 7.4.2 Comment (p.198)
Hi,
Yes, I believe clarity of the code is often underestimated in functional programming - hopefully this will change now that it's becoming main-stream. However, I think hiding of values is quite basic feature of functional languages, so I don't think this is the biggest source of "evil", but it definitely needs to be used with care! It can be mis-used to write nasty things smilie.

>> my comments may sound negative, but they don't mean to be. I'm glad you
>> wrote the book and I think it needed to be written and hopefully it will help lots
>> of readers transition to a more "functional" mindset.

Not at all! I'm finding your comments very useful and I believe that the changes I did based on your feedback will make the book better & easier to understand. Thank you very much for your time spent on this forum!

Tomas