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

131–140 of 141 posts

Re: Alan Kay and OO Programming

#131

Post by anoncake »

cryptica wrote: post #109
dnautics wrote: post #85

Earlier quoted context omitted.

> Dynamic languages let you think a problem you haven't thought of at design time will somehow solve itself magically at runtime, using components designed weeks before, with knowledge of that time. I don't think most people who program in dynamically typed languages believe that. However there are people in the extreme that believe that static typing will save you from errors. Sometimes I worry that the cognitive ov…

I've had several experiences where static typing forced my hand into making a software design decision which I later regretted. Many real-world entities don't have a fixed set of characteristics/properties; instead, they have fluid characteristics that can change over time. Trying to model those entities using static types which have a fixed/static set of properties is a bad idea. For example, in nature, a tadpole mi…

> What type is the creature if it's exactly halfway between being a Tadpole and a Frog?

It's an animal. The type checker will make sure you don't try to water() it. Static typing does not have to mean infinitely granular typing (though of course typing everything "statically" as any is pointless).

Re: Alan Kay and OO Programming

#132

Post by golergka »

ergothus wrote: post #120
bsaul wrote: post #118

Earlier quoted context omitted.

Ok so what is the benefit of dynamic / runtime binding, then ? Isn’t it to reach potential combination of components talking together in ways you couldn’t (or didn’t want to) anticipate at compile time ?

Your comment feels very aggressive and uninterested in actual debate. My primary benefit is not spending the time telling the computer things it should already know. Dev time is the most limited resource, I prefer not to spend it restating the obvious. And yes, sometimes this restatement could be complex to express. The biggest benefit I see most static typing advocates benefiting from is IDE-hints, not compile-time…

> My primary benefit is not spending the time telling the computer things it should already know.

Sounds like you're in favour of type inference, not dynamic typing. A lot of statically typed languages don't need you to type out type declarations of your functions.

> Dev time is the most limited resource, I prefer not to spend it restating the obvious.

But on a typical dev job, you spend 10 times more reading code than writing it. And when you read, these type declarations actually save your time.

> The biggest benefit I see most static typing advocates benefiting from is IDE-hints, not compile-time checking.

Uhm, no? I'm pretty sure it's about the guarantees that compiled languages give you - the more invariants, the better. The same logic as with immutability.

Re: Alan Kay and OO Programming

#133

Post by tomaskafka »

megous wrote: post #13
kstenerud wrote: post #10

Earlier quoted context omitted.

OK, I must be missing something fundamental, then. Let's say you want to take payment and ship a product. You send a message that payment of X is needed. And... nothing happens because the component that handles that isn't listening for whatever reason. Do you wait for a message saying payment was posted? How long do you wait? What about the UI? How long does the customer wait? It seems like a messaging system like t…

Message sending function can block until timeout or response is received.

How is timeout and sending message without knowing how it was handled different?

Re: Alan Kay and OO Programming

#134

Post by fnord77 »

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

> As someone who has over 15 years of experience going back and forth between statically typed and dynamically typed programming languages I have >20, in a mix of dynamic and statically typed languages. I've even designed a few of both including some that straddle the line. > It's a shame to see the new generation of developers moving back to statically typed languages It's only a shame if you presume to know better…

> Personally, I trust that in the aggregate, developers aren't dumb and do understand their own pain points and solutions even when the pain and solutions aren't obvious to me.

Not saying you're wrong on your other points, but "Wisdom of the crowd" is a logical fallacy.

plenty of examples where developers as a group followed some line of bad practices for years until someone smart managed to "steer the elephant" in a better direction.

Re: Alan Kay and OO Programming

#135

Post by discreteevent »

GorgeRonde wrote: post #61

What is late binding of everything ? To me it's a bit like doing the opposite of what macros in Lisp do, but to do it during run-time rather than compile-time. Take Ruby for instance (which is interpreted in its standard implementation). You can define methods at runtime and 'keywords' that allow you to define new methods are methods as well. As a result you can extend the more "static" part of the language, adding n…

