7 ms·

Why Every Ruby Developer Should Learn Smalltalk

106 points by bitops 14y ago

asolove 14y ago
This should really be "Why every developer should learn Smalltalk." Dan Ingalls gave a keynote at jsconf demoing Lively Kernel, a SmallTalk-like, image-based, in-browser IDE written in JavaScript. His demo received a standing ovation and was the thing I heard talked about most during the social events. We're obviously not far from being able to have SmallTalk-quality interactions with things we build in the browser. Brent Victor's recent talk has spurred a lot of work on more-interactive development environments, some of them in the browser. I would really like an old SmallTalker to spend some time researching and thinking about the old tools they had: which were valuable, which were more trouble then they were worth? What mistakes did they make that they wish they had done differently? It would be an excellent briefing for the next few years of work on the web.
- stcredzero 14y ago
  (A small note: it's traditional to not capitalize the t in Smalltalk. Old-timers take that as a signal that text was written by a non-dev.) thinking about the old tools they had: which were valuable, which were more trouble then they were worth? A seasoned Smalltalker would have spent more time talking about the Debugger. I was teaching a Smalltalk class once, and this one student who was a quant from a New York financial firm just spontaneously exclaimed: "This debugger is from God!" It was very fast, responsive, and was "well integrated" with the environment. More on that... EDIT: As I took the time to say elsewhere, there really isn't that much "integration." It's more that the environment is so minimalist that it lacks many barriers present in other environments. Just about every single instance of every object has the equivalent of a REPL, and finding a particular instance in the middle of runtime debugging typically takes just a second. Even the "IDE" really isn't one. (And I should know, because I've written a good portion of a commercial Smalltalk browser.) Aside from the refactoring mechanisms, it's a pretty lightweight and basic browser on objects -- it just so happens they're the meta-level. What mistakes did they make that they wish they had done differently? A big mistake: exorbitant per-seat developer licenses, and positioning as the "secret weapon" of the Fortune 500. Another oft-cited one was the Parcplace/Digitalk merger and the ensuing conflicts. Most of the mistakes had to do with community and how the ecosystem did/didn't interact with the rest of the programming world. Technologically, there was a lot of goodness.
  - asolove 14y ago
    Thanks for both the small note and the big suggestion. What did the debugger have that made it "well integrated"? In JavaScript, we have fairly good graphical tools in Chrome. One headache is debugging asynchronous code, and a good debugger could track not just the current call stack, but the deeper "reason" why this code is running, including timers, events, xhr callbacks, and let us jump between those levels as opposed to just the function calls.
    - stcredzero 14y ago
      What did the debugger have that made it "well integrated"? It's more what the environment didn't have. Everything, including almost all of the meta-level (and by almost, I think it's just 3 Classes that are treated specially by the VM) was just an ordinary object. Even throwing an exception was just Smalltalk executing as usual. Basically, there were no barriers. (EDIT: An example mentioned elsewhere -- the integration between the Debugger and Unit Tests. It's not rocket science. You just catch an exception and pass an object to the Debugger.) One headache is debugging asynchronous code, and a good debugger could track not just the current call stack, but the deeper "reason" why this code is running, including timers, events, xhr callbacks, and let us jump between those levels as opposed to just the function calls. It wasn't unusual in VisualWorks for us to have multiple call stack open at the same time. (In fact, some people would put code to evaluate in comments, which could be executed in the midst of another debug session.) Timers, events, Semaphores -- these are all just Objects, subject to the same kind of manipulation. This isn't to say there wasn't some pain around concurrency, because there was that. But a competent programmer felt confident about dealing with it, because she/he had such responsive tools and no barriers to what they could do and see.
      - angersock 14y ago
        What sort of issues did you observe with concurrency and Smalltalk?
        stcredzero 14y ago
- sebastianconcpt 14y ago
  We are already having them: 1. go here: http://amber-lang.net/ http://amber-lang.net/ 2. click "Open Browser" 3. start having nerdgasms
irahul 14y ago
forecast := service forecastForDays: 5 format: 'Xml'. The equivalent ruby is shown as: forecast = server.forecastForDaysInFormat(5, "xml") The example is illustrative, and a ruby code in the wild will generally use positional arguments or pass hashes around, rather than implementing weirdly named methods: forecast = server.forecast(5, "xml") forecast = server.forecast(days: 5, format: "xml") That is not to say weirdly named methods aren't used. Activerecord dynamic finders are one example that comes to mind `Model.find_by_first_name_and_last_name`, but they are named so to provide information to method_missing hook. > If you need to pass multiple blocks to a method in Ruby it always looks clunky and probably that's why it's not a common idiom: service.forecastFor ->{puts "Do stuff"}, ->{puts "handling errors"} I don't think the examples are clunky at all. It is similar in all languages which treat functions as first class datatypes. In ruby, you use "one block" or pass multiple lambdas. It isn't any different from smalltalk example, except for superficial syntactic difference. > When you start writing a new app in Smalltalk you don't open Emacs or RubyMine you launch a VM. I don't know much about Smalltalk, but this IDE/VM approach must be damn substantive to make up for not using Vim. The way the article puts it makes it sounds like "don't open Emacs" is a positive, which is seldom the case with people who use a lot of emacs/vim.
- stcredzero 14y ago
  I don't know much about Smalltalk, but this IDE/VM approach must be damn substantive to make up for not using Vim. The thing about the IDE, is that there's hardly any of it there. It's all just objects that each effectively have their own REPL, and you're directly manipulating all of them. You can actually start writing a debugger in most Smalltalk environments, and you'll have something that lets you browse a stack trace in under 5 minutes. (If you know the API for dealing with stack traces. A newb or someone out of practice will take longer, but most of it will be reading the API.) An engineer I know was bored in his "Intro to Smalltalk" class and spent 10 minutes writing a tool that compiles and evaluates code. The exact same code made it into the production "IDE" and was there for over a decade. The thing is, there's such an amazing amount of "integration" in the environment, you'd think there was tons of ingenious code written by teams of geniuses, but there isn't. It's just that a lot of unnecessary stuff has been removed and made runtime, so everything is available for you to see and change. It's one of the best examples of how minimalism can work very well.
RandallBrown 14y ago
This is one of the reasons I like objective-c. Lots of people hate its verbosity, but I love that you can almost read it like english (assuming you name stuff sanely).
- gurehamu 14y ago
  A word of caution... :) I had a similar experience with Obj-C and decided to give smalltalk a try. After a brief struggle and period of wetware refactoring, I can longer stand to work in anything else.
sktrdie 14y ago
SHUT THE FUCK UP I DONT WANNA LEARN THIS SHIT
- angersock 14y ago
  You must be a hit at parties. I know this, because you sure as hell aren't spending that time doing something useful and worthwhile. EDIT: [REDACTED] EDIT2: In hindsight, probably not nice to make fun of somebody's product. I know I wouldn't appreciate it.
  - parsnips 14y ago
    Rails programmers insulting .net guys is sort of like two step children fighting. Except you're the red headed one.
    - angersock 14y ago
      Rails is a small hobby--day job is paying the bills with Java. I mostly hack C and C++, graphics, games, containers, tests--take your pick, coffee and pistols for two at dawn. :)
    - parsnips 14y ago
      I think we can be best friends.
  - sktrdie 14y ago
    i'm just tired of these front page stories about advising people to learn new languages because of stupid reasons such as "It’s much closer to English that, for instance, Ruby"
    - angersock 14y ago
      There were several other things the author mentioned--though I will admit I found that first part of the first reason somewhat silly. The thing is, you really ought to expose yourself and at least play around in other languages. No language (except, perhaps, APL, assembly, Forth, Lisp, or Prolog [not that there exists a standard variant of the last two]) is perfect. Every language does some things really well, other things really poorly, and muddles through the rest. Being familiar with other helps you know when your language of choice might need to call out to something better suited to your problem domain.
