15 ms·

If you're tired of hearing about the virtues of Smalltalk (like I was at one point) and ask "if it is so good, why isn't it popular?", then watch @deech's talk

by jasim 6y ago

If you're tired of hearing about the virtues of Smalltalk (like I was at one point) and ask "if it is so good, why isn't it popular?", then watch @deech's talk (Aditya Siram) - "What FP can learn from SmallTalk" - https://www.youtube.com/watch?v=baxtyeFVn3w https://www.youtube.com/watch?v=baxtyeFVn3w I think it is the most accessible explanation of the marvel of Smalltalk, for those who were not lucky to work with it during the late 80-90s. Also I think Ruby is the mainstream language that is closest to Smalltalk today, with the idea that everything is an object and late-binding as much as possible. One thing I can't help point out is that Smalltalk / Alan Kay's vision of interconnected objects forming a recursive computing system is not the only "true" vision of OO out there. From Simula thru C++ and then Java and C# also are object-oriented (or class-oriented for those who care about the distinction), but they are statically typed. It is also OO because OO is a word, not a mathematical definition, and when people talk about OO, there is enough similarity between all these variations that we consider all of them to be in the same camp. Plus with the growing move towards strict static typing even in interpreted languages, which I think is driven by actual industry needs and programmer preferences than external marketing, it is becoming a disservice to think of statically typed OO languages as being somehow inferior to the true ideal of object-oriented programming.

nextos 6y ago
Ruby is a joy to use and relatively close to Smalltalk in many many ways. I wish Ruby had taken Python's spot. When Rails exploded ~2006, I thought it'd become a mainstream language. But sadly it has never been very popular for non-web things, if we exclude Japan. One reason is probably that the standard Ruby implementation (MRI) was really slow till recently. Smalltalk, on the other hand, had extremely good VMs that served as embryo for the JVM. I've used Ruby for many big projects (but never used Rails!) and it has scaled really well for large and exotic things such as abstract interpreters.
- codetrotter 6y ago
  Speaking of Ruby, there is this book that I read a few years ago (five years ago, in fact – time flies), that was using Ruby when explaining the things it was talking about. Personally I don’t use Ruby and prefer Python instead, but the book was very enjoyable nonetheless so I would recommend that book to anyone, even to people like me who don’t really like Ruby in general and don’t really want to read or write Ruby in general. Stuart, T., 2013. Understanding Computation: From Simple Machines To Impossible Programs. O’Reilly. Book website: https://computationbook.com/ https://computationbook.com/
  - joshhogg 6y ago
    This books looks super interesting. Did you find any of it applicable to particular problems you are working on or was it good general knowledge?
    - codetrotter 6y ago
      As good general knowledge yes
  - AdieuToLogic 6y ago
    Another good "non-rails" Ruby book is "Enterprise Integration with Ruby"[0]. Unfortunately, it's a bit dated (2006), so I am sure some of what Schmidt details is no longer supported/valid. Still, a cool book IMHO. 0 - https://www.amazon.com/Enterprise-Integration-Ruby-Maik-Schmidt/dp/0976694069 https://www.amazon.com/Enterprise-Integration-Ruby-Maik-Schm...
- zengargoyle 6y ago
  I didn't give Ruby a second thought after hearing Matz say something along the lines of being a bit sad that people were using it because it meant that he couldn't change it anymore. It was his toy language that escaped his control and now he had to worry about compatability and couldn't just break things. It's not a good sign when the creator didn't want it to be used that much.
Konohamaru 6y ago
OO was the best programming paradigm until people recognized the power of concurrency. Even in the usecase of GUI programming, where OO is supposed to shine the brightest, OO is a failure because interactive programs are extremely concurrent. Even back then when everything was executed in serial GUI frameworks were designed concurrently in crummy languages never designed to support concurrent programming such as C. Or worse, C++. And functional programming is no good as a general programming paradigm because: 1. Little of computing--almost nothing--is declarative. That means functional programming's non-general by definition. 2. Programming cannot be married to mathematics despite what formal proof proponents and people who think naming their language "Pascal" is a good idea think. It will always be an arranged and sham marriage. 3. Thinking being able to easily execute your declarative programs in parallel means you'll never have to think concurrently and can just outsource everything to Hadoop only means you can't understand the difference between parallelism and concurrency.
- jcelerier 6y ago
  > Even in the usecase of GUI programming, where OO is supposed to shine the brightest, OO is a failure because interactive programs are extremely concurrent. Even back then when everything was executed in serial GUI frameworks were designed concurrently in crummy languages never designed to support concurrent programming such as C. Or worse, C++. I must say that I have trouble reconciling this with the fact that every single GUI program running on my computer right now is written mostly in C++ with a bit in C for my WM and a bit of Rust for Firefox.
