5 ms·

Do i really need to use the ide to 'get' smalltalk? I'm pretty happy with my tools, and would only use ST for the paradigm shift anyway. I don't want to leave m

Do i really need to use the ide to 'get' smalltalk? I'm pretty happy with my tools, and would only use ST for the paradigm shift anyway. I don't want to leave my text editor. It has become a part of me, and i can't imagine life without it.

gnaritas 15y ago
Yes, you do. Smalltalk is a running object model and the IDE lets you modify that model while it's running. There are no files. Changes apply instantly. You can pull up some test data, and code it while it's running changing things as fast as you can think until it works the way you want. To the best of my knowledge, there exists no faster environment to think and code in. SLIME come close, but it's too textual and doesn't seem as fast.
- fractallyte 15y ago
  Didn't Lisp machines provide an analogous environment? The Smalltalk VM provides access to the entire 'OS'; only the hardware is abstracted away. Surely a similar Lisp VM is possible now?
  - gnaritas 15y ago
    I'm not talking about what's possible, simply what is. Emacs is what's equivalent to a Smalltalk environment for Lisp today.
mronge 15y ago
The short answer is yes, you need to use the environment to fully grok Smalltalk. Much of the power of Smalltalk comes from the environment. It is pretty amazing how even now parts of Smalltalk are more sophisticated than todays programming tools.
- da02 15y ago
  It might have to do with how Smalltalk/Squeak comes from people who believed the OS is stuff that you wanted in the language. Dan Ingalls: "An operating system is a collection of things that don't fit into a language. There shouldn't be one." http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.h... Alan Kay mentions this idea in relation to Lisp and Smalltalk: http://www.youtube.com/watch?v=tQg4LquY0uU http://www.youtube.com/watch?v=tQg4LquY0uU (It's buried somewhere after 24 minutes.)
jcromartie 15y ago
Just to play devil's advocate to some of the other comments, there is GNU Smalltalk: http://smalltalk.gnu.org/ http://smalltalk.gnu.org/ It's tagline is "The Smalltalk for those who can type". However it doesn't look very lively, and you'd be pretty lonely. I don't know any projects using GNU ST. Squeak, and now Pharo, are really the only implementations with momentum right now. And as far as the typing thing... I am a die-hard Emacs user, and I still enjoy Pharo. This is because programming in Smalltalk is not so much about writing and editing code as it is working with objects. And, frankly, Smalltalk's way of working with objects (and remember: classes and their methods are just objects) is much more powerful than the average editor's way of working with source code.
- fractallyte 15y ago
  The developers at ObjectFusion (http://www.objectfusion.fr/ http://www.objectfusion.fr/) appear to do much of their development in GNU Smalltalk. That's: Iliad web framework, Odyssey CMS, and possibly the upcoming Smalltalk Hub (the equivalent of GitHub, and an anticipated replacement for SqueakSource).
  - gecko 15y ago
    Unless I'm badly mistaken, SmalltalkHub is now developed on, and for, Pharo, not GNU Smalltalk. I have no insight into the reason for that change, however. (I'm basing this on the code for SmalltalkHub, which at least used to be available on SmalltalkHub, and which had Pharoisms in the code base. It's entirely possible they simply moved those pieces over to GNU Smalltalk, though.)
- gecko 15y ago
  GNU Smalltalk's actually decently lively, in my opinion. Its lack of updates has a lot more to do with the core being stable than anything else. The two problems I have with it are simply that it's far slower than Pharo or Squeak, and that using the GPL for a Smalltalk makes me extremely nervous, since the concept of a derivative work gets really dicey when any half-decent Smalltalk app is going to end up throwing new methods into the base library.
fractallyte 15y ago
When Smalltalk methods are so short (averaging between 6-8 lines) it hardly makes sense to focus on its text editing aspects. This is part of the paradigm shift!
- kencausey 15y ago
  Absolutely! This is why complex editing features don't thrive in the most Smalltalk environments; they simply aren't often used. Heck, 6-8 lines is a long Smalltalk method, time to consider refactoring. ;)
  - gnosis 15y ago
    That's nice. But I have a feeling there isn't just one method in your whole program. Having such short methods probably means that you'll wind up with many of them in most useful programs. That means that you'll be spending a fair bit of your time editing, which means that you'll want the ability to use your editor of choice, rather than being forced to use someone else's editor of choice.
    - fractallyte 15y ago
      Smalltalk programs typically consist of many short methods woven together in a pure OO fashion. Thus the focus is more on program structure than actual editing. This has follow-on effects: refactoring, TDD and patterns are so much easier when the code resides in tiny snippets. It's a whole new world, where the code is 'live' rather than merely contained in static 'dead' text files...
