Hacker News Reader

I'm the kind of person that sees a bowl as a large cup without a handle.

Likewise, I see these patterns as equivalent style choices, since the problem fundamentally dictates the required organization and data flow, because the same optimal solution will be visible to any skilled developer, with these weak style choices of implementation being the only freedom that they actually have.

For example, these two are exactly the same:

    state = concept_operation(state, ...args)

and

    class Concept:
        def operation(self, ...args)
            self.state = <whatever with self.state>

and an API call to https://url/concept/operation with a session ID where the state is held.

I suspect people who get emotional about these things haven't spent too much time in the others, to understand why they exist with such widespread use.

It's like food. If you go anywhere and see the common man eating something, there's a reason they're eating it, and that reason is that's it's probably pretty ok, if you just try it. There's a reason they're eating it, and it's not that they're idiots.

A voice of sanity. The submitted article has zero meaningful content.

This comment i posted in an earlier thread rehashing Inheritance vs. Composition for the gazillionth time is highly relevant here - https://news.ycombinator.com/item?id=45943135

OOD/OOP has not gone away, has not shifted etc. but is alive and well; just packaged under different looking gloss. The meta-principles behind it are fundamental to large scale systems development, namely; Separation-Of-Concerns, Modularization, Reuse and Information-Hiding.

I thought structured program was about language support for control flow, simplification and formalization of control flow and single return. Not ADTs.

I thought I expressed that: "I came across structured programming. The core idea was ... Then there were Abstract Datatypes, ..."

I can see what you mean, I interpreted everything to be elaboration to your introductory remark:

> "We" are replacing layers of stupid shit that got layered on top of, and associated with OOP, with different renderings of the same stupid shit.

Meaning that both structured programming and ADTs are different names for the same "stupid shit", meaning the same ideas as OOP. I agree with this for ADT, that is really just the same thing under another name, but I failed to see how structured programming has something to do with OOP.

I now see, that the paragraph wasn't to be read like that.

---

This:

> All the glop that was added later -- Factories, FactoryFactories, GoF patterns, services, microservices -- that's not OOP as originally proposed. A bunch of often questionable ideas were expressed using OO, but they were not part of OO.

> The OOP hatred has always been bizarre to me, and I think mostly motivated by these false associations. The essential OOP ideas are uncontroversial. They are just programming language constructs designed to support programming practices that are pretty widely recognized as good ones, regardless of your language choices. Pick your language, use the OO parts or not, it isn't that big a deal. And if your language doesn't have OO bits, then good programming often involves reimplementing them in a systematic way.

is really the summary under every explanation or criticism of OOP. It is way more eligible for expression than most blog-posts, but it is so concise that it kind of doesn't even warrant to be that.

> And while we're at it, GOTO is never a good idea, don't use it even if your language provides it.

Good luck with that if you're a C programmer.

Well sure, but don't use it to implement if/while/for.

These are not the same thing. The GOTO people complained about and what the famous article "GOTO considered harmful" is about, is called longjmp in C. Nearly all C programmers will agree with you that you shouldn't use longjmp. The goto of C has less freedom for control flow than try-catch constructs in other languages.