Those who know this technique either discover it themselves, through "reading, learning, doing", or are shown,like this guy was. None of us was born knowing this. Clay has blogged about his experience of discovering this - that in itself is what makes this a great read for me. I wouldn't be surprised if every single tech book author, at some point after their book has been published, has learned something and thought "I wish I knew that when I wrote my book !!" By their very nature books document the authors understanding at a point in time. Would polymorphism have helped Clay's book ? Probably. Does not knowing it ruin the book ? Probably not. If we waited 'til we knew everything before we wrote a book about anything, nothing would ever get written.

Authoring a book and being an expert in the topic of said book is, surprisingly, not always correlated. I don't know this particular person, so don't read that as a comment on this particular author. I have met people whose books I have read, I have seen code written by these same people, I have talked with them about the book topic. My take away is that some people are good at writing books, some people are good at writing code, some, but definitely not all, are good at both.

Writing a book is also a great way to discover new things about your subject.

While true, when I purchase a book I'm trusting that the author is an expert in the topic. Maybe my expectations are too high.

You may never know - if it teaches you some things and makes you more productive, then what of it?

My concern is the inverse of that: recommending something you either don't fully understand or haven't used long enough to speak to either its pros or cons. Being in a book usually is an indicator that something is a best practice or how the way things should be done, ostensibly being put forth by an expert. Perhaps we shouldn't hold such content to such a standard.

I checked out the self-published Object-Oriented Design Anthology that this Clay guy ostensibly wrote judging by the discourse in this thread.

Instead, I found that he wrote from what I can tell the only book that introduces RubyMotion, published by PragProg, and endorsed by other authors.

His blog post shows humility, an ability to praise the work of others, and an effort to add value to the world.

All things that these HN comments distinctly lack and, ultimately, punish.

While I understand the point you're trying to make, OOP is a pervasive concept that should factor into building Ruby and RubyMotion apps. My point is if he opts not to use polymorphism in a RubyMotion app, it's an indication from him as the author of a RubyMotion book that polymorphism should be avoided for whatever reason (maybe the dynamic dispatch is too expensive). My assumption isn't that the author simply doesn't understand OOP, but rather that this was a deliberate decision. But, now a hole in his knowledge becomes best practice for many, because as you pointed out, it's the only book on RubyMotion.

I appreciate the humility. I just wish it manifested in a crawl before you can run mentality. There is actual value in understanding the fundamentals.

When doing rails work, HTML => Haml When doing perl, HTML => HTML::Template

For both CSS => Sass

Crime solved - your laptop was stolen by Deuce Bigalow, male gigolo

Still being rung a couple of times a month. Handing work off to mates. So not too bad.