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

41–50 of 141 posts

Re: Alan Kay and OO Programming

#41

Post by doboyy »

unimpressive wrote: post #6
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...

>Surely our concept of objects and OOD can't be that bad How would you know if it were?

Because software isn't as cooperative and scalable as Alan Kay says. We are getting better at this, but probably at a painstakingly slower rate than he would like.

Re: Alan Kay and OO Programming

#43

Post by carlmr »

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...

There are actually two languages (aside from Smalltalk) I know that are very close to Alan Kay's idea of message passing objects (as I understand it). Those are elixir and erlang.

They're usually regarded as functional languages, but they have message passing actor model at their core. It might not be the best for everything, but they definitely are very good in their niche of embarassingly parallel computation.

Re: Alan Kay and OO Programming

#44

Post by carlmr »

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…

>Instead of using the "message bus" of Smalltalk or Objective-C's "objc_msgSend()", the world has decided to express the evolution of software via multiple programming languages and runtimes and by the mechanism of software updates instead of depending on a single language ecosystem like Smalltalk to write a metaphoric cell biology system to evolve itself.

I find your post very insightful. I'd just like to add that you have that kind of message passing in Elixir and Erlang, and they also support hotswapping code. So the idea didn't completely lose in the marketplace of ideas. It did lose the war for the name OOP though.

I'm not a fan of what we understand as OOP today either, just looking at the GoF book should make you think whether you want to work in the model that makes all this necessary. So I kind of understand Alan Kay. I just think calling Elixir an actor based functional language is just as good to me.

Re: Alan Kay and OO Programming

#45

Post by mpweiher »

coldtea wrote: post #40
jondubois wrote: post #37

Earlier quoted context omitted.

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.

> your codebase doesn't solve the problems most of us solve

Why not?

> and use the stacks most of us use

Probably. Or at least not use them the same way.

I am consistently amazed by the time even unit tests take when I join projects. If they have them.

And those unit tests are usually also at least part broken and very incomplete. I would argue those phenomena are closely related.

The unit tests for one of my projects typically run in the ~1 second range, meaning that I can, and do, run them as part of the build process. A build is not complete until the unit tests pass.

This includes Postscript/PDF interpreters, so it's not just testing completely trivial stuff.

(Just checked: currently 3.9s real for 1498 tests across 9 projects, so a bit on the slow side overall)

Re: Alan Kay and OO Programming

#46

Post by [deleted] »

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…

[deleted]

Re: Alan Kay and OO Programming

#47

Post by mpweiher »

mirsadm wrote: post #27
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?

In my experience silent failure leads to some of most difficult to debug systems that end up in a not quite right state. Fail as early as possible has always worked better for me, bugs are found much earlier.

Things are different in-the-small vs. in-the-large.

You can't statically typecheck the internet. Oh, and no-one said the failure needs to be silent.

Re: Alan Kay and OO Programming

#48

Post by armitron »

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

I'm a fresh graduate from uni so I'd say that I don't have that much experience. My last years working on the side of studies using Python really made me prefer strongly typed languages like Haskell, Rust, Elm etc. My experience is that the compiler almost always finds my small errors and would-be-bugs which Python exposes at runtime (crashes with e.g. None-type errors). What would you say the benefits are with dynam…

The article explains (very well) what the benefits of dynamic typing are, it's just that Python is a terrible language that spits in the face of Alan Kay's ideas. It's like someone went out of their way to create a language that would not be too paradigm shifting by discarding the crucial elements that Alan Kay keeps raving about and only choosing the most superficial with the only consideration being ease of use and popular appeal.

Try programming in Erlang, Common Lisp or Smalltalk. All dynamically typed languages. All meshing perfectly with Alan Kay's vision. All very different to Python. It's too bad that people's idea of "dynamic typing" has been - mostly - reduced down to Python and Javascript.

Re: Alan Kay and OO Programming

#49

Post by jondubois »

adwn wrote: post #38
jondubois wrote: post #37

Earlier quoted context omitted.

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).

That's not my experience. Usually it only takes me a few minutes to fix a bug once it has been caught by an integration test.

Re: Alan Kay and OO Programming

#50

Post by pleasecalllater »

jondubois wrote: post #49
adwn wrote: post #38

Earlier quoted context omitted.

> 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).

That's not my experience. Usually it only takes me a few minutes to fix a bug once it has been caught by an integration test.

Depends on your system. Mine usually are huge. The integration test showing "this json reply is wrong" doesn't tell me anything else than I have to dig through all the layers.
Post reply on HN