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

Alan Kay on the misunderstanding of OOP (1998)

lists.squeakfoundation.org

Post reply on HN
Print view View original

151–160 of 212 posts

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

#151

Post by kmiroslav »

optforfon wrote: post #113
kmiroslav wrote: post #81

Earlier quoted context omitted.

> If anything I feel the failure of OO languages What failure exactly? OOP has flaws but it has certainly proven to be extremely versatile and adaptable over these past decades since even today, it's still the dominant paradigm to solve modern problems in computing.

Sorry, I mean "drawbacks". One of the reoccurring complaints about OO is that it leads to huge codebases. Lots of articles about how X rewrote some Java program in Y and it's not 10x smaller and 100x more maintainable. This is a consequence of languages being designed to be minimal in terms of keywords - trying to push off as much as possible on to library writers. Unfortunately this seems to have serious limitations…

"Huge code base" is a pretty vague metric. Huge in what, lines of code? Binary size?

I'd argue that neither of these are really a good measure, I'm more interested in the concepts that a source file captures than its size in kb, because these concepts correlate directly to how easy it will be to evolve that code base in the future. There is a point of diminishing return in trying to make the code too compact, which basically means you're optimizing in one dimension at the detriments of all the others.

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

#152

Post by ruraljuror »

infinite8s wrote: post #135
kmiroslav wrote: post #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…

>> This is not how we program in the 21st century Sadly, how we program in the 21st century isn't much different to how we programmed in the early 20th century when computers were first invented (at least to a 1st order approach). Where are the Maxwell equations of Computer Science?

Perhaps this is what you're referring to, but according to Kay they can be found in Lisp.

http://queue.acm.org/detail.cfm?id=1039523

https://www.amazon.com/LISP-Programmers-Manual-Michael-Levin...

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

#153

Post by lbenes »

kmiroslav wrote: post #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…

No, message passing doesn’t solve all the problem of parallelism, but it is one of the most powerful and useful tools to have in our toolkit when attacking these problems.

I hope it doesn’t dominate as OOP did in the 90s, as many other models such as actor and dataflow still have a lot of room for research and improvement.

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

#154

Post by njharman »

kmiroslav wrote: post #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…

Every http request/response is a message.

Every task queue, every AMQP/message system are message based systems.

Modern development is lousy with message based architectures. It's just at the system level and not natively supported paradigm in most languages.

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

#155

Post by endlessvoid94 »

jonahx wrote: post #149

I'd love clarification on a few points, from anyone who understands everything Alan says here: Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard Is he referring here to alternative protocols from http, or to the fact that behind the single http protocol are servers written in myriad languages and styles? If you focus on just messag…

> Is he referring here to alternative protocols from http, or to the fact that behind the single http protocol are servers written in myriad languages and styles?

My interpretation is that the design of TCP/IP (and maybe HTTP?) focuses on the behavior of the components from the perspective of how they communicate with one another, not how they behave internally. They follow the Robustness Principle: Be conservative in what you do, and liberal in what you accept from others.

> What is a metasystem? Can you provide an example? Similarly, what are 2nd level architectures?

It took me a long time to understand what this means. Basically, a metasystem is a blurring of the language and the code you write within that language. Smalltalk is an example of such a system because you can change the language itself from within the language and the environment.

There are downsides to such a system, though, including the proliferation of many fragmented, inconsistent environments. To take a deliberately ridiculous example, let's imagine Ruby was a metasystem. You write some code in your rails app that allows a third method privacy mechanism beyond public, private, and protected. Or, that you decide you want multiple inheritance in ruby.

That's powerful -- and dizzying for many people not accustomed to thinking about their languages at that level. So, what Alan is suggesting is that we erect "fences" of some kind to both allow this power in our languages but in a protected manner, so that we mitigate the risk of the fragmented world that could result. (Since you've essentially created a new "flavor" of ruby by changing its behavior.)

There is a fantastic book on this topic called "The Art of the Metaobject Protocol" that I highly recommend. It guides you through building an object oriented language construct from within Common Lisp.

I don't know what he means by 2nd-level architectures, nor what he's saying about assignments being meta-level change from functions.

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

#157

Post by notduncansmith »

kmiroslav wrote: post #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…

Message-passing is a necessary but insufficient abstraction. It's not pixie dust, but if you want to build a robust and organized system you'll probably want to reach for it. For the data integrity issue, you need to have a strong data model implemented upon your message-passing architecture, like an immutable event log. Project useful aggregations and indices from that. I'm wrapping up an implementation of exactly this today (Node.js + Kafka = poor man's Erlang actors), AMA. Email is in my profile as well.

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

#158

Post by jstimpfle »

jdmichal wrote: post #118
Retric wrote: post #115

Earlier quoted context omitted.

Functions have no internal state. Early languages used global variables to share state across functions without explicit message passing (everything was a singleton). This created worlds of pain. The alternative was passing state with each function call. This also got painful as people often passed data down through functions. OOP lets chunks of functions share state and hide that state from the wider application. Mo…

> Functions have no internal state. But closures do. And thus, why closures are a poor man's objects, and objects are a poor man's closures. As an example, Java closures are really anonymous objects with the closed state as instance variables. > More importantly you could have multiple instances of that shard state without explicit management, saving a lot of complexity and effort. Technically that's what classes giv…

If you apply this common understanding of "closure" where the values that closures close over are not really values but mutable objects, then closures don't count as (pure) functions.

If one thinks of them as proxies to the closed-over objects, they are quite like "procedures". Another way to think about them is simply as objects with only a single method.

Post reply on HN