I've always liked and preferred Safari. The only reason I moved away was that as a Mac gets older, there comes a point where you can't update the OS, and that means Safari falls behind. Even that's not a problem for me, but web standards were always changing and after a while certain things won't work.
Am I the only one surprised that Anthropic isn't more interested in allowing a full range of behaviors for information gathering purposes? You can't learn about cruelty if you're suppressing it, and you can't learn about people's behavior if their behavior is constrained to a tight set of rules that doesn't allow criticism. The younger generation today seems really into judging people, blaming people, and insisting on conforming to superficial behavior rules, while at the same time having very little curiosity about why things are the way they are - why are people cruel anyway? If it's bad, why do people act that way.
Anthropic might learn, for example, that a large part of the cruelty is a reaction to something the AI is doing or not doing. Not possible?
One of the things I'm often curious about is how various BASIC interpreters organize memory for string storage. You'd think there's some way to reclaim memory after an expression involving intermediate strings is finished. But you don't see descriptions for how BASIC works in this regard.
Smalltalk's been enormously influential and successful... There is however a better way of understanding objects. Namely, "objects" are [defined to be] processes, "messages" are asynchronous, and Smalltalk's message invocations are indirect function calls. I know what you're thinking: "But no OO PL works like that. You won't understand anything that way." That's true: this suggested reframing won't help you understand any popular OO language, because they use indirect function calls instead of asynchronous message passing.
The indirect function calls of Smalltalk don't transform the semantics of programming. It's still data structures and algorithms. You can, if you adopt Kay's ideas wholesale, write programs where individual letters in a text typeset themselves (as Kay describes). I'm arguing that that model of programming is more accurately articulated in an async message passing frame.
Smalltalk's function calls do have an important benefit, which is polysemy. I'm stealing that word and not using it quite right. The benefit is you can define ideas that are not algorithmic. You can for instance define many methods for LOOKUP(key,table) that works for many data structures, and now you've defined not a recipe, but an idea that transcends recipes. Any recipe R that uses LOOKUP automatically works with all the data structures that LOOKUP works with, even though R itself may be a specific recipe for a specific data structure of its own.
That's a tremendous benefit, and it's worth using OO features to take advantage. But even so you're still living in an algorithms and data structures world. Polysemy is a linguistic feature and does not cause a mechanical or paradigmatic change.
Asynchronous messaging however does change how algorithms are designed, in much the way that Alan Kay anticipated, and also in a way that models real world entities in direct fashion. But everyone understands this part already.
So how is this a "better" way of thinking about objects? 1) It emphasizes the advantage of polysemy, which in my experience OO pedagogy tends to overlook, even though most everyone utilizes OO partly for that purpose; 2) It explains why OO programs remain organized as algorithms and data structures; and 3) it welcomes combining "object" techniques with A & DS techniques in the same program or function or even the same line of code. They are completely compatible, in the sense that the language or library or database is not "OO" or "non-OO".
> Any recipe R that uses LOOKUP automatically works with all the data structures that LOOKUP works with, even though R itself may be a specific recipe for a specific data structure of its own.
this seems similar to protocol extensions + associated types as used in swift maybe?
Yes. I don't know Swift, but it appears that Swift's protocol and class are similar to Java's interface and implementation (class), and defining a protocol would be required in Swift in order to define a generic table.LOOKUP(key) operator.
