13 ms·
Alan Kay: Smalltalk is not about objects, it’s about messaging (1998)
- thdrdt 7y agoThere are so many models based on the ideas of Kay. But I got the feeling that the actor model (Carl Hewitt) is closest to what Kay meant. Am I right?
- jghn 7y agoI can't find the quote online so this could easily be apocrypha or something I made up in my head, but I could have sworn Alan Kay has said as much along the way.
- anaphor 7y agoThere's a quote from Joe Armstrong saying something like that > As Erlang became popular we were often asked "Is Erlang OO" - well, of course the true answer was "No of course not" - but we didn't to say this out loud - so we invented a serious of ingenious ways of answering the question that were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot) but not really (If you listened to what we actually said, and read the small print carefully). https://stackoverflow.com/a/11809324/903589 https://stackoverflow.com/a/11809324/903589
- trevyn 7y ago>If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money. Oof.
- mathgladiator 7y agoI think so, I'm accidentally building an actor centric programming language and it is a magical way of building stuff.
- bsaul 7y agohow do you handle persistence ? i’m trying to design a system at the moment and i feel like actors are great until you have to deal with persisting state to a database ( at which point the idea of having millions of independant process each hitting your database to save and load their state look like a disaster) edit : i misread your post, thought you were designing a system, not a PL... maybe you can still answer my question ?
- pmontra 7y agoYou should check how Erlang / Elixir database drivers handle that. In my experience with Elixir there are never many processes that have a state to save in a database. Eventually it's the same load no matter if the implementation is actor based or object oriented.
- bsaul 7y agobut then how do you deal with transactionnal behaviors ?
- pmontra 7y agoCheck Elixir's Ecto module https://hexdocs.pm/ecto/Ecto.html https://hexdocs.pm/ecto/Ecto.html The general idea is to build the transaction in a pipeline of function calls. Each function gets the old definition of the transaction as an argument and returns a new one. Eventually the call at the end of the pipeline executes the statements in the definition, wrapping them in a transaction. If the question is how to deal with 100 or 100 k concurrent transactions, the answer again is in the same way a cluster of servers running programs written in any other language do. Eventually SQL is SQL.
- verttii 7y agoThat's not how you would persist to the database. Processes (Erlang VM threads) have mailboxes that process messages (like records to be saved to db) in a queue. Everything is built around message passing, each process just handles its own narrow job.
- pgt 7y agoYes. Erlang probably bears out the actor model best, although there are many library implementations in various languages.
- dnautics 7y agoYes and no. Carl hewit will tell you that erlang's actor model is not pure (and to be sure a process doesn't have to be much of an actor - like Elixir's Task module). But I think that impurity is one of the strengths of the BEAM. So I would qualify 'best' to meant "easiest system that 95% looks like actors that you can quickly get up and running and doing useful things and or play around with"
- anaphor 7y agoE (http://erights.org/ http://erights.org/), Monte (https://www.monte-language.org/ https://www.monte-language.org/), and Pony (https://www.ponylang.io/ https://www.ponylang.io/) are probably the most faithful actor-model languages I know of.
- ProfHewitt 7y agoAbove are important contributions, but they don't provide an adequate foundation for Actor massive concurrency.
- dualogy 7y agoAny others around today that do?
- ProfHewitt 7y agoThe Actor Model has been used in many important large applications [Bernstein, Bykov, Geller, Kliot, and Thelin 2014; Bonér and Reisz 2017, Cesarini 2019] and has become the foundation for current computing. Satisfactory implementation for Reusable Scalable Intelligent Systems with millions of Actor cores for quadrillions of Actor are under development, but not yet publicly available.
- goofballlogic 7y agoThat had been my conclusions over the years. Erlang (or Elixir) are ironically one of the nicest environments for OO code these days (given they are usually categorized as "functional")
- nailer 7y agoThe YC ideation talk with Alan Kay has a small rant from Alan about what he meant with Objects, and how that isn't what objects are used for now. What he described sounds exactly like the actor model.
- madhadron 7y agoHe explicitly credited the actor model as one of the major influences on Smalltalk and OOP. The distinction as far as I have been able to tease it out is that in the actor model there is a distinction in kind between actors and values passed among actors. In OOP, there is no distinction in kind, that is, imagine you have an actor-like thing that sends you a reference to something, but that something is going to be of the same category of actor-like thing.
- abecedarius 7y agoHewitt created actors after hearing an early Smalltalk talk by Kay at MIT, as I recall it. That wasn't the only influence (capabilities were a big one, for instance) and I'd be surprised if there wasn't reciprocal influence, though. In Hewitt's actor model, messages are also (immutable) actors. At least in the early version I read about.
- ProfHewitt 7y agoActors were developed to unify and overcome limitations of previous important contributions including lambda calculus [Church 1932] (first-class procedures), Petri nets [Petri 1962] (true concurrency), semaphores [Dijkstra 1962-1963], packet switching [Baran 1964] (concurrent communication between computers using fixed size packets), capabilities [Dennis and van Horn 1966] (pointer security), Simula [Dahl and Nygaard 1967] (class hierarchy), and SmallTalk-72 [Goldberg and Kay 1976] (bit-mapped computer graphics and browser, the precursor of modern programming Integrated Development Environments). The lambda calculus could not express concurrency with the consequence that lambda calculus programs can be thousands of times slower than Actors. A Petri net cannot dynamically expand and has the limitation that tokens can miraculously disappear from different places, which is inefficient to implement. Capabilities have the limitation that pointers must be manipulated using indexes into capability lists thereby making programming awkward. Simula did not implement concurrency and did not have messages. SmallTalk-72 used a byte stream of program tokens thereby making it awkward for concurrency. See the following for more information: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003
- kitd 7y agoThe way messages are constructed in Smalltalk is one of its delightful features. It seems so obvious to 'template' a message with the replaceable parts being the parameters. Typical methods a la C++ or Java look so clumsy in comparison. It would be nice if there was a way to construct something similar around actor-based systems on the JVM.
- steveeq1 7y agoYou can, it's called "erlang".
- jacquesm 7y agoErlang is not running on top of the JVM but on top of its own VM (BEAM). There have been some attempts to get Erlang running on the JVM but so far none that really made it worth adopting, and frankly I don't see how you could do it without losing everything that makes Erlang/OTP special.
- senderista 7y agoI’m very disappointed when I see new languages (cough Rust) not even consider named arguments. The added readability at call sites just seems like a no-brainer to me.
- inertiatic 7y agoIt should be easy to implement on a modern IDE, right? I think intellij exposes a setting for example.
- simias 7y agoThe only counter-argument I've heard was that it has the consequence of making the argument name part of the API (i.e. changing the name would be a breaking change, so all parameter names of exported functions "leak" into the public interface). That always seemed like a very minor drawback to me, I too would appreciate to have named arguments in Rust.
- paulcole 7y agoAs a dev, I grok that smalltalk is all about messaging but I find that it bores me to discuss the trivialities of sportsball with marketing or business people.
- grzm 7y ago> but I find that it bores me to discuss the trivialities Then don't. There are plenty of other submissions on HN, and if you don't see any you find worth discussing, submit some you do.
- paulcole 7y agoI see I’m not the only one who didn’t read the article!
- coldtea 7y agoMany people here have read the same case (OO as intended by AK and Smalltalk being not about Objects but about messaging) made in different outlets from Alan Kay over the years (I've read it over 10 times in various forms, including 2-3 videos). It has also been posted on HN for over 10 times, and a few times Alan Kay himself was commenting here too. So it's not like everybody needs to read this particular "TFA" to jump into the discussion, or that it's that bad if they missed some specific reference you've made to the content of this particular article...
- bjornjaja 7y agoDoes anyone know how this would relate to Qt signals/slots?
- adamnemecek 7y agoIt's about messaging and also loose coupling, referentiality, resources etc. It's about being able to reference by some reference(UUID) rather than by values. This idea gives rise to contexts. It's the difference between graphs and trees. It's the difference between linear logic and classical logic. In some sense, heap allocated objects work like this. The main problem is that you can't relocate objects. Rust's interior mutability is about this as well. ECS[0] is about this. https://en.wikipedia.org/wiki/Entity_component_system https://en.wikipedia.org/wiki/Entity_component_system
- noughtme 7y agoEvery time this comes up it makes me want to learn Smalltalk, but the current tooling/IDEs don’t seem to have been kept up to date. Is it possible to learn Smalltalk without a Smalltalk-specific IDE? Or, is there a relatively small current language that is similar to Smalltalk?
- mark_l_watson 7y agoWhoa, hold your horses! Pharo is a modern open source Smalltalk that was derived from Squeak. Nice UI, vibrant ecosystem and community. https://pharo.org/ https://pharo.org/
- jchw 7y agoInstantly was enticed by this, but quickly ran into the depths. I'm on NixOS unstable and I realize this is not ever going to be a well-supported place to be in terms of running random software, but thankfully there are in fact Pharo attributes in nixpkgs. Sadly though, I can't figure out how to use it. It looks like I want to start with Pharo Launcher, so I've installed the Pharo VM and Pharo Launcher, but when I try to start Pharo Launcher a window pops up and it just exists. All I can see in the terminal is a message about pthread_setschedparam failing, which does not seem fatal. I wonder whether my problem is with not understanding what I'm doing, or with NixOS, or something in between...
- e12e 7y agoDid you try the zip from here? http://pharo.org/download http://pharo.org/download I'd guess you could get some hints by running ldd on the vm (I'm assuming it's not strictly a static binary). You need the vm and an image - the launcher I imagine is a vm and just enough image to display a menu and get a "proper" image downloaded.
- jchw 7y agoI have the VM seemingly working through the NixOS package, and if I run the Pharo image downloaded from there, it seems to show a window with nothing on it but a menu item labelled "Pharo" that does nothing. Perhaps I'm missing something but I doubt the Linux VM download on that page will help me. Ordinary binaries don't tend to run on NixOS without at least some ELF patching due to the Nix store architecture.
- Animats 7y agoNah. It's about objects. Messaging is when you send a message off to the vasty deep and hope for a reply. A Smalltalk message is a function call that has to return. Most of the issues around messaging come from waiting for answers. Hence callbacks, futures, async, retries, timeouts... Good discussion of this back in 2012.[1] [1] https://news.ycombinator.com/item?id=4788926 https://news.ycombinator.com/item?id=4788926
- lonelappde 7y agoI think Alan Kay knows what Smalltalk is about. He uses messaging to mean interfaces and protocols of communication.
- Animats 7y agoRanks of "Message oriented": Rank 1: Polymorphism. You can "send" a message to an object. You don't know or care exactly what the object does. Other than the polymorphism, the "message" behaves just like a function call. It will definitely be handled by your target object, and it will definitely return instantly with a response. The compiler might even be able to inline this function call. As seen in: Pretty much every OOP language. Rank 2: Messages as first-class values. It's possible to write a function that forwards all incoming messages to another object, based on some logic. The caller does not know what will happen to the message. However, the message can be expected to be handled instantly, and it may respond instantly (if it does have a response). As seen in: Objective-C, Smalltalk Rank 3: Asynchronous messaging. When sending an outgoing message, it might be placed in a queue and handled at a later date. The message does not return a result instantly, so agents must have some other mechanism (such as including a "reply to" address) to be able to talk back and forth. From the perspective of the caller, it's a bit like putting a message in a bottle and watching it drift off to sea. As seen in: Erlang, message queueing libraries.[1] “When I use a word,” Humpty Dumpty said, in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.” “The question is,” said Alice, “whether you can make words mean so many different things.” “The question is,” said Humpty Dumpty, “which is to be master—that’s all.” [1] https://news.ycombinator.com/item?id=4788926 https://news.ycombinator.com/item?id=4788926
- matchagaucho 7y agoPassing a single, immutable object as a parameter to a method, and replacing several native parameters, is a common "what-if" comment I make in code reviews. It's not 100% the intention of Smalltalk messaging, but it's in the spirit of "objects as messages".
- derefr 7y agoI think the key insight of Smalltalk can be grasped just by thinking about how Smalltalk does branching. A line from the GNU Smalltalk tutorial: mybool ifTrue: [ ^ 2 / 4 roundup ] The outer part of this expression reads “send a closure expression, as the message ifTrue, to the receiver mybool.” Keep in mind, this `mybool` could be anything! It just so happens that there are two runtime objects, `true` and `false`, that satisfy the “Boolean interface” (consisting of messages ifTrue and ifFalse) the way you’d expect—with `true` running any closure passed in an ifTrue message, and `false` running any closure passed in an ifFalse message. (For those of you who know combinatory logic, these objects are essentially the K and SK combinators.) But consider that you can create your own object that implements this interface—with whatever arbitrary logic you like—and substitute it for a Boolean as the value of `mybool`, and no code will be able to tell the difference. This is what is meant by “computation as messaging.” Branching is a request to an opaque “branch-evaluating object.” At each step of computation, you’re not getting the runtime to compute—you’re getting your objects to compute. The objects are the computers, and the messages are the instructions to those computers!
- golergka 7y agoThat sounds very interesting. How are return values treated under this model, though? Is the object you send the message to obligated to send something back, synchronously?
- AllegedAlec 7y agoBy default, each message call returns the result of the last expression. the ' ^ something ' syntax is used to explicitly return a value.
- galaxyLogic 7y agoBut the object responding to a message can also "reply later" if one or more of the arguments of the message are "blocks" which are function-like objects created by the sender, having access to variables in the context of the sender. The recipient of a block can call it any time in the future, including multiple times.
- mntmoss 7y agoSomething I have gotten more attuned to over time is the importance of the message format - i.e. the medium - in defining the message. That is, the way in which the message is specified changes the classes of errors and development challenges one might encounter. If function arguments are positional you get positional errors; if they are named you enter the business of defining many more types. Messages may return a different version of themselves(e.g. arithmetic) or a different category of message. The later in time the message is delivered, the more it has to carry around its own context. And when a message has unbounded scope it has unbounded complexity. And like with a lot of things, there aren't silver bullets. Many things can be defined as a single enumerated value. Sometimes tuples are nice, sometimes records are nice. Sometimes the problem expands to the point where you have to have a message with a little computer inside it - but when that happens it's usually not for the purpose of any specific task, it's to add a layer of programmability into the system.
- rektide 7y agoLovely post! Here here! I've toss in cap'n'proto & surely others who let you write messages that talk about still outstanding messages. Still short of referring to full on streams in your messaging. https://capnproto.org/rpc.html https://capnproto.org/rpc.html There's hx-uri that allows for referring to other http messages, which I think could fulfill this in http. https://github.com/martinthomson/hx-uri https://github.com/martinthomson/hx-uri Here's to expanding the medium! Let the hypertext ever hyper.
- DonHopkins 7y agoThanks for pointing that out! I'd heard of Cap'n'Proto but didn't realize how cool it was. Pipelining promises is incredibly useful! I'll check it out more deeply now. When I first heard of it, maybe I was initially skeptical because of the name, having been traumatized years ago by Cap'n Software Forth on my Apple ][, which John Draper developed to implement SleazyWriter while incarcerated in the Alameda County Jail. https://archive.org/details/EasyWriter_Capn_Software_John_Draper_1979_Program https://archive.org/details/EasyWriter_Capn_Software_John_Dr... >EasyWriter was a word processor first written for the Apple II series computer in 1979, the first word processor for that platform. It was written by John Draper's Cap'n Software, which also produced a version of Forth, which EasyWriter was developed in. >Draper developed EasyWriter while serving nights in the Alameda County Jail under a work furlough program. https://news.ycombinator.com/item?id=14245590 https://news.ycombinator.com/item?id=14245590
- discreteevent 7y agoThe other bit of that comment is also very insightful: "I would say that a system that allowed other metathings to be done in the ordinary course of programming (like changing what inheritance means, or what is an instance) is a bad design. (I believe that systems should allow these things, but the design should be such that there are clear fences that have to be crossed when serious extensions are made.)"
- seltzered_ 7y agoA great visual example of messaging / sharing between two <s>apps</s> tools is in "Alan Kay's tribute to Ted Nelson at "intertwingled" fest": https://youtu.be/AnrlSqtpOkw?t=607 https://youtu.be/AnrlSqtpOkw?t=607
- mpweiher 7y agoObjective-Smalltalk ( http://objective.st/ http://objective.st/ ) is a newish smalltalk that was very much inspired by this very message (no pun intended). And by Mary Shaw's work on software architecture, and, and... So what might make a good metasystem? The ones we have are usually too specific, too concrete, the metasystem for this particular language, sort of like having a "types" rooted in concrete machine types (cough, C, cough). Smalltalk solved this for the type-system, with the root being something abstract, "Object". If you apply the same idea of creating a hierarchy to the metasystem(s), you come up with something along software-archtitectural ideas of component (procedures, methods, objects, filters, programs) and connector (calls, message-sends, pipes, variable access, ...). And it turns out that this gives you parsimony, great power, and pretty darn good security of meaning.
- qwerty456127 7y agoObviously. That's so sad OOP went a completely wrong way ever after.
- ProfHewitt 7y agoBelow is the fundamental axiom for Actor events (i.e. communications: ∀[S:ActorSystem, P predicateOn Event<S>] // For every ActorSystem S and every predicate P on events of S (∀[x:Primordial<S>] P[Creation[x]] // If P holds for the creation event of every primordial of S ⋀ ∀[e:FromOutside<S>] P[e] // and P holds for every event from outside S ⋀ ∀[e:Event<S>, e1:ImmediatelyFollows<e>] // and for every event of S P[e]⇒P[e1]) // if P holds for the event, then P holds for each immediately following event ⇒ ∀[e:Event<S>] P[e] // then P holds for every event of S See the following for more explanation: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3459566 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3459566
- elegaphant 7y agoI have an applied math background. What resources are recommend to understand the symbols used here?
- deleted 7y ago[deleted]
- trobertson 7y agoThe base notation is from formal logic. A (dense) overview of first-order logic can be found on this wikipedia page: https://en.wikipedia.org/wiki/First-order_logic https://en.wikipedia.org/wiki/First-order_logic It's much nicer to get slowly walked through it with a textbook, but I'm blanking on the name of the book I used.
- elegaphant 7y agoThanks trobertson. This may be what I need. So, may I presume that the notation of (Prof) Carl Hewitt’s Direct Logic is consistant with that of First-Order Logic?
- ProfHewitt 7y agoActually, the notation used above is for strongly-typed higher-order theories. See the following: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3459566 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3459566
- mbrodersen 7y ago... which is why Erlang is perhaps the only truly OO language used in production today (using Alan Kay's definition of OO).