11–20 of 33 posts
A page-long strawman isn't a great way to start an article. I also disagree with the author's claim that refactoring is ridiculous or different, but like the author I'm not going to elaborate.
Edit: I would love others, who have read the above mentioned book, to weigh in with your anecdotes.
https://news.ycombinator.com/item?id=17090319 - May 17, 2018 (41 comments)
There are others with 1-2 comments but no other discussions beyond that that I can find.
I suppose they're going for the "wow, are you God?" effect, but when it's a miss, it just makes them look silly.
OOP is fine. And DRY (what the core idea of the article is getting at) applies in OOP paradigms as much any another. The arguments the author makes are orthogonal to OOP.
The author seems to not enjoy planning before writing code, which I guess is more necessary for OOP than other paradigms?
A page-long strawman isn't a great way to start an article. I also disagree with the author's claim that refactoring is ridiculous or different, but like the author I'm not going to elaborate.
What's the strawman? This way of thinking is taught in universities around the world. And it doesn't stay there. I personally know people who approach problems like this.
Instead of a Manager class inheriting Employee and Contractor (which in turn inherit Person, which in turn may inherit other classes...), you'd separate employee and contractor into traits/interfaces and define distinct manager classes that implement the two traits. Of course, ultimately it's all classes and inheritance in C++ because there are no traits, but it's organized differently.
I was actually in the school of thought that this article describes until I read and worked through the book How to Design Programs [0]. The rest is upto you to judge. [0] https://htdp.org/ Edit: I would love others, who have read the above mentioned book, to weigh in with your anecdotes.
What distinguishes the approach from what is presented in this blog post, can you provide a summary for those of us who haven't read the book? I am sincerely interested.
TL;DR: DRY Nice read, though. Very approachable.
I think semantic compression is achieved by using a denser more expressive language, some languages can express the same activity in far fewer lines of code. Personally I find the denser code, harder to read, which I think also makes sense, since it contains more meaning in less space. If you are writing code, perhaps in python, and you keep following your editors instructions to refactor it, you end up with far fewe…
Prompting you to make the changes allows you to cognitively keep up in lockstep with the code changes. Further, it has no concept of your present/future intent, so perhaps not all of its suggestions apply.
TL;DR: DRY Nice read, though. Very approachable.
Yep, but with the added condition of “don’t DRY pre-maturely, that is, before you have duplicated code”.