rauljara 14y ago
I love reading introductions to languages. But holding them up in comparison to just one other language is often problematic. I don't think this article does ruby much justice (e.g. the syntax stuff, and especially the bit about ruby's lack of debugging tools: https://github.com/pry/pry https://github.com/pry/pry). I found myself wanting to defend ruby. Which is very distracting, and entirely beside the point, because really I just wanted to learn a little bit more about smalltalk.
- bromagosa 14y ago
  I guess the point of the author is that no language can have a debugger as powerful as Smalltalk's, as having the code, the state and the tools live in the same environment is the only way you can go as deep as Smalltalk debuggers go. If you're editing your code in an editor, running it in an interpreter and storing the state in your RAM, there's no way your editor is gonna be able to stop at a point of your stack to let you modify a piece of code live, or add a method, or override an operator, or change the class of a living object and continue as if nothing ever happened.
  - vidarh 14y ago
    That's pretty much what Pry provides for Ruby. It might not be as polished as the Smalltalk tools yet, but there's no inherent problem doing this with Ruby. There might be some things you can't do in pure Ruby, such as perhaps replacing a class pointer to actually change the class of an object, but low level hackery like that is easily enough done with a small C extension - I've poked around in MRI's C-level view of the object model before and it's pretty simple.
barik 14y ago
Can anyone provide a suggestion on what to use to learn Smalltalk under Windows? The article mentions both Squeak and Pharo, of which only I've used Squeak briefly in college, but there I really had a hard time with the interface. At least I felt like I completely hosed my Smalltalk VM more than once. I have not tried Pharo. It appears that there is also Dolphin Smalltalk. Thanks!
- cwp 14y ago
  Squeak, Pharo, VisualWorks and Dolphin will all work fine on Windows. Squeak and Pharo (and VisualWorks to a lesser degree) have non-standard UIs that will be (a little) unfamiliar to Windows users. Dolphin's UI should be the most familiar.
