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

Alan Kay and OO Programming

ovid.github.io

Post reply on HN
Print view View original

31–40 of 141 posts

Re: Alan Kay and OO Programming

#31

Post by gnclmorais »

LandR wrote: post #4
warent wrote: post #2

I have a ton of respect for Alan Kay and think he's a genius. But why does it seem like every time he talks about OO it's always painting an apocalyptic picture like we're in some kind of twilight zone alternate nightmare reality of broken patterns and models? Surely our concept of objects and OOD can't be that bad, but his apparently contrary outlook is just so persistent...

> I have a ton of respect for Alan Kay and think he's a genius. But why does it seem like every time he talks about OO it's always painting an apocalyptic picture like we're in some kind of twilight zone alternate nightmare reality of broken patterns and models? Because we are? Have you seen most OOP code-bases, they are a train wreck!

Could you elaborate on the “most” part? Coming from my experience on Rails over the past couple of years, I’m quite happy with what I’ve found so far.

Re: Alan Kay and OO Programming

#32

Post by eternalban »

kstenerud wrote: post #3

I'm not sure I understand why late binding and Alan Kay style messaging is desirable. If you send a message to something that's supposed to do a task, and it just ignores your message because it was the wrong type or whatever, how are you supposed to debug that, or reason about the correctness of your program at all?

Have successfully completed tasks call home to mama. No call no work. Easy.

Alan Kay and fellow minded et al. are looking at Biology and to an extent Physics as the successful approach to pervasive computation at large.

It is the desirable feature set of the biological organism that informs that perspective: self-healing, self-regulating, regenerative systems operating in an open-ended operational context.

So that is the holy grail. Or at least one of them. Clearly biological systems can do all that. Can we do this with software? That's what Alan Kay wants us to find out.

Re: Alan Kay and OO Programming

#33

Post by pleasecalllater »

cryptica wrote: post #21

>> Extreme late-binding is important because Kay argues that it permits you to not commit too early to the "one true way" of solving an issue (and thus makes it easier to change those decisions), but can also allow you to build systems that you can change while they are still running! >> Binding can also refer to binding a variable type to data. As someone who has over 15 years of experience going back and forth betw…

Focusing on integration tests: oh, the test fails, something is wrong somewhere... I will debug all layers for the next week, as we simply don't have too many tests covering the internal code.

I like to have both.

Re: Alan Kay and OO Programming

#34

Post by contingencies »

jasode wrote: post #18

>, he realized that while software routinely has trouble scaling, cells can easily coordinate and scale by a factor of over a trillion, creating some of the most fantastically complex things in existence, capable of correcting their own errors. By comparison, the most sophisticated computer software programs are slow, tiny, bugfests. Kay's conception of OOP starts with a single question: how can we get our software t…

An insightful and well illustrated perspective.

Re: Alan Kay and OO Programming

#35

Post by jackcviers3 »

kstenerud wrote: post #3

I'm not sure I understand why late binding and Alan Kay style messaging is desirable. If you send a message to something that's supposed to do a task, and it just ignores your message because it was the wrong type or whatever, how are you supposed to debug that, or reason about the correctness of your program at all?

You aren't. You don't have a "program." You have millions of tiny isolated processes that can send messages to one another. Since you cannot observe the state of any process from the outside, and cannot tell if it has failed or not, you have to rely on other things (think tcp/network protocols) to indicate message reception and processing.

You can reason about your protocols, as they have an algorithm. But your object graph as an entire entity is a bunch of black boxes with very few observable properties about which to reason, or indeed even need to in the world of isolation.

Re: Alan Kay and OO Programming

#36

Post by walterstucco »

kstenerud wrote: post #3

I'm not sure I understand why late binding and Alan Kay style messaging is desirable. If you send a message to something that's supposed to do a task, and it just ignores your message because it was the wrong type or whatever, how are you supposed to debug that, or reason about the correctness of your program at all?

Tracing.

BTW that's how Erlang works and it's much easier to debug than many other languages I used

Tooling is important

Re: Alan Kay and OO Programming

#37

Post by jondubois »

pleasecalllater wrote: post #33
cryptica wrote: post #21

>> Extreme late-binding is important because Kay argues that it permits you to not commit too early to the "one true way" of solving an issue (and thus makes it easier to change those decisions), but can also allow you to build systems that you can change while they are still running! >> Binding can also refer to binding a variable type to data. As someone who has over 15 years of experience going back and forth betw…

Focusing on integration tests: oh, the test fails, something is wrong somewhere... I will debug all layers for the next week, as we simply don't have too many tests covering the internal code. I like to have both.

Why next week? Why not use the integration tests as part of your debug cycle now? The kinds of integration tests that I write only take a few milliseconds to run so if they fail I can just make a code change (or add a new breakpoint or log), then run again, then repeat. The flow should not be any different from doing TDD with unit tests. Note that integration tests don't necessarily have to be end-to-end; the point is more that each test case should cover a specific behavior.

Re: Alan Kay and OO Programming

#38

Post by adwn »

jondubois wrote: post #37
pleasecalllater wrote: post #33

Earlier quoted context omitted.

Focusing on integration tests: oh, the test fails, something is wrong somewhere... I will debug all layers for the next week, as we simply don't have too many tests covering the internal code. I like to have both.

Why next week? Why not use the integration tests as part of your debug cycle now? The kinds of integration tests that I write only take a few milliseconds to run so if they fail I can just make a code change (or add a new breakpoint or log), then run again, then repeat. The flow should not be any different from doing TDD with unit tests. Note that integration tests don't necessarily have to be end-to-end; the point i…

> Why next week?

I think pleasecalllater's point is that without unit tests, you'll spend a lot of time just pinpointing the bug, since it could be anywhere in your module (which unit tests would cover), not just at the interface to other modules (which integration tests cover).

Re: Alan Kay and OO Programming

#39

Post by nudq »

Ovid wrote: post #25
nudq wrote: post #22

https://lobste.rs/s/8yohqt/alan_kay_oo_programming#c_5xo7on >> He doesn’t have random opinions about “objects”, he invented the word > Kay did not invent the term “object”.

Alan Kay says he did. "I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea." Source: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...

> Alan Kay says he did

How sad if true! I'm reserving the right to think you misunderstood what he was trying to say there.

Re: Alan Kay and OO Programming

#40

Post by coldtea »

jondubois wrote: post #37
pleasecalllater wrote: post #33

Earlier quoted context omitted.

Focusing on integration tests: oh, the test fails, something is wrong somewhere... I will debug all layers for the next week, as we simply don't have too many tests covering the internal code. I like to have both.

Why next week? Why not use the integration tests as part of your debug cycle now? The kinds of integration tests that I write only take a few milliseconds to run so if they fail I can just make a code change (or add a new breakpoint or log), then run again, then repeat. The flow should not be any different from doing TDD with unit tests. Note that integration tests don't necessarily have to be end-to-end; the point i…

>The kinds of integration tests that I write only take a few milliseconds to run

So your codebase probably doesn't solve the problems and use the stacks most of us solve/use.

Post reply on HN