16 ms·

On Learning Smalltalk

152 points by xkriva11 5y ago

pulse7 5y ago
Maybe - one day - somebody will make the image based virtual machine for Java... VisualAge for Java was an attempt in that direction, but the image part was abandoned later in Eclipse...
- protomyth 5y ago
  I like the idea of a live image, and have watched some Smalltalkers being amazingly productive, but I hope the next iteration of image-based IDEs think about some advances such as multi-images, round trips to text, and better scripting around the creation, destruction, and interaction of multiple VMs. Having checkpoints would be a nice touch. Image deltas and stare copying would be nice.
  - p_l 5y ago
    The Smalltalk VCSes do all that, AFAIK, even as far back as Envy
- xkriva11 5y ago
  I think that the magic ingredient is not the image itself. Imagine that you have the language where every method/function is in its own file, and most of them are very short (two, three lines). Then the text editing functionality of the IDE starts to be really unimportant - something on the level of Notepad is good enough. It makes the compilation super fast; the IDE needs to invest in exploring relations between these small code fragments (that have no defined order), their organization, code changes need to be not just text file editing (Smalltalk pioneered refactorings). This is one thing that makes Smalltalk so interesting (and what the mainstream does not get).
  - igouy 5y ago
    iirc Bill Opdyke's refactorings were for C++ https://ieeexplore.ieee.org/document/7274256 https://ieeexplore.ieee.org/document/7274256
- grahamlee 5y ago
  Take a look at TruffleSqueak on the Graal VM.
- pjmlp 5y ago
  Actually that is kind of the idea behind Eclipse's workspace concept. It wasn't abandoned, rather rebuilt on top of a virtual file system.
Jenk 5y ago
I worked with Smalltalk for a number of years, and was even present at discussion during the ESUG (European Smalltalk User Group) meetup in 2008 that was the very birthplace of Pharo, though admittedly was a little out of my depth with some of the technicalities (and politics) that caused the rift from Squeak. I loved working with Smalltalk as a language, and developing inside the fully integrated VM. It's my fondest development experience to date. I really didn't love deploying Smalltalk applications and even collaborating was more difficult than file based languages/systems. Deployments (at the time) were a practice of shipping the image to the servers that needed to run. There literally is no (separate) "runtime" it's all in the image. This thing got bulky real quick. I haven't touched Smalltalk in a while, so maybe (hopefully?) things have improved and deployments are no longer a problem.
- ljm 5y ago
  I played around with Squeak over Christmas (basically trying to implement a ray tracer, although I started to lose interest after I rolled my own Matrix implementation with all the transforms). As far as working with the code, debugging, reading and writing were concerned, it was great. It really gave me a taste for thoughtful OOP, simple documentation, and even TDD-style development again, because the whole environment just worked perfectly for it in a way that would be hard to reproduce in a traditional language where you're organising things on the file system. Dealing with version control was a little more awkward (getting Git in place), and I'm glad I didn't have to worry about deployment or any kind of maintenance. Possibly GNU Smalltalk would be an ideal middle-ground there. It's also one of the few occasions where I've not really had to rely on the internet so much to get help when I need it. It's been enough to have a book on Smalltalk and to rely on the documentation in the IDE.
- pjmlp 5y ago
  My first Smalltalk was Smalltalk/V. I fail to see how shipping a tree shaked version of the image was any different than shipping a C++ application with MVSCRT.dll, for example. As for source control, while it was indeed a problem with workarounds like text export/import, image based SCM were eventually developed.
- rsayers 5y ago
cies 5y ago
I find Ruby to be enough of a Smalltalk for my taste. Besides that I see people to stuff with Clojure, such as hot-replacing live code, that I had only seen Smalltalk devs do so far.
- disconcision 5y ago
  related, see this clojure talk on image-based programming in a functional context: https://www.youtube.com/watch?v=Kgw9fblSOx4 https://www.youtube.com/watch?v=Kgw9fblSOx4