- stcredzero 14y ago
  I've used Squeak briefly in college, but there I really had a hard time with the interface. Well, they have a "burn the diskpacks" philosophy, so the interface is very different and changes a lot of conventions. At least I felt like I completely hosed my Smalltalk VM more than once. This is something very different and weird you'd have to get used to. Hosing your VM is actually no big deal. There's a way to recover from that quickly without losing any source code changes. I would try Pharo. Dolphin was a nice environment, but that was so long ago. (Since Smalltalk gives you the power to do anything, even with your meta-level, it >has< to work like this. Otherwise, people would feel timid about manipulating their meta-level.)
- bromagosa 14y ago
  Check out Amber! It's browser-based! The online ProfStef tutorial (which is based on Pharo's ProfStef tutorial) is quite comprehensive: http://amber-lang.net/learn.html http://amber-lang.net/learn.html
- fusiongyro 14y ago
  Start with Pharo.
- radiowave 14y ago
  At this point, I'd say Pharo is the most actively developed, and the most polished, of the open source Smalltalk implementations. There's been a fair amount of work cleaning up the UI since they forked from Squeak, and the free ebook "Pharo By Example" has a good overview of the UI and development tools in the opening chapter. http://www.pharobyexample.org/ http://www.pharobyexample.org/
ajross 14y ago
It amuses me greatly to see it point out how much more readable Smalltalk's method syntax is (i.e. "it skips the . operator") immediately before launching into an example of how great Smalltalk is that it doesn't have an if() construct and needs to define methods to dispatch on conditions. Smalltalk is great (mostly for historic reasons these days) and definitely worth learning. But that bit is cognitive dissonance at its best.
- stcredzero 14y ago
  it doesn't have an if() construct and needs to define methods to dispatch on conditions. Smalltalk is great (mostly for historic reasons these days) and definitely worth learning. But that bit is cognitive dissonance at its best. It allows you to extend even the Boolean Logic of your system. With just an ordinary act of defining functions, you can implement something like: (condition) ifTrue: [ "true" ] ifFalse: [ "wasn't true" ] ifMaybe: [ "whoa, toy fuzzy logic!" ] The same goes for looping and other control structures. This makes any DSL you write a first-class language construct equal to anything else in the language.
  - ajross 14y ago
    I know. What it is not is "clear", for any definition of the term understood by a working programmer who doesn't already know the language and grok the new abstraction. The point was that this followed immediately an explanation of how much more readable (!) the OO syntax was because there was no separate operator (".") for method invocation. If the former is seriously a criteria for "being better than ruby", the Smalltalk condition trick is an abomination, and immensely inferior. edit to avoid thread continuation: yet again the response boils down to "it's easy if you know it". So to be clear: 1.) I do know it; and 2.) Duh. But the previous point in the blog post seems to be predicated on the idea that learning the "." operator for method dispatch in ruby is somehow "hard" and that it's an advantage to Smalltalk that it has such a straightforward syntax. Those two opinions cannot logically be held in the same brain.
    - stcredzero 14y ago
