Earlier quoted context omitted.
Prototypical inheritance has caused so many, many vulnerabilities...
How so? Never heard this perspective. Is it substantially more than reflection?
Squeak 6.1
121–130 of 153 posts
Re: Squeak 6.1
#122Earlier quoted context omitted.
I'm also interested in this and made decent progress on a git-style content addressed image where everything is identified by hash and residency determines what's in memory. For example, there's a filesystem on the image that works this way and you can page over the "cold" non-resident bytes for very large files that you would not want to hold in memory. You don't persist the state of the full image continuously to t…
Sounds like you would find NixOS and/or Unison interesting!
Yes, big fan of Unison (the system I described above follows its model for code hash identity) and I use a NixOS machine for most of my software work!
Re: Squeak 6.1
#123And after all these years, still no fixes for high-DPI displays. The UI is still pixely and slow. Perhaps I should take Fable and try myself, this was the only bug I cared about and it is not solved after 10 years at least.
yeah, after all these years, they are waiting for your contribution. you really should go at it with Fable.
Re: Squeak 6.1
#124Smalltalk'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".
Re: Squeak 6.1
#125Earlier quoted context omitted.
Wouldn't you just do elixir now? It's like erlang but even wilder. I think smalltalk and erlang are so interesting because they model the idea of small computers so differently. Lisp just feels like the purest way to understand what the units of a programming language really is.
For me, Elixir misses the mark. If you're an unc with a background in Ruby or that era of webdev, I can see the appeal. It's a familiar set dressing. I don't have that background, I much prefer the syntactic structure of Erlang's psuedo-horn clauses. Both for similar familiarity reasons (I knew Prolog before I touched Erlang), as well as a general preference for the simplicity.
> If you're an unc with a background in Ruby or that era of webdev
"claude, run 'npm install' for me"
Re: Squeak 6.1
#126Earlier quoted context omitted.
I find that lamentation a bit funny, because the list in practice is never really complete. For instance, you forgot the mighty Prolog. Surely, tcl belongs on there too.
I blame the unknown unknowns. I don’t haven’t learned Prolog yet. Alas, enlightenment still eludes me. (Agreed that TCL is pretty cool)
If I have to describe the feeling is that you'll realize that computation is symbolic manipulation (yes, it is obvious, but quite difficult to be fluent in it). With C and the likes you're too close to the machinery to easily grasp symbolic manipulation. But with other paradigms like lisp, prolog, oop with smalltalk,... you start learning how to design solutions in terms of symbols and their manipulations instead of values and concrete actions.
Once you start doing that, you move a ladder up in problem solving, where you solve class of problems instead of specific instances.
Re: Squeak 6.1
#127Smalltalk'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 understan…
> 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.
https://docs.swift.org/swift-book/documentation/the-swift-pr...
Re: Squeak 6.1
#128Smalltalk'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 understan…
> 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? https://docs.swift.org/swift-book/documentation/the-swift-pr...
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.
Re: Squeak 6.1
#129Earlier quoted context omitted.
The only mainstream-ish language where that still happens? R. Too bad, there's a lot more use cases for this sort of thing now - versioning, anything non-persistent agents touch, collaboration, auditable enterprise LOB. It's 2026, why are we (or our agents) still writing serialization code? Even if the AI's write the boilerplate, the state management fragility is often a tax/risk.
You could argue that a Claude code session also works like a lisp/smalltalk image.
I fail to see it. But that could really be me. Could you explain how?
Re: Squeak 6.1
#130Just like learning Lisp will make you rethink programming languages, and learning Erlang will make you understand the true power of concurrency: learning Smalltalk will make you understand what "object oriented" actually means. I haven't used Squeak since college but I'm glad it was part of the cirriculum. Btw, almost all of Javascript's good parts come from Smalltalk.
Lisp, Forth, Erlang, Smalltalk, and Rebol, so easily forgotten. All languages that multiply your insight into the nature of computer programming. A bit sad that many just stop at the first of these, and many more don’t even venture past their Pythons and Javascripts.
Favorited and commenting on this so I can get back to this :)