- weatherlite 5y ago
  So what are the similarities between Ruby and Smalltalk? I'm probably never gonna learn Smalltalk so it's hard to understand what Ruby borrowed.
  - Mikeb85 5y ago
    Everything is an object. Being able to inspect/change running objects, etc...
  - cies 5y ago
    I feel Ruby is mostly another syntax, but the type of OO (with bits of FP where it makes sense in OO) is very much like Smalltalk the language.
- 0x445442 5y ago
  I don't have experience with Ruby or Clojure. While you're debugging an app, can you step to a break point, evaluate the next statement, navigate back up the call stack, change code that's already executed and try again in those languages?
  - vidarh 5y ago
    To an extent. Things like "pry" in Ruby will let you edit methods and reload and resume and generally somewhat pretend you're working on an image. It's not as flexible as a typical Smalltalk environment, but with the new Ruby debugger in Ruby 3.1 I suspect we'll see another big leap towards that.
VaxWithSex 5y ago
I wrote my Bachelor and Master Thesis about Smalltalk stuff and I still love it to this date.
mdrzn 5y ago
Love these ambiguous enough titles to be either something interesting for the whole population (how to learn small talk) or something incredibly specific for one subset of the programmers population.
- marcellus23 5y ago
  I think it's the difference between Smalltalk (one word) and small talk (two words).
gjvc 5y ago
smalltalk and lisp are both secret weapons; understand and appreciate them and even though you may not use them in any commercial or professional setting, knowledge of them makes becoming familiar with other languages much easier.
- pjmlp 5y ago
  Not only that, learn about Mesa, XDE and Mesa/Cedar, and then discover how Smalltalk and Interlisp-D influenced how even modern IDEs look like.
- sebastianconcpt 5y ago
  Correct.
beardyw 5y ago
Smalltalk was my introduction to OO in the 90s. It is the perfect introduction in my opinion, but as the author says, it might spoil you for anything else. If I remember right, the whole image thing took a bit of care, with odd forgotten stuff ending up in production. Someone may correct me.
jonathaneunice 5y ago
I learned Smalltalk in the Elder Days (1985). Coming from C and Pascal, the power and majesty of true collections—dynamic lists! that you didn't have to build yourself with pointers! sets! dictionaries! iteration over objects not integers! selection, rejection, injection!—was astounding. The ability to define behaviors in a generic not intensely specific way, the ability to meta-program, the ability to twiddle your environment directly—just so many world-changing innovations. Thankfully most of these advances are now baked into Ruby, Python, JavaScript, etc. (either right into the language, or with ready-to-hand libraries like itertools, more-itertools, and Underscore.js). The image—all your code, data/state, your entire OS and windowing system, your IDE, all rolled up into one—that was an interesting approach but honestly that is the worst thing about Smalltalk. No modularity. No version control. Your image persists your data and changes forever—including any mistakes you make, knocking around inside big ball of ever-declining clarity and reliability. Over time every image collects entropy, mistakes, and bitrot like no one's business! Eventually it gets to be impossible to figure out how to fix it, or takes so much energy to maintain you won't bother. Then you have to chuck it and start afresh. Rinse and repeat! Give me today's alternative, non-persistent dev environments and version control, any day.
- jimbokun 5y ago
  That seems to be the common complaint about image bases systems like Smalltalk and (some versions of) Common Lisp. The difficulty of collaborating, auditing, deploying, continuous integration and rolling back to specific versions of the code. Seems like it makes operational tasks, and really anything that involves distributing the code to anyone who is not the developer, is more difficult than with non-image based languages.
  - scroot 5y ago
    There have been several different version control systems available for most Smalltalks for a while now. In the big open source Smalltalks (Squeak, Pharo, etc) there is even Git integration.
  - xkriva11 5y ago
    Pharo has all this solved quite well.
