Live data from Hacker News

Alan Kay on the misunderstanding of OOP (1998)

lists.squeakfoundation.org

71–80 of 212 posts

Re: Alan Kay on the misunderstanding of OOP (1998)

#73
post #51

I might be wrong, but I think people like Alan Kay and Christopher Alexander have in common that they: * see that things can be done better (not as in upgrade but best); * have a global idea/feeling of how this could be done; * take a lot of ideas from nature. And somehow I think they have a lot of trouble expressing the 'how'. My take: we should take a good look at nature because this is closest to what we are. For…

> communication between objects could be learned from cells

So, message queues? I completely agree.

Re: Alan Kay on the misunderstanding of OOP (1998)

#74
post #54
post #40

I find it interesting that everyone gets so up-beat about the ideology or philosophical debate about objects sending each object messages, hell even not relying to a message one object send you until a later date. Without even thinking about concurrency, state, and hell even the basics such as cyclic loops within a event based system! Though I keep hearing from Alan and other prominent language designers that we stil…

> I've seen too many project's that have drunken the cool aid and has resulted in 5-10 level deep inheritance tree's with their own branching logic trying to fit behavior to a specific taxonomy. I don't think you understand Alan Kay's version of OOP, if you think inheritance is a key part of OOP. I was interested in this stuff during the summer and I wrote up the following question/answer if you're interested on what…

I read your essay on programming languages. I found it was awesome btw.

I saw you made the comment `o be concrete - object oriented programming is easy in python, because it's possible to program methods of an object in a way that doesn't assume a particular representation.`

I thought you would be really interested in usage of polymorphism in python (http://neverworkintheory.org/2016/06/13/polymorphism-in-pyth...).

Quote from the article: `Our findings show that the receiver in 97.4% of all call-sites in the average program can be described by a single static type`.

It looks like even when that restriction is removed it doesn't really help that much.

Another great podcast on evidence based programming: https://www.functionalgeekery.com/episode-55-andreas-stefik/

Evidence-based programming language design : a philosophical and methodological exploration: https://jyx.jyu.fi/dspace/handle/123456789/47698

Is another great read if you've got the time.

Re: Alan Kay on the misunderstanding of OOP (1998)

#75
post #73
post #51

I might be wrong, but I think people like Alan Kay and Christopher Alexander have in common that they: * see that things can be done better (not as in upgrade but best); * have a global idea/feeling of how this could be done; * take a lot of ideas from nature. And somehow I think they have a lot of trouble expressing the 'how'. My take: we should take a good look at nature because this is closest to what we are. For…

> communication between objects could be learned from cells So, message queues? I completely agree.

Does queuing occur when cells communicate?

Re: Alan Kay on the misunderstanding of OOP (1998)

#76

Does anyone know what Alan means by "assignments are a metalevel change from functions, and therefore should not be dealt with at the same level"? In what way are assignments a metalevel change from functions?

I believe he means that variable and their assignments are at a lower level. Objects interfaces should be defined in terms of the messages they can send and receive. No exposed variables: Variables should always be private/protected and are just used by the objects to maintain their internal state.

Re: Alan Kay on the misunderstanding of OOP (1998)

#77
post #75
post #73

Earlier quoted context omitted.

> communication between objects could be learned from cells So, message queues? I completely agree.

Does queuing occur when cells communicate?

Sort of. AFAIK, cells basically just send out signals and the nearest available cell with a compatible protein that can "read" the signal picks it up.

Re: Alan Kay on the misunderstanding of OOP (1998)

#78
post #14

IMO the problem with object-oriented programming is that it turned into the standard curriculum for peoples' first semester of computer science, rather than being yet another interesting concept that advanced programmers would ponder. And the way we handle "the standard CS curriculum" sucks. (In the USA at least.) For example, AP Computer Science requires Java and tries to teach stuff like designing inheritance hiera…

Have you actually talked to educators about this? I've asked a few why OO is the first thing you learn - and the reasoning was two fold: 1) People that start off by learn imperative programming end up writing really really shitty OO code. They're they type of people that end up copy and pasting stuff everywhere. It's really hard to get students to not take the "short cut" of copy paste to think in objects when you ha…

People have trouble understanding OO because usually it is presented informally with insufferable dog/cat/mouse examples.

Moreover, the fact that "subclassing==subtyping is unsound" is swept under the rug. A lot of people actually grasp the latter at an intuitive level, that's why they're never comfortable with objects.

OO should be taught as abstractly as possible (I recommend Didier Remy's writings). After grasping the concepts, many people will conclude that they'll be better off with FP and modules.

Re: Alan Kay on the misunderstanding of OOP (1998)

#79
post #14

IMO the problem with object-oriented programming is that it turned into the standard curriculum for peoples' first semester of computer science, rather than being yet another interesting concept that advanced programmers would ponder. And the way we handle "the standard CS curriculum" sucks. (In the USA at least.) For example, AP Computer Science requires Java and tries to teach stuff like designing inheritance hiera…

OOP should be something you only get into after you have written some practical programs

I'd modify that to "practical programs that are nontrivial enough to benefit from OOP", just like how I advocate not teaching about functions until they become useful. IMHO the CS curriculum should start with the low-level basics and work up from there in a natural progression:

    - Representation and interpretation of binary data.
    - Basic straight-line computation (more like calculation), concept of instruction execution
    - Flow control: decisions, loops
    - Functions/procedures/subroutines
    - Grouping data together: Arrays/structures/records/etc.
    - Basic OOP, grouping data and code together: Objects, composition, inheritance
    - Advanced OOP: virtual functions/polymorphism/etc.
I have worked with some of that type of Java-student you mention, and it is astounding how many can create huge object-oriented monstrosities (including design patterns), the bulk of which are object creation and method calls, while not understanding arrays or even basics like why datatypes have a finite range. Their code has more object creation and method calls than branches, loops, or simple computational statements. Given that sort of inverted knowledge they have, that they fail fizzbuzz is not surprising at all. It also explains a lot of the inefficiency and bloat in most software. It's somewhat like teaching calculus to students who don't know arithmetic.

Re: Alan Kay on the misunderstanding of OOP (1998)

#80
I don't really understand this obsession with messages.

We're moving away from it. This is not how we program in the 21st century. The last popular language that supported this paradigm (Objective C) is being replaced and will probably be all but gone in just a few years as Swift (not message based) takes it place.

Besides, this idea of message passing is really not that useful for modern programming anyway but a lot of people still have this weird idea that message passing magically solves the problem of data integrity in parallelism. It doesn't. It does nothing to solve it. You can still have deadlocks and you can still have data corruption.

The only approach that has provably improved our problems in this area is immutability, but even that paradigm comes at a cost that sometimes doesn't make it worth the trouble

Post reply on HN