Late binding to me means late binding of the implementation, not the interface/protocol. So the discussion above about static vs dynamic languages is orthogonal. You can do it in either. In the example at the end of the article the protocol is that you give the shopper object a budget and a list of things to buy. But you could replace the implementation (late-bound) for one that does machine learning to optimise the result for cost or quality without changing the interface.

Re: Alan Kay and OO Programming

#136

Post by golergka »

mpweiher wrote: post #45
coldtea wrote: post #40

Earlier quoted context omitted.

> 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 project…

How many external build systems and proprietary closed source tech do you have to yous to build your project and run integration tests on it? In my case, full production build that produces the same library takes about 30 minutes using asset cache: re-building everything completely from scratch would take about two hours.

Re: Alan Kay and OO Programming

#137

Post by senderista »

carlmr wrote: post #44
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 y…

The GoF book was written for Smalltalk and C++, so the limitations that compel the invention of design patterns clearly apply to Kay’s own language as well.

Re: Alan Kay and OO Programming

#138

Post by walterstucco »

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…

This is interesting, but look at it this way: you're talking about a society, Kay is talking about cells

As society we achieve extreme late binding by communicating with each other. We even invented ways to make it possible when it's physically impossible (phones, internet, etc.)

At a smaller scale, our body work because our internal organs achieve late binding by sending each other messages via buses, the blood stream and nervous system.

At even smaller scale it works the same way: cells communicate to each other using chemical messages

In software development we have solved only the problem on a large scale, using network protocols, but we are still building organs and cells in various ways, most of them wrong and inefficient

Re: Alan Kay and OO Programming

#139

Post by megous »

tomaskafka wrote: post #133
megous wrote: post #13

Earlier quoted context omitted.

Message sending function can block until timeout or response is received.

How is timeout and sending message without knowing how it was handled different?

Have you programmed anything on the web? fetch() has interface just like that.

Re: Alan Kay and OO Programming

#140

Post by vidarh »

adwn wrote: post #14
vidarh wrote: post #12

Earlier quoted context omitted.

That is not the point. The point is having the ability to fully control how to react to a message. Sometimes just ignoring certain messages is fine: You might slot in an object as a sink to log certain messages and not care about others. Other times you want to be able to do things like delegate certain subsets of messages to other objects without having to know the precise set of messages in the sender or ultimate r…

That sounds great for a quick & dirty prototype, or for debugging and testing. But it would be an absolute nightmare for building and maintaining large-scale projects.

On the contrary. It's fantastic on large-scale projects in part because it keeps them much smaller.

I think you're picturing just losing messages, but that is not what happens unless you explicitly design a system to randomly drop messages. The reality is a system where by default you'll typically still get exceptions if you call something that does not exist (and in production use, the stack traces from those exceptions likely ends up somewhere like Bugsnag), but where you can selectively override what happens and e.g. redirect messages somewhere else. If someone sends a message that truly can not be handled, we'll still throw exceptions.

But that flexibility means you save a massive amount of boilerplate. When I switched from C++ to Ruby, that was a major driver - I'd spent years doing meta-programming using templates, and was dimissive of dynamic typing. Until I tried it and realized that for the pitfalls it has, the amount of ceremony and boilerplate that was cut was astounding.

I write all my code in a homegrown editor these days. It uses Drb to split the UI frontend with a server that holds all open buffers. Drb is a Ruby RPC library that uses the ability to intercept all messages to dynamically create proxy objects that serialize calls over the network connection. Because we can do that, it's almost entirely transparent and no custom code whatsoever needs to be written.

If the server side throws an exception, by client catches it and throws me into a REPL (or it could have dumped state and exited if I preferred). Messages don't get randomly lost, even though the client side objects have no idea what the actual interfaces of the server side objects are.

Post reply on HN