gilbetron 5y ago
I did smalltalk professionally as my second job out of college, 1995-1997. It was cool learning it, and it definitely gets you into OOP. It also laid the groundwork for realizing that OOP isn't a great paradigm for software development. Plus it was really slow and clunky, in the end. For the time, the IDE (VisualAge and the other one I can't remember) was cool, although git crushes the model they used back then. Overall, I'm glad I learned it, much like TCL and Lisp, but I'm definitely glad I don't use it professionally. The languages basically take their premise to the extreme, where the premise for each is "What if everything, including the language itself, was ..." TCL: ...a string? Lisp: ...a list? Smalltalk: ...an object? I don't know enough about it, but I think with Haskell the suffix would be "...a function?" Neat experiments, neat learning them, but I appreciate other languages more for actually implementing large projects.
- vindarel 5y ago
  not to mis-interpret this comment: Lisp has of course other data structures, hash tables and all. The source code though can be seen as a list of lists, and it can be manipulated as is in macros (but you can use an AST too).
- jimbokun 5y ago
  For Haskell, maybe it's: "What if everything was immutable?" Which I guess doesn't really include the language itself. But it seems more fundamental to Haskell than first class functions, which exist in many other popular languages.
- ljm 5y ago
  I feel like Smalltalk demonstrated a better version of OOP than what you get in other languages that market themselves as object oriented. Firstly that it's consistent with itself, but mainly because it's incredibly awkward to do OOP in the Gang of Four/Clean Code/DDD style that you'd typically see in, say, a Java project. You're essentially building up a catalogue of messages and answers and so it's not particularly ergonomic to jump through several layers of abstraction in the browser to get what you need. And there's no arbitrary limitation on your code such that a class can only have 10 methods in it, or 100 lines, or some other silly thing that forces you into creating a more convoluted architecture with more indirection. I've grown weary of OOP for a long time because of how hard it is to find an effective application of it that doesn't grow into a collection of explicit design patterns with some business logic buried in the depths of the hierarchy. My brief experience with Smalltalk essentially revived my interest in it and encouraged me to be more thoughtful about my approach without throwing it all out and pining for a purer, more functional language that trades OOP's big problems with a set of its own.
chriswarbo 5y ago
I've played in Smalltalk systems over the years, but not used it for anything serious. On one hand I like the idea of an image, being inspectable, adjustable, etc. Yet on the other hand I'm also a fan of stateless, pure-functional approaches where possible (e.g. Haskell, Nix, etc.). I get a similar feeling from Emacs: it's really useful to inspect, override, debug, etc. the underlying Lisp; yet I prefer to keep my config as declarative as possible (e.g. via use-package). In fact, I rebooted recently and found that ANSI colour codes had stopped working in my Emacs terminals: turns out I'd forgotten to update my xterm-color config when switching from shell-mode to shx-mode several weeks ago!
- 0x445442 5y ago
  You can manage the Smalltalk image the same way you do with Emacs by starting with a base image that loads only the extra packages you want.
germandiago 5y ago
The problem I have with Smalltalk (and I love the idea!) is that when I want to save things in Git, or when I want to deploy something minimal, things are so glued with each other that I find difficult to figure out what belongs to me. There are also other problems: - a desktop app cannot look like a regular one, at least in Pharo. - I am not sure how to glue native code, so when doing graphics stuff (this is what I really want to do with Pharo bc of its interactivity) I did not know how to consume APIs for drawing. I do not have a lot of training admittedly. The interactivity looks super, super cool! But also you have to change a lot of habits.
- rscho 5y ago
  Pharo 10 will use a native GUI backend. Also, git is well-integrated.
  - germandiago 5y ago
    Yes, I saw git is integrated. The problem is that I am not sure how to use it. Any docs? Probably there were but my visit was some time ago. It would rock to have native GUI. Also, if I could know how to draw graphics... That would be very nice also, because having an interactive environment for graphics is the most awesome stuff that Pharo can offer (me).
    - xkriva11 5y ago
      There is a booklet about Git integration: http://books.pharo.org/booklet-ManageCode/pdf/2019-03-24-ManageCode.pdf http://books.pharo.org/booklet-ManageCode/pdf/2019-03-24-Man... For 2D graphics, Pharo uses Cairo binding named Athens (and Roassal as another convinient layer above that). For 3D, you may be interesting in Godotalk (https://www.youtube.com/watch?v=ncmERef0EFo https://www.youtube.com/watch?v=ncmERef0EFo, https://pharoweekly.wordpress.com/2021/02/03/godotalk/ https://pharoweekly.wordpress.com/2021/02/03/godotalk/)
    - Zenchess 5y ago
      I started working on a raylib binding for pharo using pharo's ffi...I have to say pharo's ffi system is very easy to use. It works and I got a few demos working, but I haven't put in the function calls for most of raylib. https://github.com/Zenchess/pharoRaylib https://github.com/Zenchess/pharoRaylib There's also native pharo smalltalk stuff like athens, woden, and maybe others... Personally I have moved to using Dolphin Smalltalk and raylib bindings there as it's been more performant and I prefer Dolphin over pharo. Dolphin also has good external interfacing support and is more of a native Windows OS smalltalk distro. If you're looking for building native windows looking applications on windows at least probably your best bet is dolphin and it's free and open source.
