Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fifty Shades of OOP

lesleylai.info

Post reply on HN
Print view View original

31–40 of 119 posts

Re: Fifty Shades of OOP

#31

Post by igouy »

dmux wrote: post #9
igouy wrote: post #7

Earlier quoted context omitted.

Smalltalk can use build & deploy. (Image as cache, not archive.) "At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the ima…

Yes, you could also build and deploy a Smalltalk system, but my point is that the “build & deploy” approach (to me) seems antithetical to the message passing and late-binding paradigms. To use another example, it seems like you lose a lot of the benefits of Common Lisp via Slime (hot code reloading) if you deploy your Common Lisp app to a short-lived, ephemeral environment.

> (to me) seems antithetical to the message passing and late-binding paradigms

(To me) seems like build & deploy as dev process and message-passing & late-binding as implementation technique.

Separate concerns, I probably misunderstood.

Re: Fifty Shades of OOP

#32

Post by fmjrey »

jolt42 wrote: post #5

My OO projects were usually in Java with a DB. They all ran afoul of what Martin Fowler calls the Anemic Domain Model. Basically your objects are data-only, so there's no benefit. In addition Spring injection became ubiquitous, and further killed objects with behavior. The only project using a DB and had objects with behavior was an old one that happened to use TopLink as an OR mapping.

OO fatigue is a healthy symptom of readiness to move to clojure, where data and functions are free to live without encapsulation. No king of nouns, no king of execution!

Re: Fifty Shades of OOP

#34

Post by hgs3 »

> I feel that prototypes are harder to wrap one’s head around compared to classes.

This is sad to read because prototypes are conceptually easier to understand than classes. It’s unfortunate that most developers experience with them is JavaScript, because its implementation is extremely poor. I recommend trying Io which is very Self inspired as well as Lua.

Re: Fifty Shades of OOP

#36

Post by bazoom42 »

aussieguy1234 wrote: post #35

One may argue xml is superior to json, which it is. But json wins out because it can be learned much more quickly. Something similar could be said with OOP vs Functional Programming.

So which one is the quickest to learn? I think Python is easy to learn and C++ is hard, and Scheme is easy and Haskell hard.

Re: Fifty Shades of OOP

#37

Post by sph »

Mikhail_Edoshin wrote: post #15

There is a good methodological principle stated by a Soviet philosoph Ilyenkov: to understand the nature of a thing build or describe a minimal working model of the thing. So simple that if you remove any single detail it ceases to work. He himself gave an example of radio: to understand what radio is build a minimal radio sender and receiver of three or four details each. Do not start with a household radio unit tha…

Minimal working model of object orientation, that cannot be simplified further? Look no further than Piumarta’s https://piumarta.com/software/id-objmodel/

As beautifully shown in that paper, all you need is a primitive “message send” operation and a “lookup” message, pretty much everything else in OOP isn’t necessary or can be implemented at run-time.

Re: Fifty Shades of OOP

#39

Post by elric »

vips7L wrote: post #29
ejflick wrote: post #8

Earlier quoted context omitted.

> Basically your objects are data-only, so there's no benefit. This makes me wonder why most of us use Java at all. In your typical web app project, classes just feel like either: 1) Data structures. This I suspect is a result of ORM's not really being ORM's but actually "Structural Relational Mappers". - or - 2) Namespaces to dump functions. These are your run-of-the-mill "utils" classes or "service" classes, etc. T…

Service classes are the thing I hate most. They’re just namespaces for functions. They’re a product of Java not being able to have top level functions.

Not being able to have top level functions is a feature, not a bug.

You can declare static methods on interfaces in Java, which means you could call things like Users.create("Foobar") if you wanted to.

Re: Fifty Shades of OOP

#40

Post by elric »

jolt42 wrote: post #5

My OO projects were usually in Java with a DB. They all ran afoul of what Martin Fowler calls the Anemic Domain Model. Basically your objects are data-only, so there's no benefit. In addition Spring injection became ubiquitous, and further killed objects with behavior. The only project using a DB and had objects with behavior was an old one that happened to use TopLink as an OR mapping.

Why did you create an anemic domain model?

Java has had "data carriers" in the form of records for a while now. Immutable(ish), low boilerblate, convenient.

    record User(String name){}
Records are great when doing more "data oriented programming".
Post reply on HN