Live data from Hacker News

Anthropomorphism Gone Wrong: OOP

loup-vaillant.fr

61–64 of 64 posts

Re: Anthropomorphism Gone Wrong: OOP

#61
post #51

Earlier quoted context omitted.

According to Alan Kay: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... --- OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. --- I think over the years OO just ended up meaning "whatever C++, Ja…

Maybe concede the term OOP to Java, C++, et. al. and call message passing among processes service-oriented programming or something.

...and give up the opportunity to remind programmers their OOP is the inferior OOP? :)

Re: Anthropomorphism Gone Wrong: OOP

#62
post #55
post #52

Earlier quoted context omitted.

> having all procedures that operate on and change the state of an object in the same file is super helpful. How many OOP programs do you know that have achieved this? None that I know. Perhaps utility libraries can get close, but no software actually solving domain-specific problems. Objects don't live on their own, in a typical OOP program there are bits of code all over the place that operate on your data objects.…

> Objects don't live on their own, in a typical OOP program there are bits of code all over the place that operate on your data objects. Finding all the ways that a personel record is modified can be a tricky problem. Searching for all the code that touch an Employee record class is much easier than searching for all the code that touch a generic hashmap that supposes to contain the employee data.

Why on earth would you use an untyped generic hashmap for employee record data? What kind of language do you think forces you into that kind of architectural decision?

Certainly no language I have or would develop an MIS in, regardless of paradigm.

Re: Anthropomorphism Gone Wrong: OOP

#64
post #49

Earlier quoted context omitted.

I read a Java textbook that started with something like "OO allows you to model things like they are in reality. A dog has a tail, and it can be wagging or not. A dog has a name..." But dogs don't 'have names' in the OO sense. Humans have names for dogs. We can give a dog two names and it doesn't matter whether other dogs have two names or not. We can have a dog with no name, yet we can still call it by something as…

Well names are a bit of a bad example. Entire fields of study were spawned from that example [1]. A better example might be a credit card, which always has a number and a cardholder. Things get interesting when you might formalize: * Expiration (do all credit cards expire? Is expiration necessarily a date, or is it a predicate?) * Cardholder - referent might be another entity in your system * Is the card number encry…

These kind of issues lead to the development of aspect-oriented programming, which is an attempt to better match our intuition about how things in reality behave in a compositional manner.
Post reply on HN