[HN Gopher] OOP "is really just a common sense extension of stru...
___________________________________________________________________
OOP "is really just a common sense extension of structured
programming"
Author : jjuliano
Score : 22 points
Date : 2022-09-09 21:07 UTC (1 hours ago)
(HTM) web link (archive.org)
(TXT) w3m dump (archive.org)
| gorgoiler wrote:
| I'm not sure what I supposed to be reading here but the title at
| least rang a bell of recognition for me.
|
| Programming to an interface, composition, immutable classes and
| objects as fancy closures that can do more than one thing:
| _Drake-yes-please.jpg_
|
| Inheritance for code sharing: _Drake-no-thanks.jpg._
|
| One thing I really miss from my Java days, and which I don't
| really think has anything to do with OOP, is the concept of
| package visibility. Private data for the class itself. Protected
| data for inheritors if you dare have them. Public for anyone
| using your library. And package level visibility for me and my
| team to have special privileged access to these things in the
| same module, but which one outside of it is allowed to touch.
| It's a great feature for large groups of programmers.
| arinlen wrote:
| > _One thing I really miss from my Java days, and which I don't
| really think has anything to do with OOP, is the concept of
| package visibility._
|
| C++ has that in the form of internal linkage. You can have all
| the symbols you want that are only visible within your own
| translation unit.
| kerblang wrote:
| OOP gives excellent benefits as concerns scope control, and since
| many of us are suffocating to death under overwhelming scope,
| there's a win.
|
| As for the handwaving about simulation & modelling and We Must
| Design The Matrix and all that nonsense... not applicable to most
| programming.
| swatcoder wrote:
| It's true.
|
| But eventually a junior developer realizes that a Triangle is an
| PolygonalOpenFrameMetallicPercussionInstrument and it now has 4kb
| of private state, 307 inherited member functions, and floods your
| console when its logged.
|
| I love OOP, but caution is indeed warranted.
| pipeline_peak wrote:
| What is a "private state" and how would you know its size?
| zozbot234 wrote:
| Not a concern if PolygonalOpenFrameMetallicPercussionInstrument
| is just a pure interface/type-class/trait. Now, is that (i.e.
| interface-only inheritance) still OOP proper, or just a case of
| "object based" coding, a straightforward "common sense
| extension" of simple data abstraction? People will disagree
| about this point, and it's mostly just a matter of definition.
| pier25 wrote:
| You can totally have OOP without inheritance.
|
| In fact "composition over inheritance" is a thing in the OOP
| world.
|
| https://en.wikipedia.org/wiki/Composition_over_inheritance
| erokar wrote:
| Sure you can -- in your own code. But everywhere else
| inheritance is a virus. Spring, Rails, .NET Core, Django,
| Pydantic -- just to take some random examples are all
| fundamentally base on inheritance.
| WesolyKubeczek wrote:
| But why not have both?
| adgjlsfhk1 wrote:
| inheritance makes your code slower even if you don't use
| it.
| WarChortle18 wrote:
| That's a very broad statement care to back it up?
| alexalx666 wrote:
| in fact I dont remember when I last used inheritance,
| protocols and composition used a lot
| tyurok wrote:
| It's a thing because inheritance got out of hand.
|
| Inheritance x composition is orthogonal to OO.
| pyrale wrote:
| Ah yes, "You wanted a banana but what you got was a gorilla
| holding the banana and the entire jungle".
| phpthrowaway99 wrote:
| I like to think I'm a decently intelligent person. UC Berkeley
| Mechanical Engineering. I self taught a few years ago and wrote
| an entire project management SaaS for a certain industry in PHP
| and jQuery front end. 34 small companies use it.
|
| Even though I once took a highschool C++ course long ago that
| talked about OOP and made us do a few things with it.....
|
| I still have no idea what OOP really is, and why I need it.
| Unless I'm using it without knowing, I have a feeling I'm either
| dumber than I think or people have lost their minds. I can't
| tell.
| civilized wrote:
| Self-taught programmers have an easier time thinking in a
| simple, direct, solution-oriented way. CS-educated programmers
| tend to think too much about whether this project gives them an
| excuse to use fancy things they learned in courses (how can I
| cram algebraic types into my recipe management program?).
|
| The downside of being self-taught is well-known - you might end
| up convincing yourself that for loops don't work, strings with
| more than 10 characters are unreliable, numbers can only
| reliably be added using BigDecimal, etc.
| dpkirchner wrote:
| Self-taught programmer checking in: OOP is about isolating
| private implementation details, akin to using local variables
| inside a function. Seems pretty direct to me.
| bostonsre wrote:
| I think this is why some people call software development
| software engineering. If you don't take into account a lot of
| different things and engineer for stability and
| maintainability it can become a headache in the future. It
| may be simple and direct, but I wouldn't feel comfortable
| crossing a bridge made of 2x4s and plywood that was slapped
| together in a weekend and it would just make more work for
| someone else down the line because it probably wouldn't last
| very long.
| bentcorner wrote:
| As mostly self-taught, I found that OOP makes more sense when
| you're working with many people and to simplify organization
| boundaries you deal with interfaces on abstract objects. Your
| team owns a window which calls click() on something owned by
| another team that implements IWindowControl. That
| IWindowControl interface is something you agree upon, but the
| internals of each object are invisible to each of you.
| ReptileMan wrote:
| And yet common sense is(was) severely lacking in most OO
| languages implementations.
| slively wrote:
| If it's not common, maybe it's not common sense?
| astrange wrote:
| If you have to justify proposals with explicit reasoning (or
| conversely, if you're allowed to), then it's hard to reject
| them because they go against common sense, since it's hard to
| just say "my intuition told me this would be bad".
| recursivedoubts wrote:
| "Object-oriented programming is an exceptionally bad idea which
| could only have originated in California." --Edsger Dijkstra
|
| NB: I am from California and I like object oriented programming.
| maxbond wrote:
| Dijkstra was the original HN flame warrior.
| AprilArcus wrote:
| OOP's greatest crime is needlessly adding an I-thou dichotomy to
| the realm of programming languages. The "switching" or context
| sensitive properties of deictic pronoun referents is one of the
| last and most difficult linguistic skills that first language
| learners acquire. Class instances add deixis to programming
| languages, which never needed it and don't benefit.
| maxbond wrote:
| Is it that programming languages don't need deixis or that OOP
| does it badly? I think OOP makes context more diffuse and you
| encounter it more often. I think that data-oriented languages
| like SQL do a better job of managing context. But I can't say
| whether or not it is necessary and I don't think I've used a
| programming language without it, so I don't know what that
| programming paradigm would be like and whether I'm missing out
| something.
| MauranKilom wrote:
| Could you translate this into English, please?
| nighthawk454 wrote:
| attempt: a class and an instance of a class aren't the same
| thing, which creates cognitive load to distinguish
| IshKebab wrote:
| I think he's trying to say that object methods now can refer
| to two different tenses of things - this/self/me, and
| everything else (it/that). In C there is only the latter.
| (And also "look at the clever words I know!")
|
| It's nonsense though because this/self is barely more than
| syntactic sugar for what C programmers do anyway - in fact
| languages with UFCS let you choose arbitrarily. Writing free
| functions with `this` as the first parameter doesn't really
| change anything.
| samatman wrote:
| I think they're complaining about `this`, which I also find
| annoying, but don't feel the need to dress that up in fancy
| terms.
|
| My issue with `this` and things like it is that the first
| argument (the 'object') is usually the most important thing,
| and it's easier to read methods if they have a name.
|
| Ok, you can call this deixis but do you need to? Clearly not.
| maxbond wrote:
| Your fancy terms are someone else's terms. It was critical
| to their point about how deixis specifically being
| difficult for new language learners. Addutionally I enjoyed
| skimming the Wikipedia articles and considering programming
| languages as languages; I got more out of it than I do most
| HN comments.
|
| I think it's fair to skip over a comment using terminology
| you find tiresome, be it because you aren't familiar, or
| you find it irritating for some reason, or for any reason;
| it's your time. I think it's unnecessary to insist we all
| use the same terminology, as that just limits what
| conversations can be had and who can have them. One of the
| things that makes HN feel magical is when people from a
| weird discipline jump in to give their two cents, and they
| add value to the community when they bring their
| terminology with them.
| IncRnd wrote:
| They are saying they favor the emacs model over that of vi,
| and that subsequent editors have not added any appreciable
| value. Well, that's what they said, after transpiling into an
| editor discussion about modal vs. non-modal editors against
| the backdrop of forking editors in order to add new features.
| klabb3 wrote:
| This.
| rileyphone wrote:
| It's far from needless - doing so enables syntonic reasoning
| [0] by the programmer, as originally explored by Papert in
| Logo's turtle graphics, which was one of the direct
| inspirations for Smalltalk. There's a reason this "last and
| most difficult linguistic skill" is so handy - with it we can
| refer to objects across space and time.
|
| 0.
| https://www.tech.dmu.ac.uk/~mjdean/notes/modules/education/E...
| [deleted]
| bumblebritches5 wrote:
| nine_zeros wrote:
| Having worked with physical models that store state in memory
| during simulations, I assure you that OOP has its place and works
| very well.
|
| Without OOP, we quickly get into codebases much like JavaScript
| where every new framework attempts to reinvent the same thing in
| even more contrived ways.
|
| The only place where OOP style doesn't make sense is in stateless
| programs, which a lot of web backends are (but even there, it's
| often useful to hold connections and to create good interfaces).
|
| Don't let your code in any language go down the JavaScript
| framework path.
| echelon wrote:
| The biggest problem with OOP is the concept of class hierarchies.
| They're an unnatural representation of units of work and state
| that force obtuse topological reasoning where there should be
| none.
|
| Traits and type classes are a much better solution that offer far
| more flexibility, yet still allow the programmer their own
| balance of expressiveness and rigidity.
|
| Of course data can have defined behavior. Don't try to marshall
| it into genetic lineages of parents and ancestors. That's an
| orthogonal and entirely made up problem.
| zozbot234 wrote:
| Traits and type classes are broadly the same as interface
| inheritance. So there still is a hierarchy, it's just
| restricted to the interface layer as opposed to impacting the
| implementation.
| nsajko wrote:
| OOP is just a buzzword. There's no clear meaning behind "OOP" as
| far as I see, it's not even close to being well-defined, it just
| serves to confuse and fuel pointless discussions and arguing
| about semantics (see this thread, for example).
| mikewarot wrote:
| In Turbo Pascal/Delhi/Free Pascal/Lazarus, the OOP seems quite
| sane.
|
| The whole abstract factory generator class iterator thing I see
| in other languages scares the bejeezus out of me.
| gballan wrote:
| I model systems that naturally have block diagrams (modulators,
| phase locked loops, power amplifiers, channels...). I came to an
| object oriented approach relatively late, but I would not go
| back. I don't know about general software, but for simulating
| physical systems it seems ideal.
| mixedCase wrote:
| Objects are a good tool.
|
| Isolating some kinds of state in more manageable units can be
| very handy while remaining unmaintainable.
|
| Even inheritance can be nice under the right circumstance.
|
| Object _oriented_ programming? An unmitigated disaster.
| Twisol wrote:
| For those wondering, the quote in the submission is in the first
| paragraph of the Preface, page vii.
| hudon wrote:
| In terms of readability and maintainability, one problem with OOP
| is the development process that tends to go with it, where you're
| asked to create upfront the separation of concerns, before code
| has had a chance to run and breathe for a while. Most of the
| time, you end up being wrong on how things should be segregated,
| and your behavior ends up fragmented across a variety of objects,
| making it difficult to easily see the flow of your program.
| Actions related to a Widget end up not actually being neatly
| encapsulated in a Widget, and encapsulation is one of the major
| selling points of OOP.
|
| It's probably best to start off a solution with plain old data
| structures, and plain old functions (ie. procedural style). Build
| with that until right abstractions or separations emerge.
| colordrops wrote:
| Also, within the context of an individual class, variables can
| be modified and accessed anywhere in the class, creating all
| the same problems as global variables.
| bostonsre wrote:
| If the single responsibility principle is followed and
| cohesion is strong, it should help mitigate these concerns.
| Creating large uber classes can quickly become troublesome.
| arinlen wrote:
| > _Most of the time, you end up being wrong on how things
| should be segregated, and your behavior ends up fragmented
| across a variety of objects, making it difficult to easily see
| the flow of your program._
|
| This can only become a problem if you pay little to no
| attention to modularization, software architecture, and even
| encapsulation.
|
| The responsibility of a paradigm and a language is to allow a
| developer to freely express their concepts. The programming
| paradigm is not to blame if the developer chooses to express
| poorly thought-out ideas that are riddled with detrimental
| consequences.
| alfiedotwtf wrote:
| This is the same reason why I think TDD is the wrong approach
| too. How do you test before you know what you're building?
|
| I've tried everything but my favored approach these days is
| just to stream of conscious psuedocode in main() to get the
| shape of what needs to happen, and then backfill until there's
| something working. Once I know what I want, only then do I
| break things up so that everything is in the right place. It
| seems to end well every time.
|
| tl;dr: bottom-up, and top-down are too extreme!
| rileyphone wrote:
| It's important to note that there are two schools of OOP that
| often get conflated and muddy the waters of understanding. On the
| one hand is the one evidenced in the OP and C++, where OOP is
| mostly an organizing principle and function calls are bound
| early. On the other side is the Smalltalk school, emphasizing
| message passing and late bound everything, which is slower but a
| lot more dynamic and flexible, as best laid out by Kay in his
| famed email [0]. At this point, object-oriented programming is
| about as precise a term as socialism (and equally likely to start
| a flamewar).
|
| 0. http://lists.squeakfoundation.org/pipermail/squeak-
| dev/1998-...
| yakubin wrote:
| Something being common sense is not a good argument for it making
| sense. The most obvious demonstration of that is physics. Our
| common sense is hopeless at modelling the world around us
| accurately. Maths is better at that. In programming, similarly,
| algebraic properties and representation in memory should be
| preferred over a reasoning that something is just "common sense".
___________________________________________________________________
(page generated 2022-09-09 23:02 UTC)