- gecko 15y ago
  I also think it's important to point out that Pharo and Squeak do have a rich set of keybindings, so it's not as if you have to do mouse-based development if you don't want to. The editor may be a bit weak, but the general keyboard situation is pretty good.
akkartik 15y ago
I found myself nodding to this bit of the article: "Intellectually I know that it’s really hard to lose changes in a Smalltalk image, but it still feels fragile to me not to have files readable by an external tool." It has nothing to do with how reliable smalltalk is. With such an alien paradigm I'm sure I'll screw up and lose code somewhere and have no way of knowing how it happened. Perhaps putting code in a binary image has also hindered the spread of smalltalk? I see fewer code fragments of smalltalk than I do of say lisp. (I'd love pointers to more smalltalk code reading.)
- gecko 15y ago
  Code actually is not in the image, and I wish that the article weren't conflating that with what actually happens, which is at once better and worse. The image is just bytecode and a bunch of predefined objects. So where does your source code live? Inside of a file called YourImageName.changes, which contains every single line of Smalltalk you execute, including everything from class definitions to method renames to one-offs in workspaces and so on. If you blow up your image, you simply start with a new one, open a change sorter on your old .changes file, and file in the exact pieces you want, skipping over the part where you, say, accidentally did "Integer become: Boolean" or something equally stupid. So far, so good: your code is indeed in text, and it's always up-to-date, and it's trivially machine parsable. So what's the issue? The issue, for me, is that there isn't, by default, a dump of code that represents your program as it exists right now. With that trivial change, using traditional source-control becomes a royal pain the ass, if not outright impossible. That's why you see almost zero Smalltalk code on sites like GitHub, even though the community's active: they end up developing their own systems, such as Monticello, and their own hosting solutions, like SqueakSource and SmalltalkHub, that work with Smalltalk .changes files, rather than Smalltalk code living in text files. If Smalltalk made one-file-per-class, or something similar, the default, and if it automatically generated "compacted" changes on a regular basis (basically a .changes with all of the stuff you deleted thrown out--in other languages, you'd call these the source files), then I think it'd go a long way to helping adoption. Hell, as a side-benefit, writing Smalltalk code in Emacs would be a lot easier, for those who like that particular path. But in the meantime, that's the way things work.
jamesladd 15y ago
For people who cant live without files and their associated tools, AND they have to run on the JVM there is Redline Smalltalk. http://redline.st http://redline.st Use the tools you are used to, use the language that is super productive and run the result on the JVM.

gnaritas 15y ago

Yes, you do. Smalltalk is a running object model and the IDE lets you modify that model while it's running. There are no files. Changes apply instantly. You can pull up some test data, and code it while it's running changing things as fast as you can think until it works the way you want. To the best of my knowledge, there exists no faster environment to think and code in. SLIME come close, but it's too textual and doesn't seem as fast.

fractallyte 15y ago
Didn't Lisp machines provide an analogous environment? The Smalltalk VM provides access to the entire 'OS'; only the hardware is abstracted away. Surely a similar Lisp VM is possible now?
- gnaritas 15y ago
  I'm not talking about what's possible, simply what is. Emacs is what's equivalent to a Smalltalk environment for Lisp today.

mronge 15y ago

The short answer is yes, you need to use the environment to fully grok Smalltalk. Much of the power of Smalltalk comes from the environment. It is pretty amazing how even now parts of Smalltalk are more sophisticated than todays programming tools.

da02 15y ago
It might have to do with how Smalltalk/Squeak comes from people who believed the OS is stuff that you wanted in the language. Dan Ingalls: "An operating system is a collection of things that don't fit into a language. There shouldn't be one." http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.h... Alan Kay mentions this idea in relation to Lisp and Smalltalk: http://www.youtube.com/watch?v=tQg4LquY0uU http://www.youtube.com/watch?v=tQg4LquY0uU (It's buried somewhere after 24 minutes.)

jcromartie 15y ago

Just to play devil's advocate to some of the other comments, there is GNU Smalltalk: http://smalltalk.gnu.org/ http://smalltalk.gnu.org/ It's tagline is "The Smalltalk for those who can type". However it doesn't look very lively, and you'd be pretty lonely. I don't know any projects using GNU ST. Squeak, and now Pharo, are really the only implementations with momentum right now. And as far as the typing thing... I am a die-hard Emacs user, and I still enjoy Pharo. This is because programming in Smalltalk is not so much about writing and editing code as it is working with objects. And, frankly, Smalltalk's way of working with objects (and remember: classes and their methods are just objects) is much more powerful than the average editor's way of working with source code.