TheCondor 5y ago
What do some of you smalltalksters do with it? I've had a daydream that some sort of data Swiss army knife/visualizer toolkit would be a fun project but it lacks the share ability of notebooks. Are there other operational sorts of things you use smalltalk for? I have a set of scripts and tools I use daily for work (things that slice and dice our data, perform various operational tasks against AWS, etc..) that I could see cooking in to some sort of smalltalk system but I haven't done it.
- ynniv 5y ago
  Have you seen https://gtoolkit.com https://gtoolkit.com? https://lepiter.io/feenk/glamorous-toolkit-and-pharo-9q25tavxwfq6z1drwvegd5u9o/ https://lepiter.io/feenk/glamorous-toolkit-and-pharo-9q25tav...
  - jboynyc 5y ago
    Also Grafoscopio: https://mutabit.com/repos.fossil/grafoscopio/doc/tip/readme.md.html https://mutabit.com/repos.fossil/grafoscopio/doc/tip/readme....
AlbertCory 5y ago
This is heartening. It was hugely influential on the Xerox Star and by extension, Lisa and Mac, even though we didn't actually write in it. It showed you a different way of thinking about things. But for anyone saying they learned Smalltalk in the Elder Days (1980s): No, you didn't. In [1] I discuss learning it in 1978, and there was an icon prototype written in Smalltalk that same year. [1] https://www.albertcory.io https://www.albertcory.io
rbanffy 5y ago
What is the current state of multi-core and multi-threading in Smalltalk? I remember Squeak wouldn’t use more than one core and one OS process and would implement threads in itself, but that was a very long while ago.
- jecel 5y ago
  The 2008 RoarVM project allowed Squeak to run on a 56 core Tilera chip and was later ported to run on multiprocessor x86 machines: https://stefan-marr.de/renaissance/ https://stefan-marr.de/renaissance/ https://github.com/smarr/RoarVM https://github.com/smarr/RoarVM This was a research project so performance on a single core was poor compared to the official Squeak virtual machine, but it was an interesting exploration of the natural fit between objects/message passing and multiple cores.
  - rbanffy 5y ago
    Thanks, Jecel. Good to see you around. It is indeed a natural fit to many core architectures. I frequently mused about giving every message process its own thread. I’ll read the papers you mentioned.
tarkin2 5y ago
Smalltalk has the unrivaled ability to explore and change your environment graphically, and for the changes to persist. Only the web with the developer console comes close, and the changes aren't persistent. Binary image-based development with serialisation, now we aren't all trying to make exes, should be more of a thing.
sebastianconcpt 5y ago
If feels like you build the environment to match the problem, not figure out how to describe your problem on the terms of your language. Yes. Correct. That was the intention of the language design. Here is described in detail by Dan Ingalls https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
CrankyCanuck 5y ago
I remember learning Smalltalk. Or rather, beating the crap out of the bloody machine it ran on. This was back in 1989...Carleton U in Ottawa. The CompSci faculty was all-in on the glory of Smalltalk. We had to learn it on old (even then) Apple Lisa machines running some sort of Mac emulation to run Smalltalk-80. Occasionally, the Lisa would eat your diskette...and you had to rip the case apart to pry it out. We were told Smalltalk was the future...seemed no one was offering jobs in Smalltalk though...just a whole lot of dBaseIV. Must admit, it was fun, and cute...but it had no chance of paying my bills at the time.

