[HN Gopher] The Power of Interoperability: Why Objects Are Inevi...
___________________________________________________________________
The Power of Interoperability: Why Objects Are Inevitable [pdf]
Author : ingve
Score : 33 points
Date : 2021-06-01 13:11 UTC (9 hours ago)
(HTM) web link (www.cs.cmu.edu)
(TXT) w3m dump (www.cs.cmu.edu)
| coliveira wrote:
| The main problem with objects is the proliferation of conceptual
| entities that increase complexity instead of reducing it. This
| was in full display with the creation of design patterns, which
| introduced a large number of concepts meant to simplify
| programming, but that in fact multiplied the number of classes in
| an exponential way sometimes without improving understanding.
| Sometimes you'll have better code by just removing the crutch,
| but OO languages are designed to favor this kind of approach.
| throw_m239339 wrote:
| "design patterns" are mostly here to make up for the flaws of
| Java or C++. For instance, there is no need for factories
| classes when a language supports passing functions as arguments
| of other functions and closures.
|
| I say mostly, because something like the Observer pattern is
| still useful even outside OO. It's also a way to communicate an
| intent or a role a certain class has.
|
| I think all the SOLID/DRY/Clean code concepts were more harmful
| to development in general than design patterns, because these
| ideals became an obsession.
| jcelerier wrote:
| > For instance, there is no need for factories classes when a
| language supports passing functions as arguments of other
| functions and closures.
|
| C++ supports passing functions as arguments and closures yet
| factories are often necessary, how else are you creating new
| objects from dynamically loaded plug-ins ?
| [deleted]
| joe_the_user wrote:
| This is brilliant.
|
| _While there has unquestionably been some hype about objects
| over the years, I have too much respect for the many brilliant
| developers I have met in industry to believe they have been
| hoodwinked, for decades now, by a fad. The question therefore
| arises: might there be genuine advantages of object-oriented
| programming that could explain its success?_
|
| A big factor is that programmers tend to be idealists. They want
| code that's the absolute best. {code: goodness(code)=max}. OO is
| a way to take pretty terrible code and go from goodness(code)=X
| to X+1. But it doesn't guarantee getting further. It might even
| make harder to go to the next iteration. That's a terrible thing
| for any idealist but absolutely crucial in practice. Most code is
| "terrible" and most code embeds a lot of institutional knowledge
| that prevents it from being tossed away (see the tendency for
| disaster from "the big rewrite").
|
| I would contrast this with the paradigm that's been "up and
| coming" for decades now - functional programming. FP aims to
| "start at the best and stay there". The problem is that even if
| we assume FP can do that, it's not aiming to solve the "increment
| the goodness" problem, which is what a lot of ordinary
| programming at ordinary companies has to involve.
| agumonkey wrote:
| objective points i hated about OOP ala Java:
|
| - mutability is always there, you're never sure something in
| the object graph will bite you back
|
| - no clear initialization, object can be "constructed" but you
| never know what state you get in the end, you need to read
| every class implicit protocol to be sure you called the right
| methods after `new` (FP asks for near in-order static trees..
| less cute but quite obvious about dependencies). that is unless
| people played fully with generics and classes (phantom types to
| express what step you're in the object state graph)
|
| - too much bike shedding about private / public fields
|
| - single dispatch forcing someone to own some logic when
| there's zero logical reason to do so
| qsort wrote:
| > FP aims to "start at the best and stay there"
|
| I'd say there's a difference between purely functional
| languages and functional concepts in general. Purely functional
| languages have indeed remained relatively unpopular (I'm not
| really sure why, but I'd guess it's a convex combination of
| "it's not how the machine works", "it's relatively esoteric
| unless you have studied math or cs" and "not very much
| backing/support"), but we've also seen functional concepts
| "contaminate" traditional OO languages.
|
| Yes, I know, it's not really "functional" and diehard FP
| programmers will hate me, but I'd still say it's evidence that
| the functional paradigm can be (and in fact _has been_ ) used
| to "increment the goodness".
| joe_the_user wrote:
| The other thing about functional programming is it involves a
| sort of tradeoff that's very different from object
| orientation. It makes functions into "first class (language)
| objects". Manipulating functions directly is a very power
| ability. As tradeoff, making functions pure and making
| variable immutable limits that power and makes your
| operations on functions understandable as well as powerful.
| Because if you take functions with side effects and
| manipulate these in various ways, you can quickly wind-up
| with a powerful but incomprehensible system.
|
| This means that "functional effects" do sometimes do best as
| something like subsystems called by the main system.
| Jtsummers wrote:
| > Purely functional languages have indeed remained relatively
| unpopular (I'm not really sure why, but I'd guess it's a
| convex combination of "it's not how the machine works", "it's
| relatively esoteric unless you have studied math or cs" and
| "not very much backing/support")
|
| My intuition on this:
|
| Procedural/imperative thinking is more "natural" for most
| people. Asking someone to explain a process without any
| formal training in any formal language/modeling process on
| this (ie, a non-programmer) they'll give you a
| procedural/imperative description of what to do.
|
| OOP languages are, mostly, procedural/imperative languages
| with extra constructs. To varying degrees these constructs
| are organizational as much as actually substantive additions
| to the execution model. For instance, classes in Java are
| modules for collecting related behavior and controlling
| access to (usually) private data fields. They can be seen as
| "rich" structs: data objects + procedures for altering the
| data.
|
| Now, polymorphism actually adds a lot more and can be used to
| subsume other control flow mechanisms, I'm not saying that
| OOP is _just_ procedural + organizational elements. But as a
| first pass, people can step into OOP by treating it as such
| and learn the rest as they continue.
|
| FP languages, by contrast, _do not_ start off as procedural +
| first class functions or expressive type systems. In
| particular, the pure FP languages drop the imperative notions
| (or obscure them). This creates a major hurdle for many
| would-be learners. Their intuition doesn 't apply to these
| languages.
|
| See also Prolog and relational programming for another area
| where people's natural tendency towards imperative thinking
| creates a major block on learning (or on using it to its
| potential).
| [deleted]
| [deleted]
| bcrosby95 wrote:
| Yep. This is also why people suck at OOP, because most
| "good" OOP isn't a series of instructions - it's an
| abstraction layer - e.g. "ask, don't tell". Lots and lots
| of "OOP" ends up bad and telling and digging into internals
| with train.wrecks.like.this.
|
| Really, most people would probably be more at home coding
| in something like a safer version of C.
| MarkLowenstein wrote:
| I'm an obsessive idealist and I blame OO programming for my
| unfathomable (to most people) lack of productivity. With OO I
| always see, for instance, that code organization B is better
| than code organization A for very good reason. And C is better
| than B. But then A is better than C, also for good reason.
| After that nothing gets done.
|
| I feel like I got more done writing assembly when I was 13 than
| I do today.
| ssivark wrote:
| IIUC, this article highlights the importance of dynamic dispatch,
| but implicitly restricts itself to single dispatch (OOP)
| completely eliding any mention of multiple dispatch.
|
| Single dispatch is great/sufficient for modeling process
| encapsulated by a "single agent" but multiple dispatch feels far
| more elegant to encode _interactions_ between multiple agents.
|
| Eg: Neither a.sum(b) nor b.sum(a) is as cleanly extensible as
| sum(a,b)
| agumonkey wrote:
| any resource on multiple dispatch design ? i'm doing some
| common lisp and I have to admit I'm walking in the fog a bit
| Verdex wrote:
| IIRC Practical Common Lisp does a pretty good job with it.
|
| https://www.amazon.com/Practical-Common-Lisp-Peter-
| Seibel/dp...
| oscardssmith wrote:
| If you are interested in multiple dispatch, you really should
| check out Julia. In my opinion, the biggest reason Julia has
| been as successful as it has is that everything uses multiple
| dispatch, and the system for it is simple enough that you
| might not notice.
| agumonkey wrote:
| forgot julia used it, thanks
| abss wrote:
| Nice title but the article is a bit boring. I am an old
| programmer by now.. and i agree that objects are inevitable as
| are other paradigms too. Each tool has good and bad cases...
| Anyway, beside ADTs and other perspectives, objects are a nice
| way for compressing (give identity and establishing a set of good
| enoug number of proprieties) for complex (messy) relations and
| interactions. Functions are another way as also rules,
| constaints, etc. There is a concept called "swarm communication"
| that propose a deeper concept in the same direction as objects.
| It is possible to give identities to swarms of objects
| interacting in complex distributed systems. This concept is
| somehow also inevitable but I found it difficult to explain with
| words but much easier to explain to programmers showing a bit of
| code ;)
| slver wrote:
| Curious about those swarms. What is a use example.
| abss wrote:
| Examples: 1. executable chreographies implemented as messages
| belonging to the same identity (swarm of related messages) 2.
| workflows (BPM kinf of stuff when you look at them as long
| living processes). In this case the process dies and get
| revieved in time. All these instaces belonving to a single
| concept. 3. Even smart contracts fall under this swarm
| approach because the execution happens in many places but
| somehow it is still a single concept.
|
| In an way, obkects are just degenrated swarms...
|
| The whole idea is quite simple but maybe a bit too
| abstract... We proposed even an simple primitive called
| "swarm" that can be used to program. I had a old project
| called swarmesb (not active anymore) but this perspective got
| me to a lot more insights in another open source research
| project called privatesky...
| https://privatesky.xyz/overview/swarms-explained is an
| attempt i made to explain this way of seeing swarms.
| jt2190 wrote:
| (2013)
___________________________________________________________________
(page generated 2021-06-01 23:01 UTC)