Porter_423 14y ago
I spent several years as a Smalltalk developer and now I'm a decently proficient Rails developer. SmallTalk is about as close to coding perfection as you're ever going to get and the IDE just puts it over the top. If you havn't coded in your own debugger, dropped stack and started coding all over again you've missed out on something wonderful. I hope someday, someone will be able to resurrect the greatest OOP language I've ever known and make it relevant on the web.
overgard 14y ago
I used to do smalltalk for a job (internship, but still learned a lot). I love it, it's a terribly under-appreciated language. I think what ended up sidelining it was that it didn't really integrate well with the rest of the system. Part of this was the syntax, even though you could bridge it with C, it was awkward. IE, "something.f(a,b,c)" would become "something f: a with: b with: c". Smalltalk's syntax is really cool when you're just working within the smalltalk system itself, but at the edges it gets clunky. The other problem is smalltalk just seems to like living in its own world. Even now that's largely the case. (Fun challenge: try making a smalltalk app that isn't easily recognizable as a smalltalk app.) Given what Clojure is to lisp, I hope too there can be a "Clojure for smalltalk", if you will. Something that captures what's really cool about the language but throws away the historical baggage and makes it integrate well with the rest of the system.
- saurik 14y ago
  FWIW, a lot of people like Objective-C, and it uses that same colon infix syntax.
  - overgard 14y ago
    Objective-C certainly borrows the syntax, but that syntax is a second-class citizen in the C world. That removes its negative bits (interoperability), but it also removes most of its positive bits too (ie, uniformity, being able to construct new language primitives, everything-is-a-message, etc.))
    - saurik 14y ago
      My point was that the colon infix syntax, which you seem to be claiming is awkward (but maybe I don't understand your sentence construction) is something a lot of people actually consider a feature.
- protomyth 14y ago
  F-Script seems to be an OS X specific attempt.
- 14y ago
KentBeck 14y ago
There are lots of good points made here, but I'll add one: write the environment in itself. The original vision for Smalltalk is that you would be using some application, get curious about how it worked (or want to change it), press ctrl-C to start a debugger, start reading code, start editing, get curious about how the debugger works, press ctrl-C again, start reading code, start editing... That smooth progression from application user to programmer to tool developer was a conscious design goal of Smalltalk (also of Lisp), and has gotten lost somewhere along the way. Once you take responsibility for your own tools you quickly learn to use your new-found powers sparingly, but it's a completely different feeling being a programmer in an environment you can modify than being a programmer in an environment someone else made and you can't touch.
suyash 14y ago
I know a good iPhone programmer and he credits a lot to learning smalltalk before Objective C to make it a breeze, good to hear from Ruby folks as well! I'm definitely learning it soon!
_exec 14y ago
Okay, I'm sold. What books does HN recommend for learning Smalltalk effectively?
- fractallyte 14y ago
  There's a great collection of free books at: http://stephane.ducasse.free.fr/FreeBooks.html http://stephane.ducasse.free.fr/FreeBooks.html I found the following particularly useful: 'Smalltalk by Example', by Alex Sharp; 'Smalltalk With Style', by Edward Klimas, Suzanne Skublics and David A Thomas. This is a great book for beginners in any OO language: 'Smalltalk, Objects, and Design', by Chamond Liu Also surprisingly useful (terse, but well structured): 'On To Smalltalk', by Patrick Henry Winston Finally, there's the excellent ProfStef interactive tutorial that's included with Pharo (http://www.pharocasts.com/2010/01/learn-smalltalk-with-profstef.html http://www.pharocasts.com/2010/01/learn-smalltalk-with-profs...).

106 points by bitops 14y ago

This should really be "Why every developer should learn Smalltalk." Dan Ingalls gave a keynote at jsconf demoing Lively Kernel, a SmallTalk-like, image-based, in-browser IDE written in JavaScript. His demo received a standing ovation and was the thing I heard talked about most during the social events. We're obviously not far from being able to have SmallTalk-quality interactions with things we build in the browser. Brent Victor's recent talk has spurred a lot of work on more-interactive development environments, some of them in the browser. I would really like an old SmallTalker to spend some time researching and thinking about the old tools they had: which were valuable, which were more trouble then they were worth? What mistakes did they make that they wish they had done differently? It would be an excellent briefing for the next few years of work on the web.

stcredzero 14y ago
(A small note: it's traditional to not capitalize the t in Smalltalk. Old-timers take that as a signal that text was written by a non-dev.) thinking about the old tools they had: which were valuable, which were more trouble then they were worth? A seasoned Smalltalker would have spent more time talking about the Debugger. I was teaching a Smalltalk class once, and this one student who was a quant from a New York financial firm just spontaneously exclaimed: "This debugger is from God!" It was very fast, responsive, and was "well integrated" with the environment. More on that... EDIT: As I took the time to say elsewhere, there really isn't that much "integration." It's more that the environment is so minimalist that it lacks many barriers present in other environments. Just about every single instance of every object has the equivalent of a REPL, and finding a particular instance in the middle of runtime debugging typically takes just a second. Even the "IDE" really isn't one. (And I should know, because I've written a good portion of a commercial Smalltalk browser.) Aside from the refactoring mechanisms, it's a pretty lightweight and basic browser on objects -- it just so happens they're the meta-level. What mistakes did they make that they wish they had done differently? A big mistake: exorbitant per-seat developer licenses, and positioning as the "secret weapon" of the Fortune 500. Another oft-cited one was the Parcplace/Digitalk merger and the ensuing conflicts. Most of the mistakes had to do with community and how the ecosystem did/didn't interact with the rest of the programming world. Technologically, there was a lot of goodness.
- asolove 14y ago
  Thanks for both the small note and the big suggestion. What did the debugger have that made it "well integrated"? In JavaScript, we have fairly good graphical tools in Chrome. One headache is debugging asynchronous code, and a good debugger could track not just the current call stack, but the deeper "reason" why this code is running, including timers, events, xhr callbacks, and let us jump between those levels as opposed to just the function calls.
  - stcredzero 14y ago
    What did the debugger have that made it "well integrated"? It's more what the environment didn't have. Everything, including almost all of the meta-level (and by almost, I think it's just 3 Classes that are treated specially by the VM) was just an ordinary object. Even throwing an exception was just Smalltalk executing as usual. Basically, there were no barriers. (EDIT: An example mentioned elsewhere -- the integration between the Debugger and Unit Tests. It's not rocket science. You just catch an exception and pass an object to the Debugger.) One headache is debugging asynchronous code, and a good debugger could track not just the current call stack, but the deeper "reason" why this code is running, including timers, events, xhr callbacks, and let us jump between those levels as opposed to just the function calls. It wasn't unusual in VisualWorks for us to have multiple call stack open at the same time. (In fact, some people would put code to evaluate in comments, which could be executed in the midst of another debug session.) Timers, events, Semaphores -- these are all just Objects, subject to the same kind of manipulation. This isn't to say there wasn't some pain around concurrency, because there was that. But a competent programmer felt confident about dealing with it, because she/he had such responsive tools and no barriers to what they could do and see.
    - angersock 14y ago
      What sort of issues did you observe with concurrency and Smalltalk?
      - stcredzero 14y ago
sebastianconcpt 14y ago
We are already having them: 1. go here: http://amber-lang.net/ http://amber-lang.net/ 2. click "Open Browser" 3. start having nerdgasms

irahul 14y ago

forecast := service forecastForDays: 5 format: 'Xml'. The equivalent ruby is shown as: forecast = server.forecastForDaysInFormat(5, "xml") The example is illustrative, and a ruby code in the wild will generally use positional arguments or pass hashes around, rather than implementing weirdly named methods: forecast = server.forecast(5, "xml") forecast = server.forecast(days: 5, format: "xml") That is not to say weirdly named methods aren't used. Activerecord dynamic finders are one example that comes to mind `Model.find_by_first_name_and_last_name`, but they are named so to provide information to method_missing hook. > If you need to pass multiple blocks to a method in Ruby it always looks clunky and probably that's why it's not a common idiom: service.forecastFor ->{puts "Do stuff"}, ->{puts "handling errors"} I don't think the examples are clunky at all. It is similar in all languages which treat functions as first class datatypes. In ruby, you use "one block" or pass multiple lambdas. It isn't any different from smalltalk example, except for superficial syntactic difference. > When you start writing a new app in Smalltalk you don't open Emacs or RubyMine you launch a VM. I don't know much about Smalltalk, but this IDE/VM approach must be damn substantive to make up for not using Vim. The way the article puts it makes it sounds like "don't open Emacs" is a positive, which is seldom the case with people who use a lot of emacs/vim.

stcredzero 14y ago
I don't know much about Smalltalk, but this IDE/VM approach must be damn substantive to make up for not using Vim. The thing about the IDE, is that there's hardly any of it there. It's all just objects that each effectively have their own REPL, and you're directly manipulating all of them. You can actually start writing a debugger in most Smalltalk environments, and you'll have something that lets you browse a stack trace in under 5 minutes. (If you know the API for dealing with stack traces. A newb or someone out of practice will take longer, but most of it will be reading the API.) An engineer I know was bored in his "Intro to Smalltalk" class and spent 10 minutes writing a tool that compiles and evaluates code. The exact same code made it into the production "IDE" and was there for over a decade. The thing is, there's such an amazing amount of "integration" in the environment, you'd think there was tons of ingenious code written by teams of geniuses, but there isn't. It's just that a lot of unnecessary stuff has been removed and made runtime, so everything is available for you to see and change. It's one of the best examples of how minimalism can work very well.

RandallBrown 14y ago

This is one of the reasons I like objective-c. Lots of people hate its verbosity, but I love that you can almost read it like english (assuming you name stuff sanely).

gurehamu 14y ago
A word of caution... :) I had a similar experience with Obj-C and decided to give smalltalk a try. After a brief struggle and period of wetware refactoring, I can longer stand to work in anything else.

sktrdie 14y ago

SHUT THE FUCK UP I DONT WANNA LEARN THIS SHIT

angersock 14y ago
You must be a hit at parties. I know this, because you sure as hell aren't spending that time doing something useful and worthwhile. EDIT: [REDACTED] EDIT2: In hindsight, probably not nice to make fun of somebody's product. I know I wouldn't appreciate it.
- parsnips 14y ago
  Rails programmers insulting .net guys is sort of like two step children fighting. Except you're the red headed one.
  - angersock 14y ago
    Rails is a small hobby--day job is paying the bills with Java. I mostly hack C and C++, graphics, games, containers, tests--take your pick, coffee and pistols for two at dawn. :)
  - parsnips 14y ago
    I think we can be best friends.
- sktrdie 14y ago
  i'm just tired of these front page stories about advising people to learn new languages because of stupid reasons such as "It’s much closer to English that, for instance, Ruby"
  - angersock 14y ago
    There were several other things the author mentioned--though I will admit I found that first part of the first reason somewhat silly. The thing is, you really ought to expose yourself and at least play around in other languages. No language (except, perhaps, APL, assembly, Forth, Lisp, or Prolog [not that there exists a standard variant of the last two]) is perfect. Every language does some things really well, other things really poorly, and muddles through the rest. Being familiar with other helps you know when your language of choice might need to call out to something better suited to your problem domain.

rauljara 14y ago

I love reading introductions to languages. But holding them up in comparison to just one other language is often problematic. I don't think this article does ruby much justice (e.g. the syntax stuff, and especially the bit about ruby's lack of debugging tools: https://github.com/pry/pry https://github.com/pry/pry). I found myself wanting to defend ruby. Which is very distracting, and entirely beside the point, because really I just wanted to learn a little bit more about smalltalk.

bromagosa 14y ago
I guess the point of the author is that no language can have a debugger as powerful as Smalltalk's, as having the code, the state and the tools live in the same environment is the only way you can go as deep as Smalltalk debuggers go. If you're editing your code in an editor, running it in an interpreter and storing the state in your RAM, there's no way your editor is gonna be able to stop at a point of your stack to let you modify a piece of code live, or add a method, or override an operator, or change the class of a living object and continue as if nothing ever happened.
- vidarh 14y ago
  That's pretty much what Pry provides for Ruby. It might not be as polished as the Smalltalk tools yet, but there's no inherent problem doing this with Ruby. There might be some things you can't do in pure Ruby, such as perhaps replacing a class pointer to actually change the class of an object, but low level hackery like that is easily enough done with a small C extension - I've poked around in MRI's C-level view of the object model before and it's pretty simple.

barik 14y ago

Can anyone provide a suggestion on what to use to learn Smalltalk under Windows? The article mentions both Squeak and Pharo, of which only I've used Squeak briefly in college, but there I really had a hard time with the interface. At least I felt like I completely hosed my Smalltalk VM more than once. I have not tried Pharo. It appears that there is also Dolphin Smalltalk. Thanks!

cwp 14y ago
Squeak, Pharo, VisualWorks and Dolphin will all work fine on Windows. Squeak and Pharo (and VisualWorks to a lesser degree) have non-standard UIs that will be (a little) unfamiliar to Windows users. Dolphin's UI should be the most familiar.
stcredzero 14y ago
I've used Squeak briefly in college, but there I really had a hard time with the interface. Well, they have a "burn the diskpacks" philosophy, so the interface is very different and changes a lot of conventions. At least I felt like I completely hosed my Smalltalk VM more than once. This is something very different and weird you'd have to get used to. Hosing your VM is actually no big deal. There's a way to recover from that quickly without losing any source code changes. I would try Pharo. Dolphin was a nice environment, but that was so long ago. (Since Smalltalk gives you the power to do anything, even with your meta-level, it >has< to work like this. Otherwise, people would feel timid about manipulating their meta-level.)
bromagosa 14y ago
Check out Amber! It's browser-based! The online ProfStef tutorial (which is based on Pharo's ProfStef tutorial) is quite comprehensive: http://amber-lang.net/learn.html http://amber-lang.net/learn.html
fusiongyro 14y ago
Start with Pharo.
radiowave 14y ago
At this point, I'd say Pharo is the most actively developed, and the most polished, of the open source Smalltalk implementations. There's been a fair amount of work cleaning up the UI since they forked from Squeak, and the free ebook "Pharo By Example" has a good overview of the UI and development tools in the opening chapter. http://www.pharobyexample.org/ http://www.pharobyexample.org/

