It's a terrible critique. It contains way to little substance and too much ad hominem to be taken seriously. How could something like this reach the front page?
I think you need to organize your thoughts before writing an article. The separation of creation from the creator is an interesting topic, but shouldn't be mixed up with a book review in my opinion. I'm also interested what unacceptable behaviour Bob showed, since I only know of his controversial opinions on software engineering.
It depends on what you want to tell. You can discuss how you agree/disagree with someone as polarizing as Uncle Bob in the context of the book, which, if I can go by his previous books, contains a lot of his personality.
Or you write an objective critique of the book. Or maybe something entirely different.
When I read a post entitled "A critique of...", I expect an objective analysis of the information provided by the book, not jabs at the author. I hope this is helpful.
I think this article could have been better organized, but I think it's fine that book reviewers talk about the authors when they think it material either to the content or to the purchase decision.
Here, I think the post makes clear why they talk about the author like this: some will have heard of Bob Martin for his political opinions, and could well wonder whether the book features them along with technical opinions. This would be a legitimate review topic no matter the political views.
Hacker News has a strong "focus on the tech, not the politics" contingent, so I'd think they'd be especially open to a book review that evaluates whether a technical book did what they were asking for.
"I do not hold that my conclusions are absolutely correct in every regard. My goal is to learn from others. So if you can tell me, kindly, and respectfully, where the flaws are in my analysis, I would be grateful." - Robert C. Martin
Every one who is willing to learn and to reflect is a good person - to my mind at least. I would not give up on him so quickly, he is just human after all.
> Write high-level abstractions for everything that is not your core business domain, and don't let secondary component concepts leak into your business domain.
Can you elaborate what you mean by this. What would an example of the bad practice look like verse if it had been done correctly?
If i understand you basically any time a developer uses an orm he would be mixing the DB interactions with business logic but i want to be sure what you mean.
I would not label it bad practice. Honestly, I'm not sure if there is a simple rule to decide what is good or bad. Using an ORM is not necessarily mixing in DB interactions.
Here is an example from the Django documentation [0]:
selected_choice.votes += 1
selected_choice.save()
The offender in my eyes is the save() method call. The first line is business logic, but the second line has nothing to do with business logic. It might be slightly better to hide the database interaction in the object itself, create a special method, and change the two lines into:
selected_choice.increaseVotes(1)
As a counter argument, I dislike code which hides database accesses, because that easily leads to code which does way to many of them and thus is unnecessarily slow.
The second argument should also include correctness: if I increment two variables on that object (e.g. votes and last_vote_time) it needs to be a single atomic operation to not create a hard to debug race condition.
It seems better to explicitly say when to save things rather than hope that every custom method does that and you have a method for every combination of updates.
The Django ORM also has another case to consider: bulk updates, where separating logic from serialization makes a huge performance win easy and safe.
19 comments
[ 3.2 ms ] story [ 42.6 ms ] threadI was really disappointed by his posts in the last year, since he is a very important author and figure in my career.
Therefor I could not let this slide.
The question that still bothers me is: should I read material from people I think are showing unacceptable behavior?
When I read a post entitled "A critique of...", I expect an objective analysis of the information provided by the book, not jabs at the author. I hope this is helpful.
Here, I think the post makes clear why they talk about the author like this: some will have heard of Bob Martin for his political opinions, and could well wonder whether the book features them along with technical opinions. This would be a legitimate review topic no matter the political views.
Hacker News has a strong "focus on the tech, not the politics" contingent, so I'd think they'd be especially open to a book review that evaluates whether a technical book did what they were asking for.
Every one who is willing to learn and to reflect is a good person - to my mind at least. I would not give up on him so quickly, he is just human after all.
This kind of seems really obvious.
If i understand you basically any time a developer uses an orm he would be mixing the DB interactions with business logic but i want to be sure what you mean.
Thanks!
Here is an example from the Django documentation [0]:
The offender in my eyes is the save() method call. The first line is business logic, but the second line has nothing to do with business logic. It might be slightly better to hide the database interaction in the object itself, create a special method, and change the two lines into: As a counter argument, I dislike code which hides database accesses, because that easily leads to code which does way to many of them and thus is unnecessarily slow.[0] https://docs.djangoproject.com/en/2.0/intro/tutorial04/
It seems better to explicitly say when to save things rather than hope that every custom method does that and you have a method for every combination of updates.
The Django ORM also has another case to consider: bulk updates, where separating logic from serialization makes a huge performance win easy and safe.