- jbverschoor 6y ago
  Messagepassing and poking around in objects is awesome. But more from a user developer point of view. Power user.. power users aren’t here anymore
- throwaway_pdp09 6y ago
  > OO was the best programming paradigm No, it depends on what you're doing. Always does, always will. > Even in ... GUI programming, ... OO is a failure because interactive programs are extremely concurrent Seems to work well for me on windows. What's the problem precisely? > And functional programming is no good as a general programming paradigm because ... Little of computing--almost nothing--is declarative That's just wrong. > Programming cannot be married to mathematics... You give no evidence despite it being a long association. > Thinking being able to easily execute your declarative programs in parallel means you'll never have to think concurrently Yes, because concurrency only becomes an obvious issue when state is involved. So FP sidesteps that by not having interacting state. I have some criticisms of FP but this is plain silly. You're just dissing stuff here. It's annoying.
cxr 6y ago
At the risk of putting readers off by the title, there's a video essay on YouTube called "Object-Oriented Programming is Bad"[1]. It's both thoughtful and thought-provoking, although I don't agree with the conclusion. Steve Naroff (from Stepstone/NeXT/Apple) did a recent-ish set of interviews with the Computer History Museum[2][3] and referenced that video a bit (and extemporized about objects in small parts throughout). Side note: Naroff and Brad Cox are set to present a paper on Objective-C at this year's HOPL[4]. I wish it were as readily available as Allen Wirfs-Brock's JS paper for the same conference[5][6]. 1. https://www.youtube.com/watch?v=QM1iUe6IofM https://www.youtube.com/watch?v=QM1iUe6IofM 2. https://www.youtube.com/watch?v=ljx0Zh7eidE https://www.youtube.com/watch?v=ljx0Zh7eidE 3. https://www.youtube.com/watch?v=vrRCY6vwvbU https://www.youtube.com/watch?v=vrRCY6vwvbU 4. https://hopl4.sigplan.org/track/hopl-4-papers#List-of-Accepted-Papers https://hopl4.sigplan.org/track/hopl-4-papers#List-of-Accept... 5. http://www.wirfs-brock.com/allen/posts/866 http://www.wirfs-brock.com/allen/posts/866 6. https://zenodo.org/record/3707008#.XtoRR-TEklQ https://zenodo.org/record/3707008#.XtoRR-TEklQ
- panic 6y ago
  The HOPL paper is available here: https://dl.acm.org/doi/abs/10.1145/3386332 https://dl.acm.org/doi/abs/10.1145/3386332 (the PDF link even works without an institutional login!)
  - cxr 6y ago
    Thanks a ton! Earlier this week it didn't look like it was available. https://news.ycombinator.com/item?id=23436517 https://news.ycombinator.com/item?id=23436517 Looks like there's another Smalltalk paper, too: https://dl.acm.org/doi/abs/10.1145/3386335 https://dl.acm.org/doi/abs/10.1145/3386335
- foobar_ 6y ago
  Every time you call a method you are breaking encapsulation because you can no longer change the name of the method, it is exposing the internals. Thats why Message Passing has more guarantees with encapsulation. Abstraction is overdone. Sometimes the simplest implementation is a function. Not a class. Inheritance is a failed idea of code reuse because it leaves the code brittle. You can develop GUI apps without OOP - Tcl / tk and some game programming guis are done that way. All that you need are callbacks essentially. Polymorphism is essentially overloaded functions and you don't need OOP to support that.
AdmiralAsshat 6y ago
I'd be much happier if someone could instead just provide a version of Smalltalk that everyone can agree on. "Use Squeak!" "No, Squeak is old! Use Pharo!" "Pharo doesn't adhere to the Smalltalk standard. Just use gnu-smalltalk in a terminal!" Never have I seen such a self-defeating community. If the Smalltalk community wants it to be anything more than a historical curiosity, I beg it to form some kind of standards committee and agree on a common implementation so that I can learn Smalltalk without worrying that I'm studying a dialect that is not mutually intelligible to the other implementations.
- radiowave 6y ago
  Ah, you mean like a version of Python that everyone can agree on! Joking aside, it's an entirely understandable sentiment, but Smalltalk is not only an old language, but also one that lives in a symbiotic relationship with its tools (which defy the normal notions of language standardisation). As things stand, if you want a standard, what you're likely to get is a time-capsule. Pharo in particular does not want to be a time-capsule, and while it's certainly been a source of frustration to me that Pharo has existed in such a state of flux for so much of its life, I understand that the change is necessary, and I remain cautiously hopefuly about the direction they're taking. I'm not a daily user of Pharo, so while I have a rough idea that it is becomming more settled as time passes, I'm not an authority here.