ajross 14y ago

It amuses me greatly to see it point out how much more readable Smalltalk's method syntax is (i.e. "it skips the . operator") immediately before launching into an example of how great Smalltalk is that it doesn't have an if() construct and needs to define methods to dispatch on conditions. Smalltalk is great (mostly for historic reasons these days) and definitely worth learning. But that bit is cognitive dissonance at its best.

stcredzero 14y ago
it doesn't have an if() construct and needs to define methods to dispatch on conditions. Smalltalk is great (mostly for historic reasons these days) and definitely worth learning. But that bit is cognitive dissonance at its best. It allows you to extend even the Boolean Logic of your system. With just an ordinary act of defining functions, you can implement something like: (condition) ifTrue: [ "true" ] ifFalse: [ "wasn't true" ] ifMaybe: [ "whoa, toy fuzzy logic!" ] The same goes for looping and other control structures. This makes any DSL you write a first-class language construct equal to anything else in the language.
- ajross 14y ago
  I know. What it is not is "clear", for any definition of the term understood by a working programmer who doesn't already know the language and grok the new abstraction. The point was that this followed immediately an explanation of how much more readable (!) the OO syntax was because there was no separate operator (".") for method invocation. If the former is seriously a criteria for "being better than ruby", the Smalltalk condition trick is an abomination, and immensely inferior. edit to avoid thread continuation: yet again the response boils down to "it's easy if you know it". So to be clear: 1.) I do know it; and 2.) Duh. But the previous point in the blog post seems to be predicated on the idea that learning the "." operator for method dispatch in ruby is somehow "hard" and that it's an advantage to Smalltalk that it has such a straightforward syntax. Those two opinions cannot logically be held in the same brain.
  - stcredzero 14y ago