152 points by xkriva11 5y ago

Maybe - one day - somebody will make the image based virtual machine for Java... VisualAge for Java was an attempt in that direction, but the image part was abandoned later in Eclipse...

protomyth 5y ago
I like the idea of a live image, and have watched some Smalltalkers being amazingly productive, but I hope the next iteration of image-based IDEs think about some advances such as multi-images, round trips to text, and better scripting around the creation, destruction, and interaction of multiple VMs. Having checkpoints would be a nice touch. Image deltas and stare copying would be nice.
- p_l 5y ago
  The Smalltalk VCSes do all that, AFAIK, even as far back as Envy
xkriva11 5y ago
I think that the magic ingredient is not the image itself. Imagine that you have the language where every method/function is in its own file, and most of them are very short (two, three lines). Then the text editing functionality of the IDE starts to be really unimportant - something on the level of Notepad is good enough. It makes the compilation super fast; the IDE needs to invest in exploring relations between these small code fragments (that have no defined order), their organization, code changes need to be not just text file editing (Smalltalk pioneered refactorings). This is one thing that makes Smalltalk so interesting (and what the mainstream does not get).
- igouy 5y ago
  iirc Bill Opdyke's refactorings were for C++ https://ieeexplore.ieee.org/document/7274256 https://ieeexplore.ieee.org/document/7274256
grahamlee 5y ago
Take a look at TruffleSqueak on the Graal VM.
pjmlp 5y ago
Actually that is kind of the idea behind Eclipse's workspace concept. It wasn't abandoned, rather rebuilt on top of a virtual file system.

Jenk 5y ago

I worked with Smalltalk for a number of years, and was even present at discussion during the ESUG (European Smalltalk User Group) meetup in 2008 that was the very birthplace of Pharo, though admittedly was a little out of my depth with some of the technicalities (and politics) that caused the rift from Squeak. I loved working with Smalltalk as a language, and developing inside the fully integrated VM. It's my fondest development experience to date. I really didn't love deploying Smalltalk applications and even collaborating was more difficult than file based languages/systems. Deployments (at the time) were a practice of shipping the image to the servers that needed to run. There literally is no (separate) "runtime" it's all in the image. This thing got bulky real quick. I haven't touched Smalltalk in a while, so maybe (hopefully?) things have improved and deployments are no longer a problem.

ljm 5y ago
I played around with Squeak over Christmas (basically trying to implement a ray tracer, although I started to lose interest after I rolled my own Matrix implementation with all the transforms). As far as working with the code, debugging, reading and writing were concerned, it was great. It really gave me a taste for thoughtful OOP, simple documentation, and even TDD-style development again, because the whole environment just worked perfectly for it in a way that would be hard to reproduce in a traditional language where you're organising things on the file system. Dealing with version control was a little more awkward (getting Git in place), and I'm glad I didn't have to worry about deployment or any kind of maintenance. Possibly GNU Smalltalk would be an ideal middle-ground there. It's also one of the few occasions where I've not really had to rely on the internet so much to get help when I need it. It's been enough to have a book on Smalltalk and to rely on the documentation in the IDE.
pjmlp 5y ago
My first Smalltalk was Smalltalk/V. I fail to see how shipping a tree shaked version of the image was any different than shipping a C++ application with MVSCRT.dll, for example. As for source control, while it was indeed a problem with workarounds like text export/import, image based SCM were eventually developed.
rsayers 5y ago

cies 5y ago

I find Ruby to be enough of a Smalltalk for my taste. Besides that I see people to stuff with Clojure, such as hot-replacing live code, that I had only seen Smalltalk devs do so far.

disconcision 5y ago
related, see this clojure talk on image-based programming in a functional context: https://www.youtube.com/watch?v=Kgw9fblSOx4 https://www.youtube.com/watch?v=Kgw9fblSOx4
weatherlite 5y ago
So what are the similarities between Ruby and Smalltalk? I'm probably never gonna learn Smalltalk so it's hard to understand what Ruby borrowed.
- Mikeb85 5y ago
  Everything is an object. Being able to inspect/change running objects, etc...