- jecel 6y ago
  The Smalltalk community is an artifact of the pre-Internet days. See Forth or Lisp for the same result. Communication was slow, in the form of publications and you couldn't get your hands on actual code (which probably wouldn't run on any of your machines anyway). See the many Unix clones before Linux. The difference is that Linux came along when you had GNU code to avoid having to implement ls, ps, etc yourself, you had many people with 386 PCs and you had the Internet to work together without having to be all in the same room (not to mention not having to set up a company to sell CD-ROMs, though other people did that for Linux). By the time languages like Python and Ruby came along it was a different world and they could be more Linux-like in terms of community and less QNX/Coherent/Idris/BSD/Irix/AIX/Solaris/... Putting a splintered community back together is not an easy task. Note that Squeak, Pharo and Cuis deviate from the ANSI Smalltalk standard in the same ways (Traits, {....} syntax for runtime collections).
radiowave 6y ago
Smalltalk prizes interactivity, in the manner that arises from being able to make small, incremental adjustments to code while it (and it's state) remain in memory. Its rejection of static typing is not axiomatic, merely an expedient way of achieving those interactivity goals. Could the two things be reconciled? I don't know, but I think at least that it shouldn't be unthinkable. As an aside, static type systems which can be mutated during runtime are astonishingly commonplace. They're very crude, and tend to be called "relational databases", and doing those mutations is a major pain because in spite of all that's elegant about relational algebra, actual SQL is a fucking abomination. (And this is coming from a full-on Postgres fanboy.) On your comment about the similarity of Ruby, I know what you mean, and yet I regard Ruby as being basically nothing at all like Smalltalk. That's because I'm principally thinking in terms of the development culture, tools, and working practices, and not thinking in terms of the implementation of the VM or the object model, or the names of certain methods. So similarity between languages is a tricky thing to nail down, not least because in the case of a gestalt system like Smalltalk, "programming language" is actually a tricky thing to nail down.
- pjmlp 6y ago
  > Could the two things be reconciled? Yes, they can, that was the whole point behind StrongTalk. http://strongtalk.org/ http://strongtalk.org/ Whose JIT technology eventually became the basis for Hotspot.
jmchuster 6y ago
I really like all of Sandi Metz's talks and books on Ruby for that reason. Her Smalltalk background really shines through to bring out the best parts of OO, and are really applicable for just getting better at design and architecture.

by jasim 6y ago

nextos 6y ago

Ruby is a joy to use and relatively close to Smalltalk in many many ways. I wish Ruby had taken Python's spot. When Rails exploded ~2006, I thought it'd become a mainstream language. But sadly it has never been very popular for non-web things, if we exclude Japan. One reason is probably that the standard Ruby implementation (MRI) was really slow till recently. Smalltalk, on the other hand, had extremely good VMs that served as embryo for the JVM. I've used Ruby for many big projects (but never used Rails!) and it has scaled really well for large and exotic things such as abstract interpreters.

codetrotter 6y ago
Speaking of Ruby, there is this book that I read a few years ago (five years ago, in fact – time flies), that was using Ruby when explaining the things it was talking about. Personally I don’t use Ruby and prefer Python instead, but the book was very enjoyable nonetheless so I would recommend that book to anyone, even to people like me who don’t really like Ruby in general and don’t really want to read or write Ruby in general. Stuart, T., 2013. Understanding Computation: From Simple Machines To Impossible Programs. O’Reilly. Book website: https://computationbook.com/ https://computationbook.com/
- joshhogg 6y ago
  This books looks super interesting. Did you find any of it applicable to particular problems you are working on or was it good general knowledge?
  - codetrotter 6y ago
    As good general knowledge yes
- AdieuToLogic 6y ago
  Another good "non-rails" Ruby book is "Enterprise Integration with Ruby"[0]. Unfortunately, it's a bit dated (2006), so I am sure some of what Schmidt details is no longer supported/valid. Still, a cool book IMHO. 0 - https://www.amazon.com/Enterprise-Integration-Ruby-Maik-Schmidt/dp/0976694069 https://www.amazon.com/Enterprise-Integration-Ruby-Maik-Schm...
zengargoyle 6y ago
I didn't give Ruby a second thought after hearing Matz say something along the lines of being a bit sad that people were using it because it meant that he couldn't change it anymore. It was his toy language that escaped his control and now he had to worry about compatability and couldn't just break things. It's not a good sign when the creator didn't want it to be used that much.

Konohamaru 6y ago

OO was the best programming paradigm until people recognized the power of concurrency. Even in the usecase of GUI programming, where OO is supposed to shine the brightest, OO is a failure because interactive programs are extremely concurrent. Even back then when everything was executed in serial GUI frameworks were designed concurrently in crummy languages never designed to support concurrent programming such as C. Or worse, C++. And functional programming is no good as a general programming paradigm because: 1. Little of computing--almost nothing--is declarative. That means functional programming's non-general by definition. 2. Programming cannot be married to mathematics despite what formal proof proponents and people who think naming their language "Pascal" is a good idea think. It will always be an arranged and sham marriage. 3. Thinking being able to easily execute your declarative programs in parallel means you'll never have to think concurrently and can just outsource everything to Hadoop only means you can't understand the difference between parallelism and concurrency.

jcelerier 6y ago
> Even in the usecase of GUI programming, where OO is supposed to shine the brightest, OO is a failure because interactive programs are extremely concurrent. Even back then when everything was executed in serial GUI frameworks were designed concurrently in crummy languages never designed to support concurrent programming such as C. Or worse, C++. I must say that I have trouble reconciling this with the fact that every single GUI program running on my computer right now is written mostly in C++ with a bit in C for my WM and a bit of Rust for Firefox.
jbverschoor 6y ago
Messagepassing and poking around in objects is awesome. But more from a user developer point of view. Power user.. power users aren’t here anymore
throwaway_pdp09 6y ago
> OO was the best programming paradigm No, it depends on what you're doing. Always does, always will. > Even in ... GUI programming, ... OO is a failure because interactive programs are extremely concurrent Seems to work well for me on windows. What's the problem precisely? > And functional programming is no good as a general programming paradigm because ... Little of computing--almost nothing--is declarative That's just wrong. > Programming cannot be married to mathematics... You give no evidence despite it being a long association. > Thinking being able to easily execute your declarative programs in parallel means you'll never have to think concurrently Yes, because concurrency only becomes an obvious issue when state is involved. So FP sidesteps that by not having interacting state. I have some criticisms of FP but this is plain silly. You're just dissing stuff here. It's annoying.

cxr 6y ago

At the risk of putting readers off by the title, there's a video essay on YouTube called "Object-Oriented Programming is Bad"[1]. It's both thoughtful and thought-provoking, although I don't agree with the conclusion. Steve Naroff (from Stepstone/NeXT/Apple) did a recent-ish set of interviews with the Computer History Museum[2][3] and referenced that video a bit (and extemporized about objects in small parts throughout). Side note: Naroff and Brad Cox are set to present a paper on Objective-C at this year's HOPL[4]. I wish it were as readily available as Allen Wirfs-Brock's JS paper for the same conference[5][6]. 1. https://www.youtube.com/watch?v=QM1iUe6IofM https://www.youtube.com/watch?v=QM1iUe6IofM 2. https://www.youtube.com/watch?v=ljx0Zh7eidE https://www.youtube.com/watch?v=ljx0Zh7eidE 3. https://www.youtube.com/watch?v=vrRCY6vwvbU https://www.youtube.com/watch?v=vrRCY6vwvbU 4. https://hopl4.sigplan.org/track/hopl-4-papers#List-of-Accepted-Papers https://hopl4.sigplan.org/track/hopl-4-papers#List-of-Accept... 5. http://www.wirfs-brock.com/allen/posts/866 http://www.wirfs-brock.com/allen/posts/866 6. https://zenodo.org/record/3707008#.XtoRR-TEklQ https://zenodo.org/record/3707008#.XtoRR-TEklQ

panic 6y ago
The HOPL paper is available here: https://dl.acm.org/doi/abs/10.1145/3386332 https://dl.acm.org/doi/abs/10.1145/3386332 (the PDF link even works without an institutional login!)
- cxr 6y ago
  Thanks a ton! Earlier this week it didn't look like it was available. https://news.ycombinator.com/item?id=23436517 https://news.ycombinator.com/item?id=23436517 Looks like there's another Smalltalk paper, too: https://dl.acm.org/doi/abs/10.1145/3386335 https://dl.acm.org/doi/abs/10.1145/3386335
foobar_ 6y ago
Every time you call a method you are breaking encapsulation because you can no longer change the name of the method, it is exposing the internals. Thats why Message Passing has more guarantees with encapsulation. Abstraction is overdone. Sometimes the simplest implementation is a function. Not a class. Inheritance is a failed idea of code reuse because it leaves the code brittle. You can develop GUI apps without OOP - Tcl / tk and some game programming guis are done that way. All that you need are callbacks essentially. Polymorphism is essentially overloaded functions and you don't need OOP to support that.

AdmiralAsshat 6y ago

I'd be much happier if someone could instead just provide a version of Smalltalk that everyone can agree on. "Use Squeak!" "No, Squeak is old! Use Pharo!" "Pharo doesn't adhere to the Smalltalk standard. Just use gnu-smalltalk in a terminal!" Never have I seen such a self-defeating community. If the Smalltalk community wants it to be anything more than a historical curiosity, I beg it to form some kind of standards committee and agree on a common implementation so that I can learn Smalltalk without worrying that I'm studying a dialect that is not mutually intelligible to the other implementations.

radiowave 6y ago
Ah, you mean like a version of Python that everyone can agree on! Joking aside, it's an entirely understandable sentiment, but Smalltalk is not only an old language, but also one that lives in a symbiotic relationship with its tools (which defy the normal notions of language standardisation). As things stand, if you want a standard, what you're likely to get is a time-capsule. Pharo in particular does not want to be a time-capsule, and while it's certainly been a source of frustration to me that Pharo has existed in such a state of flux for so much of its life, I understand that the change is necessary, and I remain cautiously hopefuly about the direction they're taking. I'm not a daily user of Pharo, so while I have a rough idea that it is becomming more settled as time passes, I'm not an authority here.
jecel 6y ago
The Smalltalk community is an artifact of the pre-Internet days. See Forth or Lisp for the same result. Communication was slow, in the form of publications and you couldn't get your hands on actual code (which probably wouldn't run on any of your machines anyway). See the many Unix clones before Linux. The difference is that Linux came along when you had GNU code to avoid having to implement ls, ps, etc yourself, you had many people with 386 PCs and you had the Internet to work together without having to be all in the same room (not to mention not having to set up a company to sell CD-ROMs, though other people did that for Linux). By the time languages like Python and Ruby came along it was a different world and they could be more Linux-like in terms of community and less QNX/Coherent/Idris/BSD/Irix/AIX/Solaris/... Putting a splintered community back together is not an easy task. Note that Squeak, Pharo and Cuis deviate from the ANSI Smalltalk standard in the same ways (Traits, {....} syntax for runtime collections).