Porter_423 14y ago

I spent several years as a Smalltalk developer and now I'm a decently proficient Rails developer. SmallTalk is about as close to coding perfection as you're ever going to get and the IDE just puts it over the top. If you havn't coded in your own debugger, dropped stack and started coding all over again you've missed out on something wonderful. I hope someday, someone will be able to resurrect the greatest OOP language I've ever known and make it relevant on the web.

overgard 14y ago

I used to do smalltalk for a job (internship, but still learned a lot). I love it, it's a terribly under-appreciated language. I think what ended up sidelining it was that it didn't really integrate well with the rest of the system. Part of this was the syntax, even though you could bridge it with C, it was awkward. IE, "something.f(a,b,c)" would become "something f: a with: b with: c". Smalltalk's syntax is really cool when you're just working within the smalltalk system itself, but at the edges it gets clunky. The other problem is smalltalk just seems to like living in its own world. Even now that's largely the case. (Fun challenge: try making a smalltalk app that isn't easily recognizable as a smalltalk app.) Given what Clojure is to lisp, I hope too there can be a "Clojure for smalltalk", if you will. Something that captures what's really cool about the language but throws away the historical baggage and makes it integrate well with the rest of the system.

saurik 14y ago
FWIW, a lot of people like Objective-C, and it uses that same colon infix syntax.
- overgard 14y ago
  Objective-C certainly borrows the syntax, but that syntax is a second-class citizen in the C world. That removes its negative bits (interoperability), but it also removes most of its positive bits too (ie, uniformity, being able to construct new language primitives, everything-is-a-message, etc.))
  - saurik 14y ago
    My point was that the colon infix syntax, which you seem to be claiming is awkward (but maybe I don't understand your sentence construction) is something a lot of people actually consider a feature.
protomyth 14y ago
F-Script seems to be an OS X specific attempt.
14y ago

KentBeck 14y ago

There are lots of good points made here, but I'll add one: write the environment in itself. The original vision for Smalltalk is that you would be using some application, get curious about how it worked (or want to change it), press ctrl-C to start a debugger, start reading code, start editing, get curious about how the debugger works, press ctrl-C again, start reading code, start editing... That smooth progression from application user to programmer to tool developer was a conscious design goal of Smalltalk (also of Lisp), and has gotten lost somewhere along the way. Once you take responsibility for your own tools you quickly learn to use your new-found powers sparingly, but it's a completely different feeling being a programmer in an environment you can modify than being a programmer in an environment someone else made and you can't touch.

suyash 14y ago

I know a good iPhone programmer and he credits a lot to learning smalltalk before Objective C to make it a breeze, good to hear from Ruby folks as well! I'm definitely learning it soon!

_exec 14y ago

Okay, I'm sold. What books does HN recommend for learning Smalltalk effectively?

fractallyte 14y ago
There's a great collection of free books at: http://stephane.ducasse.free.fr/FreeBooks.html http://stephane.ducasse.free.fr/FreeBooks.html I found the following particularly useful: 'Smalltalk by Example', by Alex Sharp; 'Smalltalk With Style', by Edward Klimas, Suzanne Skublics and David A Thomas. This is a great book for beginners in any OO language: 'Smalltalk, Objects, and Design', by Chamond Liu Also surprisingly useful (terse, but well structured): 'On To Smalltalk', by Patrick Henry Winston Finally, there's the excellent ProfStef interactive tutorial that's included with Pharo (http://www.pharocasts.com/2010/01/learn-smalltalk-with-profstef.html http://www.pharocasts.com/2010/01/learn-smalltalk-with-profs...).