Getting Back to Smalltalk(railsrx.com)
railsrx.com
Getting Back to Smalltalk
http://railsrx.com/2011/12/29/getting-back-to-smalltalk/
5 comments
Smalltalk actually has two different ways to address things: as sequences, and as streams. Sequences are 1-based, and streams are 0-based. This is designed to model what you intuitively do in real life. As a picture:
I'm not going to tackle whether Djikstra was right or wrong, but merely to point out that there's more to Smalltalk's indexing than meets the eye.
For what it's worth: I'm not a professional Smalltalk dev by any stretch of the imagination, but I've written enough Smalltalk to tell you that you very rarely deal with the indices, anyway. Nearly all Smalltalk code ends up just using comprehensions to navigate collections. Of the remainder, they're such trivial cases that the 1-based indexing is intuitive and does not bother me the way that it does in, say, Lua or really old Turbo Pascal programs where some coder got a bit too slap-happy on arbitrarily bounded arrays.
| 1 | 2 | 3 | 4 |
+-----+-----+-----+-----+
0 1 2 3 4
I'm not going to tackle whether Djikstra was right or wrong, but merely to point out that there's more to Smalltalk's indexing than meets the eye.
For what it's worth: I'm not a professional Smalltalk dev by any stretch of the imagination, but I've written enough Smalltalk to tell you that you very rarely deal with the indices, anyway. Nearly all Smalltalk code ends up just using comprehensions to navigate collections. Of the remainder, they're such trivial cases that the 1-based indexing is intuitive and does not bother me the way that it does in, say, Lua or really old Turbo Pascal programs where some coder got a bit too slap-happy on arbitrarily bounded arrays.
Math vs. Language.
I don't refer to the first inch of a ruler as inch 0 or inch 1, I refer to it as the first inch.
There are two things being described which I think is a set up for confusion and the many off by one errors that I've seen as a result.
But, in my list of 2 items, I index with 1 and 2, not 0 and 1. But, be sure that the first item is 1.0 not 1.1 and the second item is 2.0 not 2.1.
I don't refer to the first inch of a ruler as inch 0 or inch 1, I refer to it as the first inch.
There are two things being described which I think is a set up for confusion and the many off by one errors that I've seen as a result.
1. Coordinate.
2. Interval.
But, in my list of 2 items, I index with 1 and 2, not 0 and 1. But, be sure that the first item is 1.0 not 1.1 and the second item is 2.0 not 2.1.
I'm struggling to find Dijkstra's argument sufficiently compelling to conclude that zero is the 'most natural number'. It's a conclusion based on his aesthetics (plus an anecdotal story).
The natural numbers are generally considered to start at 1. Therefore, to people in general, such a system makes more sense.
The natural numbers are generally considered to start at 1. Therefore, to people in general, such a system makes more sense.
Agreed. The fact that arrays were simple memory-offsets making zero-index easier for low-level programming doesn't make it easier for humans who historically prefer 1-indexing.
Zero is not a "natural" number, in fact many societies / civilizations never even understood or used zero in arithmetic [1].
[1] http://en.wikipedia.org/wiki/Roman_numerals
Zero is not a "natural" number, in fact many societies / civilizations never even understood or used zero in arithmetic [1].
[1] http://en.wikipedia.org/wiki/Roman_numerals
> in fact many societies / civilizations never even understood or used zero in arithmetic
Yeah, but those societies were uniformly terrible at math.
Yeah, but those societies were uniformly terrible at math.
There are Roman bridges still standing, and Roman roads still in use.
Therefore, with the concept of 'zero' in mind, I'm going to revisit the parent statement:
If I hold up my fingers to indicate elements in an array, zero fingers means the array is empty. One finger is then, naturally, the first item: of index 1.
Counting elements starting at zero (for the first element) is still unnatural...
If I hold up my fingers to indicate elements in an array, zero fingers means the array is empty. One finger is then, naturally, the first item: of index 1.
Counting elements starting at zero (for the first element) is still unnatural...
No, there really are no any societies that "terrible" at math, only societies that have evolved more sophisticated math than others - the smartest member of given society will certainly use the concepts the society has evolved correctly.
And you only need 1...N to order N bins and their contents.
And you only need 1...N to order N bins and their contents.
During my math undergrad, the natural numbers were always assumed to start with 0, the rationale being that the natural numbers should enumerate the cardinalities of all finite sets (the empty set, of course, being finite). I guess it depends on one's background.
There wasn't such consistency in my math undergrad or masters programs. Further, the Peano postulates definitely involve the natural numbers starting at 1.
Of course, most programmers don't have math degrees and I'd suspect that most people indeed think 1st element of an array starts at 1.
Of course, most programmers don't have math degrees and I'd suspect that most people indeed think 1st element of an array starts at 1.
No? You really want to discuss array starting indexes here, too? WTF? We have the end of 2011, get over it!
ARGHL!
ARGHL!
There are some excellent screencasts for pharo here:
http://www.pharocasts.com
Smalltalk is a small language (think C), so you can learn the whole language set in a few days.
The live objects concept might warp your brain a little bit. I've heard lisp does the same, so if you're from a lisp background, you might not find it shocking.
The Pharo environment (IDE) can make all the modern IDEs (Eclipse, Visual Studio) look like babies in diapers.
There is built in versionsing, DVCS, refactoring tool, unit testing framework, The most powerful debugger etc....
You will not regret trying out Smalltalk (maybe you will when you have to go back to C++) :).
http://www.pharocasts.com
Smalltalk is a small language (think C), so you can learn the whole language set in a few days.
The live objects concept might warp your brain a little bit. I've heard lisp does the same, so if you're from a lisp background, you might not find it shocking.
The Pharo environment (IDE) can make all the modern IDEs (Eclipse, Visual Studio) look like babies in diapers.
There is built in versionsing, DVCS, refactoring tool, unit testing framework, The most powerful debugger etc....
You will not regret trying out Smalltalk (maybe you will when you have to go back to C++) :).
In general I agree, except for the IDE part. Every single IDE I haven ever used have better editor that Smalltalk IDE.
Not being able to use your own editor, whichever it is, and being forced to use something that is basically equivalent to plain old browser textarea is a showstopper for calling Smalltalk environments pleasant.
Maybe Gnu Smalltalk is a cure to that, since it doesn't have live image and you can use whichever editor you like, but that kinda defeats most of the benefits of Smalltalk.
Not being able to use your own editor, whichever it is, and being forced to use something that is basically equivalent to plain old browser textarea is a showstopper for calling Smalltalk environments pleasant.
Maybe Gnu Smalltalk is a cure to that, since it doesn't have live image and you can use whichever editor you like, but that kinda defeats most of the benefits of Smalltalk.
> that is basically equivalent to plain old browser textarea is a showstopper for calling Smalltalk environments pleasant.
That's hardly an apt description. My Smalltalk environment has intellisense, auto-complete, syntax highlighting, and automated refactoring. I use Pharo.
That's hardly an apt description. My Smalltalk environment has intellisense, auto-complete, syntax highlighting, and automated refactoring. I use Pharo.
True. I've had trouble with that as well when starting up. But later on I found I'm not writing methods that are larger than 10 lines (longest being 20 lines) in Smalltalk, which makes it tolerable. Still no ideal.
I hear that SqueakVM has a package called nvi that can emulate Vi keybindings as well as emacs keybindings.
I hear that SqueakVM has a package called nvi that can emulate Vi keybindings as well as emacs keybindings.
Squeak and Pharo used to have a really great (for some value of "great", anyway) Vim emulator you could use in place of the default editor, but the hacks to enable it ran so deep that it doesn't run well anymore. The good news is that Pharo's GUI is increasingly clean and less crufty, which ought to make reintroducing a similar package feasible for the first time in years, if anyone were up to it.
It should be possible to simply embed or shell out the editing to an external program… I think this'd be the ideal solution.
Back in the day QKS Smalltalk Agents had a really nice IDE. (90s). Wonder what happened to QKS ...
> Smalltalk is a small language (think C), so you can learn the whole language set in a few days.
Hm, not sure about that. The language itself (as in: syntax) is indeed minimal. It is much smaller than C, not even having ifs and whiles but this only means you have to learn the relevant part of the runtime to start using Smalltalk.
Fun fact: if in Smalltalk is a pair of virtual methods on the Boolean objects. True implements ifTrue as "always execute the argument" and False as "ignore the argument" and it's the other way for ifFalse.
I agree with the rest of your comment - it is definitely worth trying.
Hm, not sure about that. The language itself (as in: syntax) is indeed minimal. It is much smaller than C, not even having ifs and whiles but this only means you have to learn the relevant part of the runtime to start using Smalltalk.
Fun fact: if in Smalltalk is a pair of virtual methods on the Boolean objects. True implements ifTrue as "always execute the argument" and False as "ignore the argument" and it's the other way for ifFalse.
I agree with the rest of your comment - it is definitely worth trying.
I think it means that there's a small set of concepts (and accompanying syntax) that open up the whole environment to you.
Compare it to what you need to know about Java or C++ to understand all of a codebase in that language.
Compare it to what you need to know about Java or C++ to understand all of a codebase in that language.
If you want to get introduced to Smalltalk and happens to have a Windows machine, check out Dolphin Smalltalk http://www.object-arts.com/.
Many years back, I tried Squeak a couple of times and it didn't click. Dolphin Smalltalk did that for me (and I then went back to Squeak due to other reasons). It has a well-designed, compact class library and a decent UI. I'm not sure if it has been updated to keep up with Windows, but it's a great start.
Many years back, I tried Squeak a couple of times and it didn't click. Dolphin Smalltalk did that for me (and I then went back to Squeak due to other reasons). It has a well-designed, compact class library and a decent UI. I'm not sure if it has been updated to keep up with Windows, but it's a great start.
I also enjoy hacking in the Pharo environment. That said, I have been doing most of my work lately using Clojure with combinations of: repl, Emacs, slime, and IntelliJ. I find working with Lisp or Smalltalk yields similar benefits of supporting very quick code experiments and development.
The important thing is having an environment that supports your eventual deployment requirements and also supports short term fast development requirements.
The important thing is having an environment that supports your eventual deployment requirements and also supports short term fast development requirements.
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.
Just to play devil's advocate to some of the other comments, there is GNU Smalltalk:
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.
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.
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.
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.
The developers at ObjectFusion (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).
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.)
(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.)
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.
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.
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?
I'm not talking about what's possible, simply what is. Emacs is what's equivalent to a Smalltalk environment for Lisp today.
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.)
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.)
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.
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.
This problem rings a bell: With Midgard you traditionally kept all your website (PHP) code inside a database. This made web-based remote editing easy, and allowed us to use exactly same ACLs, versioning, and deployment rules for code as for the content.
But at the same time, this meant that collaboration between users was hard, and that people were locked out of their favorite editors and VCSs.
But at the same time, this meant that collaboration between users was hard, and that people were locked out of their favorite editors and VCSs.
there isn't, by default, a dump of code that represents your program as it exists right now
If everything is in file xyz.changes, and the file is trivially parsable, could you write a program to parse the file, replay the changes up to time T, and dump out a textual representation of the program as it existed at T?
I get that this isn't the Smalltalk way. Typically it's best to approach a system on its own terms. Ideas like this are probably the equivalent of a newcomer to Lisp trying to "improve" things by getting rid of the parens. I'm just curious about what the technical barriers to doing such a thing would be.
If everything is in file xyz.changes, and the file is trivially parsable, could you write a program to parse the file, replay the changes up to time T, and dump out a textual representation of the program as it existed at T?
I get that this isn't the Smalltalk way. Typically it's best to approach a system on its own terms. Ideas like this are probably the equivalent of a newcomer to Lisp trying to "improve" things by getting rid of the parens. I'm just curious about what the technical barriers to doing such a thing would be.
You can indeed, and it's borderline trivial, but attempts to get the community to adopt such a system in the past have failed completely, and I don't find value in writing code that no one except me will ever use.
Everyone voices this concern, but it's important for people to understand that most Smalltalkers consider the binary image a throwaway artifact, and sometimes a deployment mechanism - it is emphatically not how you store or distribute code. There are standard, largely textfile based ways of doing that. I almost if it would be an advantage to not show beginners the "save image" menu item, because then it would be like any editor or IDE: if you haven't saved your source files, you lose your work, and you have to start each session by loading your source back in.
Gosh Avi, you could have mentioned Redline Smalltalk http://redline.st
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.
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.
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.h...
Alan Kay mentions this idea in relation to Lisp and Smalltalk: http://www.youtube.com/watch?v=tQg4LquY0uU (It's buried somewhere after 24 minutes.)
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.h...
Alan Kay mentions this idea in relation to Lisp and Smalltalk: http://www.youtube.com/watch?v=tQg4LquY0uU (It's buried somewhere after 24 minutes.)
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!
This is part of the paradigm shift!
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.
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. ;)
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.
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.
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...
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...
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
Use the tools you are used to, use the language that is super productive and run the result on the JVM.
Use the tools you are used to, use the language that is super productive and run the result on the JVM.
No, it really doesn't. This is a constant headache in Lua too. See Dijkstra's comments on the subject here: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...