- cies 5y ago
  I feel Ruby is mostly another syntax, but the type of OO (with bits of FP where it makes sense in OO) is very much like Smalltalk the language.
0x445442 5y ago
I don't have experience with Ruby or Clojure. While you're debugging an app, can you step to a break point, evaluate the next statement, navigate back up the call stack, change code that's already executed and try again in those languages?
- vidarh 5y ago
  To an extent. Things like "pry" in Ruby will let you edit methods and reload and resume and generally somewhat pretend you're working on an image. It's not as flexible as a typical Smalltalk environment, but with the new Ruby debugger in Ruby 3.1 I suspect we'll see another big leap towards that.

VaxWithSex 5y ago

I wrote my Bachelor and Master Thesis about Smalltalk stuff and I still love it to this date.

mdrzn 5y ago

Love these ambiguous enough titles to be either something interesting for the whole population (how to learn small talk) or something incredibly specific for one subset of the programmers population.

marcellus23 5y ago
I think it's the difference between Smalltalk (one word) and small talk (two words).

gjvc 5y ago

smalltalk and lisp are both secret weapons; understand and appreciate them and even though you may not use them in any commercial or professional setting, knowledge of them makes becoming familiar with other languages much easier.

pjmlp 5y ago
Not only that, learn about Mesa, XDE and Mesa/Cedar, and then discover how Smalltalk and Interlisp-D influenced how even modern IDEs look like.
sebastianconcpt 5y ago
Correct.

beardyw 5y ago

Smalltalk was my introduction to OO in the 90s. It is the perfect introduction in my opinion, but as the author says, it might spoil you for anything else. If I remember right, the whole image thing took a bit of care, with odd forgotten stuff ending up in production. Someone may correct me.

jonathaneunice 5y ago

I learned Smalltalk in the Elder Days (1985). Coming from C and Pascal, the power and majesty of true collections—dynamic lists! that you didn't have to build yourself with pointers! sets! dictionaries! iteration over objects not integers! selection, rejection, injection!—was astounding. The ability to define behaviors in a generic not intensely specific way, the ability to meta-program, the ability to twiddle your environment directly—just so many world-changing innovations. Thankfully most of these advances are now baked into Ruby, Python, JavaScript, etc. (either right into the language, or with ready-to-hand libraries like itertools, more-itertools, and Underscore.js). The image—all your code, data/state, your entire OS and windowing system, your IDE, all rolled up into one—that was an interesting approach but honestly that is the worst thing about Smalltalk. No modularity. No version control. Your image persists your data and changes forever—including any mistakes you make, knocking around inside big ball of ever-declining clarity and reliability. Over time every image collects entropy, mistakes, and bitrot like no one's business! Eventually it gets to be impossible to figure out how to fix it, or takes so much energy to maintain you won't bother. Then you have to chuck it and start afresh. Rinse and repeat! Give me today's alternative, non-persistent dev environments and version control, any day.

jimbokun 5y ago
That seems to be the common complaint about image bases systems like Smalltalk and (some versions of) Common Lisp. The difficulty of collaborating, auditing, deploying, continuous integration and rolling back to specific versions of the code. Seems like it makes operational tasks, and really anything that involves distributing the code to anyone who is not the developer, is more difficult than with non-image based languages.
- scroot 5y ago
  There have been several different version control systems available for most Smalltalks for a while now. In the big open source Smalltalks (Squeak, Pharo, etc) there is even Git integration.
- xkriva11 5y ago
  Pharo has all this solved quite well.

gilbetron 5y ago

I did smalltalk professionally as my second job out of college, 1995-1997. It was cool learning it, and it definitely gets you into OOP. It also laid the groundwork for realizing that OOP isn't a great paradigm for software development. Plus it was really slow and clunky, in the end. For the time, the IDE (VisualAge and the other one I can't remember) was cool, although git crushes the model they used back then. Overall, I'm glad I learned it, much like TCL and Lisp, but I'm definitely glad I don't use it professionally. The languages basically take their premise to the extreme, where the premise for each is "What if everything, including the language itself, was ..." TCL: ...a string? Lisp: ...a list? Smalltalk: ...an object? I don't know enough about it, but I think with Haskell the suffix would be "...a function?" Neat experiments, neat learning them, but I appreciate other languages more for actually implementing large projects.

