One of the Worst Bits of Programming Advice I ever Got | Hacker News Reader

One of the Worst Bits of Programming Advice I ever Got

ashfurrow.com

13 pointsAshFurrow13 comments

Open articleView on HN

The argument seems to be:

1. I was told not to do X.

2. I did X and I like it.

Therefore:

3. “Learn from your own experiences and beware of anyone espousing the virtues of the One True Way.”

This is motherhood and Apple pie. It sounds like wisdom, but it doesn’t follow logically from his example even if you agree with his feelings about his code.

By way of a counter-example, We could pick millions of lines of terrible PHP and Javascript. These were all written by people who learned from their own experiences and didn’t follow any dogmatic rules or guidelines.

Why is it that sometimes breaking the “rules” is a good idea but sometimes it isn’t? For a blog post to be useful, it should propose some sort of repeatable criteria for when to defy thirty years of experience/folklore with OOP and when to respect it.

Again, I am deliberately avoiding agreeing or disagreeing with his example, just pointing out that the conclusion as stated isn't really useful.

There seems to be a pressure for coders to blog. Writing well (and creating useful posts) requires the same attention to craft that coding does.

Thoughtfulness is a rare quality in both code and blog posts - I savor it when I find it. We probably need fewer coding frameworks and more mental frameworks that encourage thoughtfulness in coding and writing.

But I do think there is room in the blog world for writing as journaling. Maybe the usefulness of a blog post is limited to the author, but there may be some value for us as readers in simply seeing another's thought process at work rather than requiring the post to meet some metric of useful.

>>> Writing well (and creating useful posts) requires the same attention to craft that coding does.

Yeah, for sure. And rushing through writing a quick response when I should be heading out the door for work was probably a bad idea. Next time I'll sit on it until I'm through my first cup of coffee.

Maybe, but then again, maybe not. A blog is not a hardbound book with gilt corners. You can read the responses, revise it, perhaps learn from the feedback. I certainly do, and in that respect my own writing resembles my code: Writing is rewriting.

Therefore, I’d rather see you write and be thoughtful about the responses you receive than hold back until you have researched every idea thoroughly in an attempt to avoid criticism.

That is my personal view, I am not sure I can provide any evidence that it is a good idea.

I think the biggest problem I made with this particular post was conflating it with a code sample.

Few people who probably argue that OOP is the only way to code. But when faced with an example of another way, people are focusing on that specific example as a way that "I don't understand OOP." I'm finding more and more that what I don't include in my writing makes a strong piece.

So to answer his own question, yes he's doing OOP the wrong way. The advice he's given is actually really good if you want to learn how to think with objects, any "actionable" name like Helper or Fetcher implies that there's a behavior mismatch somewhere and you should refactor so that you're back to Objects doing their thing.

For the sake of the blog post, he should have refactored APIHelper to be something like ExternalApi, where it and it alone knows about how to fetch and how it's implemented. Then it's super simple to refactor ExternalApi's internals to be async instead of sync, but now he's got another object strictly dependent on the internal workings of another object, and will have trouble in the future.

The fact that he instead built an async wrapper around a sync call shows that he doesn't understand OOP and is himself stuck in procedural land with objects.

This article should be titled "How I threw away some of the best OOP advice I've ever been given".

I think this is an instance of one of the hard problems in computer science: naming things.

When thinking about "-er" names to avoid, think about "Executor" and its ilk. Contrast that with this example and I see "APIHelper" and "ModelFetcher" that should probably just be called "MyBackgroundThread" or some such with methods for fetching models and making synchronous HTTP requests.

In other words, I think avoiding "-er" is a specialization of http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom....

I read that too, with a grain of salt and subsequently did a 'find . -name "*er.java"' just to see. 23 out 148 matched in one of my projects. Cursorily, half of them are nouns and the other half are a combination of Loader, Manager and Handler. :)

I think its more a case of doing what I've seen done before. Maybe some "angry monkey" but maybe more like "Hey, that seems like a good way to do it."

The mere existence of Loader, Manager, Handler, Factory, and the like classes/methods indicate a lack of expressive power in Java's constructors.

who? where? when? references?

everything is relative.

typical hacker news: someone says something that someone else takes too literally and subsequent blog posts/arguments/flame wars ensue

Gotta drive dat blog traffic.

A piece of advice: before posting, consider carefully whether you add something to the discussion. If you don't, maybe you shouldn't.

Reply on news.ycombinator.com