fractallyte 15y ago
The developers at ObjectFusion (http://www.objectfusion.fr/ http://www.objectfusion.fr/) appear to do much of their development in GNU Smalltalk. That's: Iliad web framework, Odyssey CMS, and possibly the upcoming Smalltalk Hub (the equivalent of GitHub, and an anticipated replacement for SqueakSource).
- gecko 15y ago
  Unless I'm badly mistaken, SmalltalkHub is now developed on, and for, Pharo, not GNU Smalltalk. I have no insight into the reason for that change, however. (I'm basing this on the code for SmalltalkHub, which at least used to be available on SmalltalkHub, and which had Pharoisms in the code base. It's entirely possible they simply moved those pieces over to GNU Smalltalk, though.)
gecko 15y ago
GNU Smalltalk's actually decently lively, in my opinion. Its lack of updates has a lot more to do with the core being stable than anything else. The two problems I have with it are simply that it's far slower than Pharo or Squeak, and that using the GPL for a Smalltalk makes me extremely nervous, since the concept of a derivative work gets really dicey when any half-decent Smalltalk app is going to end up throwing new methods into the base library.

fractallyte 15y ago

When Smalltalk methods are so short (averaging between 6-8 lines) it hardly makes sense to focus on its text editing aspects. This is part of the paradigm shift!

kencausey 15y ago
Absolutely! This is why complex editing features don't thrive in the most Smalltalk environments; they simply aren't often used. Heck, 6-8 lines is a long Smalltalk method, time to consider refactoring. ;)
- gnosis 15y ago
  That's nice. But I have a feeling there isn't just one method in your whole program. Having such short methods probably means that you'll wind up with many of them in most useful programs. That means that you'll be spending a fair bit of your time editing, which means that you'll want the ability to use your editor of choice, rather than being forced to use someone else's editor of choice.
  - fractallyte 15y ago
    Smalltalk programs typically consist of many short methods woven together in a pure OO fashion. Thus the focus is more on program structure than actual editing. This has follow-on effects: refactoring, TDD and patterns are so much easier when the code resides in tiny snippets. It's a whole new world, where the code is 'live' rather than merely contained in static 'dead' text files...
gecko 15y ago
I also think it's important to point out that Pharo and Squeak do have a rich set of keybindings, so it's not as if you have to do mouse-based development if you don't want to. The editor may be a bit weak, but the general keyboard situation is pretty good.

akkartik 15y ago

I found myself nodding to this bit of the article: "Intellectually I know that it’s really hard to lose changes in a Smalltalk image, but it still feels fragile to me not to have files readable by an external tool." It has nothing to do with how reliable smalltalk is. With such an alien paradigm I'm sure I'll screw up and lose code somewhere and have no way of knowing how it happened. Perhaps putting code in a binary image has also hindered the spread of smalltalk? I see fewer code fragments of smalltalk than I do of say lisp. (I'd love pointers to more smalltalk code reading.)

gecko 15y ago
Code actually is not in the image, and I wish that the article weren't conflating that with what actually happens, which is at once better and worse. The image is just bytecode and a bunch of predefined objects. So where does your source code live? Inside of a file called YourImageName.changes, which contains every single line of Smalltalk you execute, including everything from class definitions to method renames to one-offs in workspaces and so on. If you blow up your image, you simply start with a new one, open a change sorter on your old .changes file, and file in the exact pieces you want, skipping over the part where you, say, accidentally did "Integer become: Boolean" or something equally stupid. So far, so good: your code is indeed in text, and it's always up-to-date, and it's trivially machine parsable. So what's the issue? The issue, for me, is that there isn't, by default, a dump of code that represents your program as it exists right now. With that trivial change, using traditional source-control becomes a royal pain the ass, if not outright impossible. That's why you see almost zero Smalltalk code on sites like GitHub, even though the community's active: they end up developing their own systems, such as Monticello, and their own hosting solutions, like SqueakSource and SmalltalkHub, that work with Smalltalk .changes files, rather than Smalltalk code living in text files. If Smalltalk made one-file-per-class, or something similar, the default, and if it automatically generated "compacted" changes on a regular basis (basically a .changes with all of the stuff you deleted thrown out--in other languages, you'd call these the source files), then I think it'd go a long way to helping adoption. Hell, as a side-benefit, writing Smalltalk code in Emacs would be a lot easier, for those who like that particular path. But in the meantime, that's the way things work.

jamesladd 15y ago

For people who cant live without files and their associated tools, AND they have to run on the JVM there is Redline Smalltalk. http://redline.st http://redline.st Use the tools you are used to, use the language that is super productive and run the result on the JVM.