vindarel 5y ago
not to mis-interpret this comment: Lisp has of course other data structures, hash tables and all. The source code though can be seen as a list of lists, and it can be manipulated as is in macros (but you can use an AST too).
jimbokun 5y ago
For Haskell, maybe it's: "What if everything was immutable?" Which I guess doesn't really include the language itself. But it seems more fundamental to Haskell than first class functions, which exist in many other popular languages.
ljm 5y ago
I feel like Smalltalk demonstrated a better version of OOP than what you get in other languages that market themselves as object oriented. Firstly that it's consistent with itself, but mainly because it's incredibly awkward to do OOP in the Gang of Four/Clean Code/DDD style that you'd typically see in, say, a Java project. You're essentially building up a catalogue of messages and answers and so it's not particularly ergonomic to jump through several layers of abstraction in the browser to get what you need. And there's no arbitrary limitation on your code such that a class can only have 10 methods in it, or 100 lines, or some other silly thing that forces you into creating a more convoluted architecture with more indirection. I've grown weary of OOP for a long time because of how hard it is to find an effective application of it that doesn't grow into a collection of explicit design patterns with some business logic buried in the depths of the hierarchy. My brief experience with Smalltalk essentially revived my interest in it and encouraged me to be more thoughtful about my approach without throwing it all out and pining for a purer, more functional language that trades OOP's big problems with a set of its own.

chriswarbo 5y ago

I've played in Smalltalk systems over the years, but not used it for anything serious. On one hand I like the idea of an image, being inspectable, adjustable, etc. Yet on the other hand I'm also a fan of stateless, pure-functional approaches where possible (e.g. Haskell, Nix, etc.). I get a similar feeling from Emacs: it's really useful to inspect, override, debug, etc. the underlying Lisp; yet I prefer to keep my config as declarative as possible (e.g. via use-package). In fact, I rebooted recently and found that ANSI colour codes had stopped working in my Emacs terminals: turns out I'd forgotten to update my xterm-color config when switching from shell-mode to shx-mode several weeks ago!

0x445442 5y ago
You can manage the Smalltalk image the same way you do with Emacs by starting with a base image that loads only the extra packages you want.

germandiago 5y ago

The problem I have with Smalltalk (and I love the idea!) is that when I want to save things in Git, or when I want to deploy something minimal, things are so glued with each other that I find difficult to figure out what belongs to me. There are also other problems: - a desktop app cannot look like a regular one, at least in Pharo. - I am not sure how to glue native code, so when doing graphics stuff (this is what I really want to do with Pharo bc of its interactivity) I did not know how to consume APIs for drawing. I do not have a lot of training admittedly. The interactivity looks super, super cool! But also you have to change a lot of habits.

rscho 5y ago
Pharo 10 will use a native GUI backend. Also, git is well-integrated.
- germandiago 5y ago
  Yes, I saw git is integrated. The problem is that I am not sure how to use it. Any docs? Probably there were but my visit was some time ago. It would rock to have native GUI. Also, if I could know how to draw graphics... That would be very nice also, because having an interactive environment for graphics is the most awesome stuff that Pharo can offer (me).
  - xkriva11 5y ago
    There is a booklet about Git integration: http://books.pharo.org/booklet-ManageCode/pdf/2019-03-24-ManageCode.pdf http://books.pharo.org/booklet-ManageCode/pdf/2019-03-24-Man... For 2D graphics, Pharo uses Cairo binding named Athens (and Roassal as another convinient layer above that). For 3D, you may be interesting in Godotalk (https://www.youtube.com/watch?v=ncmERef0EFo https://www.youtube.com/watch?v=ncmERef0EFo, https://pharoweekly.wordpress.com/2021/02/03/godotalk/ https://pharoweekly.wordpress.com/2021/02/03/godotalk/)
  - Zenchess 5y ago
    I started working on a raylib binding for pharo using pharo's ffi...I have to say pharo's ffi system is very easy to use. It works and I got a few demos working, but I haven't put in the function calls for most of raylib. https://github.com/Zenchess/pharoRaylib https://github.com/Zenchess/pharoRaylib There's also native pharo smalltalk stuff like athens, woden, and maybe others... Personally I have moved to using Dolphin Smalltalk and raylib bindings there as it's been more performant and I prefer Dolphin over pharo. Dolphin also has good external interfacing support and is more of a native Windows OS smalltalk distro. If you're looking for building native windows looking applications on windows at least probably your best bet is dolphin and it's free and open source.