radiowave 6y ago

Smalltalk prizes interactivity, in the manner that arises from being able to make small, incremental adjustments to code while it (and it's state) remain in memory. Its rejection of static typing is not axiomatic, merely an expedient way of achieving those interactivity goals. Could the two things be reconciled? I don't know, but I think at least that it shouldn't be unthinkable. As an aside, static type systems which can be mutated during runtime are astonishingly commonplace. They're very crude, and tend to be called "relational databases", and doing those mutations is a major pain because in spite of all that's elegant about relational algebra, actual SQL is a fucking abomination. (And this is coming from a full-on Postgres fanboy.) On your comment about the similarity of Ruby, I know what you mean, and yet I regard Ruby as being basically nothing at all like Smalltalk. That's because I'm principally thinking in terms of the development culture, tools, and working practices, and not thinking in terms of the implementation of the VM or the object model, or the names of certain methods. So similarity between languages is a tricky thing to nail down, not least because in the case of a gestalt system like Smalltalk, "programming language" is actually a tricky thing to nail down.

pjmlp 6y ago
> Could the two things be reconciled? Yes, they can, that was the whole point behind StrongTalk. http://strongtalk.org/ http://strongtalk.org/ Whose JIT technology eventually became the basis for Hotspot.

jmchuster 6y ago

I really like all of Sandi Metz's talks and books on Ruby for that reason. Her Smalltalk background really shines through to bring out the best parts of OO, and are really applicable for just getting better at design and architecture.