TheCondor 5y ago

What do some of you smalltalksters do with it? I've had a daydream that some sort of data Swiss army knife/visualizer toolkit would be a fun project but it lacks the share ability of notebooks. Are there other operational sorts of things you use smalltalk for? I have a set of scripts and tools I use daily for work (things that slice and dice our data, perform various operational tasks against AWS, etc..) that I could see cooking in to some sort of smalltalk system but I haven't done it.

ynniv 5y ago
Have you seen https://gtoolkit.com https://gtoolkit.com? https://lepiter.io/feenk/glamorous-toolkit-and-pharo-9q25tavxwfq6z1drwvegd5u9o/ https://lepiter.io/feenk/glamorous-toolkit-and-pharo-9q25tav...
- jboynyc 5y ago
  Also Grafoscopio: https://mutabit.com/repos.fossil/grafoscopio/doc/tip/readme.md.html https://mutabit.com/repos.fossil/grafoscopio/doc/tip/readme....

AlbertCory 5y ago

This is heartening. It was hugely influential on the Xerox Star and by extension, Lisa and Mac, even though we didn't actually write in it. It showed you a different way of thinking about things. But for anyone saying they learned Smalltalk in the Elder Days (1980s): No, you didn't. In [1] I discuss learning it in 1978, and there was an icon prototype written in Smalltalk that same year. [1] https://www.albertcory.io https://www.albertcory.io

rbanffy 5y ago

What is the current state of multi-core and multi-threading in Smalltalk? I remember Squeak wouldn’t use more than one core and one OS process and would implement threads in itself, but that was a very long while ago.

jecel 5y ago
The 2008 RoarVM project allowed Squeak to run on a 56 core Tilera chip and was later ported to run on multiprocessor x86 machines: https://stefan-marr.de/renaissance/ https://stefan-marr.de/renaissance/ https://github.com/smarr/RoarVM https://github.com/smarr/RoarVM This was a research project so performance on a single core was poor compared to the official Squeak virtual machine, but it was an interesting exploration of the natural fit between objects/message passing and multiple cores.
- rbanffy 5y ago
  Thanks, Jecel. Good to see you around. It is indeed a natural fit to many core architectures. I frequently mused about giving every message process its own thread. I’ll read the papers you mentioned.

tarkin2 5y ago

Smalltalk has the unrivaled ability to explore and change your environment graphically, and for the changes to persist. Only the web with the developer console comes close, and the changes aren't persistent. Binary image-based development with serialisation, now we aren't all trying to make exes, should be more of a thing.

sebastianconcpt 5y ago

If feels like you build the environment to match the problem, not figure out how to describe your problem on the terms of your language. Yes. Correct. That was the intention of the language design. Here is described in detail by Dan Ingalls https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

CrankyCanuck 5y ago

I remember learning Smalltalk. Or rather, beating the crap out of the bloody machine it ran on. This was back in 1989...Carleton U in Ottawa. The CompSci faculty was all-in on the glory of Smalltalk. We had to learn it on old (even then) Apple Lisa machines running some sort of Mac emulation to run Smalltalk-80. Occasionally, the Lisa would eat your diskette...and you had to rip the case apart to pry it out. We were told Smalltalk was the future...seemed no one was offering jobs in Smalltalk though...just a whole lot of dBaseIV. Must admit, it was fun, and cute...but it had no chance of paying my bills at the time.