Smalltalk: Swimming with the fish(simberon.blogspot.nl)
simberon.blogspot.nl
Smalltalk: Swimming with the fish
http://simberon.blogspot.nl/2013/01/swimming-with-fish.html
9 comments
With respect to version control systems, I notice you didn't mention ENVY. I can't comment on Monticello nor Store, never having used them, but I still miss ENVY. Best version control system I ever used.
Source: professional Smalltalker for about four years (fifteen years ago)
Source: professional Smalltalker for about four years (fifteen years ago)
> many parts of the Smalltalk IDEs are horribly outdated
My opinion is the opposite: I find the IDE in Pharo to be simple and very elegant, far more human-friendly than any I've seen in 'mainstream' languages. And this version of Smalltalk is under heavy development, with a push towards even greater cohesion. This small corner of computing is seething with hot, cutting-edge activity.
> The text editors are pretty bad
Well, you ought to know that Smalltalk is focused on relatively small snippets of code, held together in consistent OO structures. There's hardly any point in fancy text-editing features when your methods are generally 8-12 lines long!
My opinion is the opposite: I find the IDE in Pharo to be simple and very elegant, far more human-friendly than any I've seen in 'mainstream' languages. And this version of Smalltalk is under heavy development, with a push towards even greater cohesion. This small corner of computing is seething with hot, cutting-edge activity.
> The text editors are pretty bad
Well, you ought to know that Smalltalk is focused on relatively small snippets of code, held together in consistent OO structures. There's hardly any point in fancy text-editing features when your methods are generally 8-12 lines long!
> Well, you ought to know that Smalltalk is focused on relatively small snippets of code, held together in consistent OO structures. There's hardly any point in fancy text-editing features when your methods are generally 8-12 lines long!
This! And also, in Pharo 3.0 there's being a huge push towards better text editing, although I've never ever needed more than what Pharo 1.0 did already provide...
You don't work with text in Smalltalk.
This! And also, in Pharo 3.0 there's being a huge push towards better text editing, although I've never ever needed more than what Pharo 1.0 did already provide...
You don't work with text in Smalltalk.
Just because you have shorter methods does not mean you would not benefit from Emacs-like power. I use Haskell--which has even shorter functions, often half that length--and yet I still find Emacs exceptionally useful.
Any amount of text is still text, and Emacs excels at text editing.
Any amount of text is still text, and Emacs excels at text editing.
I problem I ran into when giving it a try. I couldn't easily find a way to print to standard output. All I wanted was to print some strings, numbers and manipulate them. Instead, it was easier to have a red ball on the screen.
There is no stdout, but if you want, you can print to something. Just open up a Transcript window and use 'Transcript show: ' method.
A while back I backed an IndieGoGo project dedicated to bringing Smalltalk to the JVM: http://www.indiegogo.com/projects/redline-smalltalk-v1-0
I really hope this project pans out, because I would love to be able to program in Smalltalk for practical purposes.
(In fact, even the thought of being able to write a single application in both Lisp (Clojure) and Smalltalk (Redline) is making me giddy. We're still a long ways from this dream, but perhaps it'll be possible one day.)
I really hope this project pans out, because I would love to be able to program in Smalltalk for practical purposes.
(In fact, even the thought of being able to write a single application in both Lisp (Clojure) and Smalltalk (Redline) is making me giddy. We're still a long ways from this dream, but perhaps it'll be possible one day.)
Redlines smalltalk on the JVM is cool. You can also use Smalltalk on the web browser through Amber: http://amber-lang.net/
You could also do http://amber-lang.net/ and ClojureScript, no?
It is cool, but redline doesn't have the environment of smalltalk, just the language. Which, arguably, misses a LOT of the point of using smalltalk.
Articles about how great Smalltalk is usually remind me of articles about how great the Lisp Machine was. And there is a lot of merit to an entire system, hardware and software, designed to operate in a high-level language.
My complaint is that neither of these things is coming back in a relevant way.
Perhaps the biggest shift in software engineering in the last decade or two is the fact that no one writes entire systems anymore. We've moved to a system of (somewhat!) interchangeable parts. If your thoughtfully constructed, delicately handcrafted utopia doesn't play well with tools the user is used to and libraries the user needs, no one will use it in the real world.
Smalltalk, though a wonderful entire system in the 80's, hasn't kept up with computing progress. Most of its best features made it into other languages (Ruby and Obj-C are the premier examples), languages which aren't so opinionated about what OS you run, what IDE you're using, what language adjacent programs are written in, etc.
Much like Lisp Machines, the rest is left to rot, and incite wistful blog posts by old hands. And pretty much everyone else ships code in other languages.
My complaint is that neither of these things is coming back in a relevant way.
Perhaps the biggest shift in software engineering in the last decade or two is the fact that no one writes entire systems anymore. We've moved to a system of (somewhat!) interchangeable parts. If your thoughtfully constructed, delicately handcrafted utopia doesn't play well with tools the user is used to and libraries the user needs, no one will use it in the real world.
Smalltalk, though a wonderful entire system in the 80's, hasn't kept up with computing progress. Most of its best features made it into other languages (Ruby and Obj-C are the premier examples), languages which aren't so opinionated about what OS you run, what IDE you're using, what language adjacent programs are written in, etc.
Much like Lisp Machines, the rest is left to rot, and incite wistful blog posts by old hands. And pretty much everyone else ships code in other languages.
> Perhaps the biggest shift in software engineering in the last decade or two is the fact that no one writes entire systems anymore.
That's unfortunate. If we kept at it, we could have discovered much simpler ways of doing things than the current accumulation of leaky abstractions over leaky abstractions in a rather disintegrated environment. We can do better: http://www.vpri.org/pdf/tr2011004_steps11.pdf
That's unfortunate. If we kept at it, we could have discovered much simpler ways of doing things than the current accumulation of leaky abstractions over leaky abstractions in a rather disintegrated environment. We can do better: http://www.vpri.org/pdf/tr2011004_steps11.pdf
There is great danger in learning OOP with Smalltalk. Everything fits together so elegantly, the first time I opened a book about C++, I closed it in disgust (after seeing the bit-shift operator being used for console output, wtf?!), only to give the language a second chance 8 years later. I even learned Java before giving C++ a try.
When a young programmer asks me for advice about the next language to learn is, my advice is to go for the language that feels most alien. C++ won't enlighten a Java programmer significantly. Forth will.
When a young programmer asks me for advice about the next language to learn is, my advice is to go for the language that feels most alien. C++ won't enlighten a Java programmer significantly. Forth will.
> I even learned Java before giving C++ a try
It's not a bad language and learning it will teach you a lot of very important concepts. My advice is to master C first, then to wrap your brain around C++.
But, again, there may be other languages more worthy of your effort.
I only leaned Java before touching C++ again because of my peculiar introduction to OOP and because I discarded the language after considering it an inelegant kludge, but, compared to Smalltalk, what language isn't?
And, finally, I decided to swallow my pride and learn C++ because I wanted to be part of the Brazilian electronic voting system projecy. Now, every ballot runs some C++ code I wrote.
If the company is that cool, give it a shot.
But, again, there may be other languages more worthy of your effort.
I only leaned Java before touching C++ again because of my peculiar introduction to OOP and because I discarded the language after considering it an inelegant kludge, but, compared to Smalltalk, what language isn't?
And, finally, I decided to swallow my pride and learn C++ because I wanted to be part of the Brazilian electronic voting system projecy. Now, every ballot runs some C++ code I wrote.
If the company is that cool, give it a shot.
Learn C first! You'll understand why C++ is what it is and you'll also get the skills needed to contribute in a lot of open-source projects.
Please don't! Learn Modern C++ instead, otherwise you will be damaged with Cisms in C++ land.
Would you like to elaborate on that?
There are lots of C constructs that are considered bad practice in C++
- null terminated strings
- plain vectors
- manual management of resources (memory, files, db connections, locks...)
- C style casts
- pre-processor instead of using inline/const/templates
- the C subset of C++ it is also not 100% compatible with C, there are a few cases with different semantics
- since C99, new language constructs are added via macros, instead of keywords
- no use of namespaces
- lack of safety of parameters that can be changed (pointer vs reference parameters)
The best way to learn C++ is to read books like "Modern C++ Design", "Programming -- Principles and Practice Using C++" and the recently published "Tour of C++".
- null terminated strings
- plain vectors
- manual management of resources (memory, files, db connections, locks...)
- C style casts
- pre-processor instead of using inline/const/templates
- the C subset of C++ it is also not 100% compatible with C, there are a few cases with different semantics
- since C99, new language constructs are added via macros, instead of keywords
- no use of namespaces
- lack of safety of parameters that can be changed (pointer vs reference parameters)
The best way to learn C++ is to read books like "Modern C++ Design", "Programming -- Principles and Practice Using C++" and the recently published "Tour of C++".
I have to take issue with your inclusion of "Modern C++ Design" in a reading list about learning C++. If you're new to C++, that is exactly the sort of thing you _shouldn't_ be reading.
"Modern C++ Design" is really intended for advanced C++ programmers only. I don't feel it gives a very good impression of the language to new developers - there are so many awful hacks in that book.
It's the sort of thing that you should hold off on until you have the experience with the language necessary to be wise about when such techniques are appropriate.
"Modern C++ Design" is really intended for advanced C++ programmers only. I don't feel it gives a very good impression of the language to new developers - there are so many awful hacks in that book.
It's the sort of thing that you should hold off on until you have the experience with the language necessary to be wise about when such techniques are appropriate.
I'll second nnq's opinion. Quite a few of C++'s quirks are the way they are because of the C in its name.
Have you ever tried Eiffel? I've always found the approach taken by Eiffel as OOP done right (compared to C++). I wonder how Eiffel and Smalltalk compare together.
Yes they are gone.
However, the main point is that back then you haven't got HN, Reddit and the blogs of today.
As such not many geeks were fortunate enough to know and understand those systems, as consequence you have a legion of developers that cannot understand the beauty of those systems.
However, the main point is that back then you haven't got HN, Reddit and the blogs of today.
As such not many geeks were fortunate enough to know and understand those systems, as consequence you have a legion of developers that cannot understand the beauty of those systems.
I've worked with Smalltalk for four years now, and for what you write, I guess you haven't been keeping up with our progresses. Take a look at:
http://amber-lang.net
http://www.redline.st/
http://pharo-project.org
Saying Smalltalk hasn't kept up with computing progress is an old argument that doesn't make sense anymore.
http://amber-lang.net
http://www.redline.st/
http://pharo-project.org
Saying Smalltalk hasn't kept up with computing progress is an old argument that doesn't make sense anymore.
At the same time, so much recent tool development has focused on virtualization. Vagrant, chef, puppet, packer, ... and yet, Smalltalk has decades of experience with whole virtualized machines to we can study.
Perhaps systems like Smalltalk still have something to teach us?
Perhaps systems like Smalltalk still have something to teach us?
> My complaint is that neither of these things is coming back in a relevant way.
I think one could make the case that Android shares many design decisions with a "Smalltalk machine". And the same actually goes for iOS, as objective-c is basically Smalltalk bolted on to c.
And then there is javascript that's modelled after Self -- so by extention chrome OS is also similar to a "Smalltalk machine".
Now why all these systems end up with some bastardized crappy programming languages rather than just using Smalltalk -- that I don't know.
The exception might be the one-laptop-per-child project.
So, I think it's wrong to say "it's not coming back" -- even java (for set-top boxes and smart devices) was an attempt at "bringing it back".
If anything, it seems these systems keep being reinvented.
I think one could make the case that Android shares many design decisions with a "Smalltalk machine". And the same actually goes for iOS, as objective-c is basically Smalltalk bolted on to c.
And then there is javascript that's modelled after Self -- so by extention chrome OS is also similar to a "Smalltalk machine".
Now why all these systems end up with some bastardized crappy programming languages rather than just using Smalltalk -- that I don't know.
The exception might be the one-laptop-per-child project.
So, I think it's wrong to say "it's not coming back" -- even java (for set-top boxes and smart devices) was an attempt at "bringing it back".
If anything, it seems these systems keep being reinvented.
> Now why all these systems end up with some bastardized crappy programming languages rather than just using Smalltalk -- that I don't know.
Because Worse is Better[1]. For example Internet and the Web is a bastardized version of Xanadu Project[2]. HTML is a bastardized version of XML or XHTML. Worse is here now, when Better gets here, it's not Better anymore, only marginally more useful. That or it turns out the benefits Better has aren't that important or are highly impractical.
[1]http://en.wikipedia.org/wiki/Worse_is_better
[2]http://en.wikipedia.org/wiki/Xanadu_Project
Because Worse is Better[1]. For example Internet and the Web is a bastardized version of Xanadu Project[2]. HTML is a bastardized version of XML or XHTML. Worse is here now, when Better gets here, it's not Better anymore, only marginally more useful. That or it turns out the benefits Better has aren't that important or are highly impractical.
[1]http://en.wikipedia.org/wiki/Worse_is_better
[2]http://en.wikipedia.org/wiki/Xanadu_Project
No. Worse is Better would explain why browsers would use Smaltalk (or Self) directly, instead of inventing a new programming language.
Javascript was probably born out of Not Invented Here. Worse Is Better only contributed the curly braces from C, and the continued use of the first widely known scripting engine.
If The Right Thing is already there, Worse Is Better simply doesn't win without exterior help. Worse is better only because it's first. And even so…
> when Better gets here, it's not Better anymore, only marginally more useful.
I would say perceived as marginally more useful in the short term. This is a point where Worse easily looks Better, but whether it is is more debatable.
Javascript was probably born out of Not Invented Here. Worse Is Better only contributed the curly braces from C, and the continued use of the first widely known scripting engine.
If The Right Thing is already there, Worse Is Better simply doesn't win without exterior help. Worse is better only because it's first. And even so…
> when Better gets here, it's not Better anymore, only marginally more useful.
I would say perceived as marginally more useful in the short term. This is a point where Worse easily looks Better, but whether it is is more debatable.
I'm gonna disagree. Could you implement Smalltalk environment in browser in two weeks? I'd doubt you could (assuming you are Brendan Eich, circa 1995), realistically. It is a sloppily written language that was perfected later over course of decades.
Worse is Better is omnipresent. Linux vs Minix vs BeOS vs Windows is example of Linux despite being bad relatively, simply winning out (on servers) due to its developer base and losing to Windows that despite numerous faults/warts won the desktop market by a large margin.
When I said Right Thing being here, I didn't mean existence, but presence. Right thing may exist in heads of few masters that know it super well, but them being unable or unwilling to spread it dooms the Right Thing. A Worse Thing that spreads far and wide will win and has always won.
Xanadu vs Internet
Linux vs BeOS
MacOS vs Windows
Lisp/Smalltalk vs C
Worse is Better is omnipresent. Linux vs Minix vs BeOS vs Windows is example of Linux despite being bad relatively, simply winning out (on servers) due to its developer base and losing to Windows that despite numerous faults/warts won the desktop market by a large margin.
When I said Right Thing being here, I didn't mean existence, but presence. Right thing may exist in heads of few masters that know it super well, but them being unable or unwilling to spread it dooms the Right Thing. A Worse Thing that spreads far and wide will win and has always won.
Xanadu vs Internet
Linux vs BeOS
MacOS vs Windows
Lisp/Smalltalk vs C
> Could you implement Smalltalk environment in browser in two weeks?
You're being unfair: you compare a Javascript interpreter against a Smalltalk environment. Obviously, If I were in a rush, I would start with a simple interpreter first.
Realistically, if you don't really care about performance (I doubt Brendan Eich did at the time), implementing a JavaScript interpreter is neither easier nor harder than implementing a Lisp or Smalltalk or Self interpreter. I maintain that ease of implementation simply was not an influential factor either way.
Therefore, Javascript was invented for other reasons. My best guess is, Brendan Eich wanted his language to be non-intimidating to C, C++, and Java users. Apparently, it worked.
Oh. That is a typical "Worse is Better".
Okay, I retract. "Worse is Better" is an excellent explanation for Javascript. There are just other kinds of short term benefits persisting through time than the mere ease of implementation.
You're being unfair: you compare a Javascript interpreter against a Smalltalk environment. Obviously, If I were in a rush, I would start with a simple interpreter first.
Realistically, if you don't really care about performance (I doubt Brendan Eich did at the time), implementing a JavaScript interpreter is neither easier nor harder than implementing a Lisp or Smalltalk or Self interpreter. I maintain that ease of implementation simply was not an influential factor either way.
Therefore, Javascript was invented for other reasons. My best guess is, Brendan Eich wanted his language to be non-intimidating to C, C++, and Java users. Apparently, it worked.
Oh. That is a typical "Worse is Better".
Okay, I retract. "Worse is Better" is an excellent explanation for Javascript. There are just other kinds of short term benefits persisting through time than the mere ease of implementation.
Ok. Then implement a Smalltalk interpreter in a week. And then make it look like Java, because that was Brendan's task.
Hmm… I think that's pretty much what Brendan did, although he likely started with Self instead of Smalltalk. JavaScript makes a strong emphasis on objects, and had closures from the beginning. Then it has a Java-ish syntax.
As for actually implementing a smaltalk interpreter, it can now be done in 300 lines: http://www.youtube.com/watch?v=EGeN2IC7N0Q (I believe he used Maru http://piumarta.com/software/maru/ ) With current techniques, a language specialist can implement Smalltalk in a day.
I'm not that strong, though. It could take me from a week to a month, depending on how much I need to learn. (Parsing the syntax is easy, but I'm less sure about the semantics.)
As for actually implementing a smaltalk interpreter, it can now be done in 300 lines: http://www.youtube.com/watch?v=EGeN2IC7N0Q (I believe he used Maru http://piumarta.com/software/maru/ ) With current techniques, a language specialist can implement Smalltalk in a day.
I'm not that strong, though. It could take me from a week to a month, depending on how much I need to learn. (Parsing the syntax is easy, but I'm less sure about the semantics.)
> HTML is a bastardized version of XML or XHTML.
No, HTML was an SGML language (XHTML is of course an XML language). HTML5 is more of an "HTML"-like language...
SGML, if anything, is more powerful than XML -- but XML is a great effort to simplify SGML while maintaining most of the power.
For other SGML languages than HTML, look for docbook (which now also exist in an XML dress).
No, HTML was an SGML language (XHTML is of course an XML language). HTML5 is more of an "HTML"-like language...
SGML, if anything, is more powerful than XML -- but XML is a great effort to simplify SGML while maintaining most of the power.
For other SGML languages than HTML, look for docbook (which now also exist in an XML dress).
> Most of its best features made it into other languages
No. A few of them have, usually in needlessly restricted and nigh-broken forms (Ruby's blocks are a pale and pitiful shadow of Smalltalk's). I've yet to see message cascading or conditions outside of lisps and smalltalk.
No. A few of them have, usually in needlessly restricted and nigh-broken forms (Ruby's blocks are a pale and pitiful shadow of Smalltalk's). I've yet to see message cascading or conditions outside of lisps and smalltalk.
> My complaint is that neither of these things is coming back in a relevant way.
Isn't Light Table essentially an effort to re-create the Smalltalk environment for modern languages?
Isn't Light Table essentially an effort to re-create the Smalltalk environment for modern languages?
Yes. And seriously, when I saw the first Light Table demo and everyone was so amazed with it I thought "man, that's how we code every day in Smalltalk... what's so new about it?"
From its documentation, it looks more like an attempt to expose the kind of REPL/runtime integration Emacs offers, through an interface which won't scare people off the way Emacs tends to do.
>My complaint is that neither of these things is coming back in a relevant way.
Where is this directed? It sounds like a criticism of Lisp, Forth, Self, etc, but please correct. The fact that the ignorant masses flocked to C and Unix doesn't grant them one _iota_ of merit. C isn't even a good low-level language. And look at the most popular platform of them all - the web browser, if you want a good laugh.
Where is this directed? It sounds like a criticism of Lisp, Forth, Self, etc, but please correct. The fact that the ignorant masses flocked to C and Unix doesn't grant them one _iota_ of merit. C isn't even a good low-level language. And look at the most popular platform of them all - the web browser, if you want a good laugh.
This is true of any new system. There is a huge complexity in supporting even the standards that most people would consider basic. Just to surf the web you need TCP/IP, HTTP(S), HTML, JavaScript, JPEG, etc. Implementing all of these from scratch is a huge pain.
What is true of any new system? I don't know what point you're trying to make.
I have been facinated by Smalltalk but the language drives my kinda crazy. I have read the 'Blue book' (http://wiki.squeak.org/squeak/64) and tried Pharo (http://www.pharo-project.org/home), Amber (http://amber-lang.net/) and GNU Smalltalk.
While I really like Smalltalk, for some reason it does not work for me as a web development platform (and the web is my platform), or maybe I just don't grasp it.
I tried Seaside (http://www.seaside.st/) but the URLs it generates are not acceptable (unfortunately) and I find their component system quite complex. I hope someday I will find way to use the techniques behind Smalltalk (live environment, object model) in a browser or web environment. Maybe Amber will develop into something I can work with. I really hope so. Any suggestions anyone?
While I really like Smalltalk, for some reason it does not work for me as a web development platform (and the web is my platform), or maybe I just don't grasp it.
I tried Seaside (http://www.seaside.st/) but the URLs it generates are not acceptable (unfortunately) and I find their component system quite complex. I hope someday I will find way to use the techniques behind Smalltalk (live environment, object model) in a browser or web environment. Maybe Amber will develop into something I can work with. I really hope so. Any suggestions anyone?
There are two other web frameworks in use, and I think one of them is more about generating clean URLs. Illiad?
I love the idea of Smalltalk, but it also never stuck for me. I think I just prefer to learn from books than through milling around in the image. All the great minds in Smalltalk seem to be self-driven autodidacts. I'm not.
I'm pretty good at Haskell and Prolog though, so I think it works out in the end. I'm also not good at Lisp or Forth. :)
I love the idea of Smalltalk, but it also never stuck for me. I think I just prefer to learn from books than through milling around in the image. All the great minds in Smalltalk seem to be self-driven autodidacts. I'm not.
I'm pretty good at Haskell and Prolog though, so I think it works out in the end. I'm also not good at Lisp or Forth. :)
Yep. AidaWeb and Iliad (plus many other smaller ones).
Although Iliad is not about generating clean URLs (it can, though), but more about being small and understandable, plus having Ajax for free and being pragmatic.
Although Iliad is not about generating clean URLs (it can, though), but more about being small and understandable, plus having Ajax for free and being pragmatic.
Based on the title, I assumed this would be an article about how Smalltalk has been murdered:
http://www.usingenglish.com/reference/idioms/swim+with+the+f...
http://www.usingenglish.com/reference/idioms/swim+with+the+f...
I'd like to see their source for that!
"[He] sleep[s] with the fishes" is the canonical form of the idiom, whose presence in the common vernacular originates with its use in Puzo's "The Godfather"; in my entire life as a native US English speaker, I have never once heard "swim with the fishes" used with anything remotely resembling the same meaning. (It doesn't even make sense! Dead things don't swim; they can't, because they're dead.)
"[He] sleep[s] with the fishes" is the canonical form of the idiom, whose presence in the common vernacular originates with its use in Puzo's "The Godfather"; in my entire life as a native US English speaker, I have never once heard "swim with the fishes" used with anything remotely resembling the same meaning. (It doesn't even make sense! Dead things don't swim; they can't, because they're dead.)
Fish vs. fishes... and I think "sleeping" is the more common form (at least in media), but yeah, I was wondering, too.
I've got a bit of the blub paradox going on here so this story is lost on me. Can anyone give me a concrete example of what he's talking about instead of an abstract analogy?
The debugger situation with Smalltalk is part of what he's talking about. You're running your application, and some part of your code throws an exception. A window pops up with the stack trace in it. You can inspect all the objects in each frame. "Inspect" in Smalltalk means, see and change the properties, call methods, change the code, clone, see the class hierarchy, etc. You can modify the method that threw the exception right there from the debug window, save it, and resume the method from where it broke. Application proceeds with new code in place and problem solved.
Look, a cosmetic bug in this window. Right click on it, click Inspect. Looks like one of the properties has the wrong value. Edit the property from the inspector, fix the problem. The application was running the whole time and now is fixed.
An impressive thing you can do with Fuel is serialize and deserialize the exception with all state. Somebody blows up your web application. You wrote a bit of code to catch unhandled exceptions and export them with Fuel. You download the binary to your local computer and deserialize it in your live Smalltalk image. You see the debugger window pop up and can examine all the state when the error happened as if it popped up locally. See, examine, change the code, all of it live the whole time. (I don't know if this is done in practice much, but it's pretty normal to run a headless Smalltalk image and connect to it over VNC when you need to debug something).
To sum up, everything is live all the time in Smalltalk, and you can interactively change all the actual running instances, both code and data, at any time without interrupting anything.
Look, a cosmetic bug in this window. Right click on it, click Inspect. Looks like one of the properties has the wrong value. Edit the property from the inspector, fix the problem. The application was running the whole time and now is fixed.
An impressive thing you can do with Fuel is serialize and deserialize the exception with all state. Somebody blows up your web application. You wrote a bit of code to catch unhandled exceptions and export them with Fuel. You download the binary to your local computer and deserialize it in your live Smalltalk image. You see the debugger window pop up and can examine all the state when the error happened as if it popped up locally. See, examine, change the code, all of it live the whole time. (I don't know if this is done in practice much, but it's pretty normal to run a headless Smalltalk image and connect to it over VNC when you need to debug something).
To sum up, everything is live all the time in Smalltalk, and you can interactively change all the actual running instances, both code and data, at any time without interrupting anything.
That's roughly how one works in Common Lisp as well (though most implementations don't ship with a graphical environment, so ssh is typical instead of VNC).
It's really much more pleasant than shipping text files and interpreters all over the place and sorting through logfiles and tracebacks when things go south.
It's really much more pleasant than shipping text files and interpreters all over the place and sorting through logfiles and tracebacks when things go south.
Absolutely. There's a deep kinship between them. Prolog can also be used this way, though it doesn't support images, it's a homoiconic language and it's very easy to read and write terms from files.
In Smalltalk, you can manipulate objects directly rather than just indirectly via code that operates on them. The state of your manipulation is made persistent in smalltalk's image facility. Also, the whole object graph is supposedly better exposed accordingly then what you could get sigh just a plain old debugger.
At least I think that is what the author is trying to convey.
At least I think that is what the author is trying to convey.
This is where my Blub programmer life bites me. I don't understand what you mean by "manipulate objects directly". I can't figure out the right abstraction level to put it at.
For instance, let's say I have an Employee object that throws an exception. Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary. So I'm not acting directly on the object, but a representation of the object.
However, then it just sounds like Smalltalk lets me play with a set of bits in memory that represent the Bob object. Most debuggers I've worked with already allow me to do that in some fashion. Yet, this is always touted as one of the great, unique features of Smalltalk. There must be something that I'm missing, but I can't see what.
For instance, let's say I have an Employee object that throws an exception. Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary. So I'm not acting directly on the object, but a representation of the object.
However, then it just sounds like Smalltalk lets me play with a set of bits in memory that represent the Bob object. Most debuggers I've worked with already allow me to do that in some fashion. Yet, this is always touted as one of the great, unique features of Smalltalk. There must be something that I'm missing, but I can't see what.
What you're missing is that, in Smalltalk, the representation on which you're acting is indistinguishable from the object; in your example, when you change the name member, Bob from Accounting's name does suddenly change to Gary; not only do future accesses of the name member on that object return "Gary", but, for example, if you have an HR management frontend open on Bob when you make the change in the inspector, you'll instantly see the effect there as well.
If all your experience and knowledge is born of Unix and the web, you don't really have available the necessary concepts to think about how a Smalltalk, or even a Lisp, actually works -- I know this because all of my experience and knowledge were born of Unix and the web, until recently, when I took it into my head to learn Lisp and also to gain at least a passing familiarity with Smalltalk. The difference is amazing -- in the preface of the UNIX-HATERS Handbook, written mostly by veterans of the Lisp years at SAIL, our modern computing environment is described thusly, by Ken Pier of Xerox PARC:
"I liken starting one's computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act."
Which I thought was hyperbole, too, until I spent some time discovering what sort of environment Pier and the SAIL folk took for granted. I don't unreservedly recommend the experiment; I earn my living in Pier's "East Africa", and sometimes I think I'd be better off if I didn't know how bad I have it. But I can certainly say that if you haven't tried it for yourself, you don't begin to know what you're missing.
If all your experience and knowledge is born of Unix and the web, you don't really have available the necessary concepts to think about how a Smalltalk, or even a Lisp, actually works -- I know this because all of my experience and knowledge were born of Unix and the web, until recently, when I took it into my head to learn Lisp and also to gain at least a passing familiarity with Smalltalk. The difference is amazing -- in the preface of the UNIX-HATERS Handbook, written mostly by veterans of the Lisp years at SAIL, our modern computing environment is described thusly, by Ken Pier of Xerox PARC:
"I liken starting one's computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act."
Which I thought was hyperbole, too, until I spent some time discovering what sort of environment Pier and the SAIL folk took for granted. I don't unreservedly recommend the experiment; I earn my living in Pier's "East Africa", and sometimes I think I'd be better off if I didn't know how bad I have it. But I can certainly say that if you haven't tried it for yourself, you don't begin to know what you're missing.
I understand that changing the name member of the Bob object to Gary will cause it to be Gary in every subsequent member access. Perhaps I've grown spoiled in my old age, but I'd be shocked at any system which didn't have this property. However, if I called out "Hey Gary!" down the hall, would he respond? Would his driver's license still read Bob?
The last time that I tried to learn Smalltalk, it was drilled into me that Smalltalk works directly with objects and not just their representations. For instance, the collection of black pixels on the screen was the Mouse object itself and not just a manifestation of a Mouse object somewhere in memory. A large amount of my confusion has possibly come from those lessons.
I agree that Lisp is an enlightening experience. I spent two years using Scheme as my primary programming language at work. Then again, I may just be stuck as a Blub programmer. I spent a year focused on Common Lisp, but never found any use for SLIME, despite using Emacs exclusively.
The last time that I tried to learn Smalltalk, it was drilled into me that Smalltalk works directly with objects and not just their representations. For instance, the collection of black pixels on the screen was the Mouse object itself and not just a manifestation of a Mouse object somewhere in memory. A large amount of my confusion has possibly come from those lessons.
I agree that Lisp is an enlightening experience. I spent two years using Scheme as my primary programming language at work. Then again, I may just be stuck as a Blub programmer. I spent a year focused on Common Lisp, but never found any use for SLIME, despite using Emacs exclusively.
> However, if I called out "Hey Gary!" down the hall, would he respond? Would his driver's license still read Bob?
Yes and no, respectively.
Perhaps a heavily contrived example might help: Consider a system in which there is exactly one representation of an object member's value, which is stored in that object; when you call an accessor method, what you actually get is a reference, which is instantiated with an observer attached that listens for a notional "change" event, fired whenever the referred value is modified, and whose event handler updates whatever context exists around the reference, regardless of its nature, so that the displayed value matches that newly assigned to the object member.
...and now perhaps you can see why people familiar with Smalltalk think so highly of it; what in, for example, Javascript, would require an enormous amount of manual infrastructure and completely fail to generalize, in Smalltalk happens entirely transparently. It's not so much that you don't have to think about it; it's that there's nothing there to think about.
> I spent a year focused on Common Lisp, but never found any use for SLIME, despite using Emacs exclusively.
And now you've lost me. How can this possibly be the case? What was your Lisp workflow like? I mean, I can understand not getting the appeal of Lisp if you're just talking to the REPL and not working in an actual Lisp environment of the sort you get with Emacs Lisp or SLIME, but I have trouble understanding how anyone could work with those tools for a year without recognizing their potential.
Yes and no, respectively.
Perhaps a heavily contrived example might help: Consider a system in which there is exactly one representation of an object member's value, which is stored in that object; when you call an accessor method, what you actually get is a reference, which is instantiated with an observer attached that listens for a notional "change" event, fired whenever the referred value is modified, and whose event handler updates whatever context exists around the reference, regardless of its nature, so that the displayed value matches that newly assigned to the object member.
...and now perhaps you can see why people familiar with Smalltalk think so highly of it; what in, for example, Javascript, would require an enormous amount of manual infrastructure and completely fail to generalize, in Smalltalk happens entirely transparently. It's not so much that you don't have to think about it; it's that there's nothing there to think about.
> I spent a year focused on Common Lisp, but never found any use for SLIME, despite using Emacs exclusively.
And now you've lost me. How can this possibly be the case? What was your Lisp workflow like? I mean, I can understand not getting the appeal of Lisp if you're just talking to the REPL and not working in an actual Lisp environment of the sort you get with Emacs Lisp or SLIME, but I have trouble understanding how anyone could work with those tools for a year without recognizing their potential.
> Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary.
Yes it does.
> So I'm not acting directly on the object, but a representation of the object.
No, that is the object. Now, if it's backed by a relational database what you're saying might be true, but then you just change the name and then tell the object to save.
You're thinking too data centric as if only persistent objects exist, so let me explain. Smalltalk is image based, you're working in the live runtime, not on files that later become the live runtime.
Forget the debugger, it has nothing to do with the debugger. I can open up a workspace and say "SomeClass allInstances", highlight the statement, press a key to inspect it and up pops a list of all instances of that class in a window. I can then click any instance in that list and inspect it and get a window for that object where I can see and modify the state of that object. That object could be a session object for a user on the website at that moment, or it could be the application itself, or any other object in the system.
In most languages using the debugger is the only time you get to play with the running program, in Smalltalk there is only the running program and you're in it all the time. I can highlight a method name, hit one key, and be taken to the source for any method in the system including those that give me that ability; I could change code that breaks the IDE that I'm working in if I wanted. I could inspect the running IDE and change the color of the window tile while I'm using it. I can do all of this from the IDE or workspace without ever invoking a debugger.
Here's a very simple way to grok it, it's just like SQL in the sense that a database is a running image and you can query user table or even system tables that control how the server itself functions. If you change a view, clients of that view see the change instantly; you don't have to restart the database to see your code changes because you are working on the running server, not a text file that when ran becomes the server.
Smalltalk is the same, you write code in the running image and changes are seen immediately by clients using that server. This is the same as a Lisp hacker connecting Emacs to a running Lisp instance, say the one that hosts this site, and making changes while people are using the site.
Smalltalk is optimized for code navigation like no other environment I've ever seen. When I work in Ruby or frankly any other language, I have to pull up the documentation for the String class to see what methods it supports; I've never had to do that in Smalltalk, I just go to the String class and look at what methods it supports directly assuming I don't see what I'm looking for in the intellisense. If I want to extend it, I add a method to it right there, but categorize it with my package so it's part of my project and not part of String for the purposes of source control.
If I want to see how a string works, I can simply highlight a string in a workspace and inspect that instance of it in a window, and then play with it, sending messages to it to see how it reacts, or if it errors, or whatever. Pretty much anywhere in the system you can simply highlight some code and press a key to evaluate it allowing you to hack things together by trial and error much much faster than if all you have is a REPL or worse only the debugger.
A Smalltalk workspace is pretty much exactly like working in a SQL workspace; write some code, highlight it, run it, see what happens. But in Smalltalk, you're not limited to a result window, you might have a transcript up, but you also might have 10 inspectors open on all the objects you're playing with in a workspace so you can see them and watch their state change while you're playing with the code.
A Smalltalk image is a running object database, not a transactional one, you don't generally want to use it for persistence, however, you can and this is fantastic when prototyping. You can write the entire UI using the image as the database and put off the persistence decision until your app is shaken out and you know what you really want to do. I can just hang an OrderedCollection off my class and use it as the database. I could then query it like so:
Yes it does.
> So I'm not acting directly on the object, but a representation of the object.
No, that is the object. Now, if it's backed by a relational database what you're saying might be true, but then you just change the name and then tell the object to save.
You're thinking too data centric as if only persistent objects exist, so let me explain. Smalltalk is image based, you're working in the live runtime, not on files that later become the live runtime.
Forget the debugger, it has nothing to do with the debugger. I can open up a workspace and say "SomeClass allInstances", highlight the statement, press a key to inspect it and up pops a list of all instances of that class in a window. I can then click any instance in that list and inspect it and get a window for that object where I can see and modify the state of that object. That object could be a session object for a user on the website at that moment, or it could be the application itself, or any other object in the system.
In most languages using the debugger is the only time you get to play with the running program, in Smalltalk there is only the running program and you're in it all the time. I can highlight a method name, hit one key, and be taken to the source for any method in the system including those that give me that ability; I could change code that breaks the IDE that I'm working in if I wanted. I could inspect the running IDE and change the color of the window tile while I'm using it. I can do all of this from the IDE or workspace without ever invoking a debugger.
Here's a very simple way to grok it, it's just like SQL in the sense that a database is a running image and you can query user table or even system tables that control how the server itself functions. If you change a view, clients of that view see the change instantly; you don't have to restart the database to see your code changes because you are working on the running server, not a text file that when ran becomes the server.
Smalltalk is the same, you write code in the running image and changes are seen immediately by clients using that server. This is the same as a Lisp hacker connecting Emacs to a running Lisp instance, say the one that hosts this site, and making changes while people are using the site.
Smalltalk is optimized for code navigation like no other environment I've ever seen. When I work in Ruby or frankly any other language, I have to pull up the documentation for the String class to see what methods it supports; I've never had to do that in Smalltalk, I just go to the String class and look at what methods it supports directly assuming I don't see what I'm looking for in the intellisense. If I want to extend it, I add a method to it right there, but categorize it with my package so it's part of my project and not part of String for the purposes of source control.
If I want to see how a string works, I can simply highlight a string in a workspace and inspect that instance of it in a window, and then play with it, sending messages to it to see how it reacts, or if it errors, or whatever. Pretty much anywhere in the system you can simply highlight some code and press a key to evaluate it allowing you to hack things together by trial and error much much faster than if all you have is a REPL or worse only the debugger.
A Smalltalk workspace is pretty much exactly like working in a SQL workspace; write some code, highlight it, run it, see what happens. But in Smalltalk, you're not limited to a result window, you might have a transcript up, but you also might have 10 inspectors open on all the objects you're playing with in a workspace so you can see them and watch their state change while you're playing with the code.
A Smalltalk image is a running object database, not a transactional one, you don't generally want to use it for persistence, however, you can and this is fantastic when prototyping. You can write the entire UI using the image as the database and put off the persistence decision until your app is shaken out and you know what you really want to do. I can just hang an OrderedCollection off my class and use it as the database. I could then query it like so:
Customer db select: [:e | e name = 'Joe'
and: [ e age > 3 ]].
First off, thank you for your through reply
> > Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary.
> Yes it does.
Okay. either I wasn't clear in my analogy or I'm actually further away from understanding Smalltalk than I thought. Let me put it a different way: If I open the Bob object in the inspector and set the "deceased" member to "true", will Bob claw his way out of his casket?
A lot of my confusion about whether it's the object or the representation of the object comes from this level. I tried to learn Smalltalk a few years ago. We started off with some GUI work and the teacher was quite adamant that we understand that the button on the screen was the object and not just a visual representation of the object.
If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment. For a comparison point, during my day job, I write a large amount of Python in Emacs. This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it. I can call the "help" function on an object to see its documentation or the "dir" function to view all its members and methods. I can load code at run time and patch new members onto classes or objects.
Of course, that's the classic Blub programmer paragraph. At the very least, Smalltalk sounds like a nice environment and I'm jealous of having multiple, independent object inspectors. I'm also sure that the Smalltalk documentation is better written than what I usually get from "help". Still, I suspect that I'm missing something. Especially if I'm still wrong about what it means to work directly on an object.
> > Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary.
> Yes it does.
Okay. either I wasn't clear in my analogy or I'm actually further away from understanding Smalltalk than I thought. Let me put it a different way: If I open the Bob object in the inspector and set the "deceased" member to "true", will Bob claw his way out of his casket?
A lot of my confusion about whether it's the object or the representation of the object comes from this level. I tried to learn Smalltalk a few years ago. We started off with some GUI work and the teacher was quite adamant that we understand that the button on the screen was the object and not just a visual representation of the object.
If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment. For a comparison point, during my day job, I write a large amount of Python in Emacs. This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it. I can call the "help" function on an object to see its documentation or the "dir" function to view all its members and methods. I can load code at run time and patch new members onto classes or objects.
Of course, that's the classic Blub programmer paragraph. At the very least, Smalltalk sounds like a nice environment and I'm jealous of having multiple, independent object inspectors. I'm also sure that the Smalltalk documentation is better written than what I usually get from "help". Still, I suspect that I'm missing something. Especially if I'm still wrong about what it means to work directly on an object.
You are thinking about the separation between source files and the running system, but there is no such thing as a separate source file in Smalltalk. You can generate them if you wish, but it is not necessary. The code, in fact, is just a representation of the real system, which is contained in an image file.
For example, when you want to modify an object in Smalltalk, the system generates a representation of it - with methods and instance variables - and you modify the representation with the system text editor. Then you ask to system to apply the changes to the object. When the changes are applied, that is it, no source files are needed anymore. The system continues to live like this. When your "programming session" is over, you save the whole image, and starts it again on the next day. No compilation of whole system is ever performed. It is said that some objects in a standard Smalltalk image have been alive for several years... they are only saved and used, never recompiled or modified.
For example, when you want to modify an object in Smalltalk, the system generates a representation of it - with methods and instance variables - and you modify the representation with the system text editor. Then you ask to system to apply the changes to the object. When the changes are applied, that is it, no source files are needed anymore. The system continues to live like this. When your "programming session" is over, you save the whole image, and starts it again on the next day. No compilation of whole system is ever performed. It is said that some objects in a standard Smalltalk image have been alive for several years... they are only saved and used, never recompiled or modified.
> First off, thank you for your through reply
No prob.
> If I open the Bob object in the inspector and set the "deceased" member to "true", will Bob claw his way out of his casket?
Oh, I see what you meant, no of course not as the Bob object itself is a representation of the real world Bob, however if you did that your system and all of its clients would immediately think Bob was deceased.
> A lot of my confusion about whether it's the object or the representation of the object comes from this level.
I think you might be confusing classes with objects; objects are instances of a class and thus only exist at runtime, which is all the time in Smalltalk (and Lisp) and at debug time for other languages.
The representation you work on is the class, in most languages the class is a source file you edit that at runtime can have instances of itself created. In Smalltalk, the class itself is just another object in the system, you create subclasses and instances by sending messages to it; there are no source files. You don't work on source files, you work on live objects, the IDE doesn't edit files, it edits method objects from the classes in the running system. You can reflect, inspect, and browse the live running class system just like the IDE does.
> If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment.
Correct, but don't let that make you think the language isn't important as well. Smalltalk the language is amazing in a similar fashion to how Lisp is amazing; the syntax is incredibly flexible and simple.
The proof of this is that Smalltalk control structures, your if/then/else/switch/while/for/etc are not part of the language itself (discounting VM optimizations), they are simply implemented in the standard library using objects, polymorphism, and lots of higher order functions.
Just as Lisp macro's enable Lispers to add native control structures because Lisp itself uses the same mechanism, Smalltalk's simple lambda syntax [ code ] or [:arg | arg isX ] and special method naming syntax enable Smalltalk'ers to add native control structures because Smalltalk the language uses the same mechanism.
For example, you can't add your own "if" to Ruby that looks and works just like the built in "if", but you could in Smalltalk because that's how it was done in the first place. It's all library, classes and objects (functions in Lisp) and everything is built on top of that. Very few languages work this way, most have special keywords for control structures and you can't add to them.
> For a comparison point, during my day job, I write a large amount of Python in Emacs.
Great, also a great little language. Ah... but you're using Emacs, if you aren't aware that's just a Lisp image exactly the same thing as a Smalltalk image. You know exactly what working in an image is like, you do it daily.
> This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it.
Yup, Emacs is an image.
> I can call the "help" function on an object
On an object, or do you mean on a class in a file. Vastly different things. Object and class are not interchangeable words to use in this context.
> to see its documentation or the "dir" function to view all its members and methods.
I think you're talking about classes, not objects. And does this also include all source for the standard library as well, not just your application?
> I can load code at run time and patch new members onto classes or objects.
Yup, Python like Smalltalk is a very flexible dynamic language, but it didn't come out till a decade later and still isn't as flexible.
> Of course, that's the classic Blub programmer paragraph.
Yup, but at least you're aware of that, so you've un-blubbed IMHO.
> At the very least, Smalltalk sounds like a nice environment and I'm jealous of having multiple, independent object inspectors.
And multiple IDE's and multiple workspaces, windows all over the place.
> I'm also sure that the Smalltalk documentation is better written than what I usually get from "help".
Actually, honestly, you'll find very little documentation to speak of for most Smalltalk code; Smalltalker's tend to just read the source, it's there, it's simple, the average method length in a typical image last time I looked was about 7-10 lines of code, and you can just create instances of anything on the fly and play with them to see how they work, or find existing running instances and play with them.
> Still, I suspect that I'm missing something. Especially if I'm still wrong about what it means to work directly on an object.
Yup, but I think you'll understand by the time you read this line based on your Emacs use alone.
No prob.
> If I open the Bob object in the inspector and set the "deceased" member to "true", will Bob claw his way out of his casket?
Oh, I see what you meant, no of course not as the Bob object itself is a representation of the real world Bob, however if you did that your system and all of its clients would immediately think Bob was deceased.
> A lot of my confusion about whether it's the object or the representation of the object comes from this level.
I think you might be confusing classes with objects; objects are instances of a class and thus only exist at runtime, which is all the time in Smalltalk (and Lisp) and at debug time for other languages.
The representation you work on is the class, in most languages the class is a source file you edit that at runtime can have instances of itself created. In Smalltalk, the class itself is just another object in the system, you create subclasses and instances by sending messages to it; there are no source files. You don't work on source files, you work on live objects, the IDE doesn't edit files, it edits method objects from the classes in the running system. You can reflect, inspect, and browse the live running class system just like the IDE does.
> If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment.
Correct, but don't let that make you think the language isn't important as well. Smalltalk the language is amazing in a similar fashion to how Lisp is amazing; the syntax is incredibly flexible and simple.
The proof of this is that Smalltalk control structures, your if/then/else/switch/while/for/etc are not part of the language itself (discounting VM optimizations), they are simply implemented in the standard library using objects, polymorphism, and lots of higher order functions.
Just as Lisp macro's enable Lispers to add native control structures because Lisp itself uses the same mechanism, Smalltalk's simple lambda syntax [ code ] or [:arg | arg isX ] and special method naming syntax enable Smalltalk'ers to add native control structures because Smalltalk the language uses the same mechanism.
For example, you can't add your own "if" to Ruby that looks and works just like the built in "if", but you could in Smalltalk because that's how it was done in the first place. It's all library, classes and objects (functions in Lisp) and everything is built on top of that. Very few languages work this way, most have special keywords for control structures and you can't add to them.
> For a comparison point, during my day job, I write a large amount of Python in Emacs.
Great, also a great little language. Ah... but you're using Emacs, if you aren't aware that's just a Lisp image exactly the same thing as a Smalltalk image. You know exactly what working in an image is like, you do it daily.
> This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it.
Yup, Emacs is an image.
> I can call the "help" function on an object
On an object, or do you mean on a class in a file. Vastly different things. Object and class are not interchangeable words to use in this context.
> to see its documentation or the "dir" function to view all its members and methods.
I think you're talking about classes, not objects. And does this also include all source for the standard library as well, not just your application?
> I can load code at run time and patch new members onto classes or objects.
Yup, Python like Smalltalk is a very flexible dynamic language, but it didn't come out till a decade later and still isn't as flexible.
> Of course, that's the classic Blub programmer paragraph.
Yup, but at least you're aware of that, so you've un-blubbed IMHO.
> At the very least, Smalltalk sounds like a nice environment and I'm jealous of having multiple, independent object inspectors.
And multiple IDE's and multiple workspaces, windows all over the place.
> I'm also sure that the Smalltalk documentation is better written than what I usually get from "help".
Actually, honestly, you'll find very little documentation to speak of for most Smalltalk code; Smalltalker's tend to just read the source, it's there, it's simple, the average method length in a typical image last time I looked was about 7-10 lines of code, and you can just create instances of anything on the fly and play with them to see how they work, or find existing running instances and play with them.
> Still, I suspect that I'm missing something. Especially if I'm still wrong about what it means to work directly on an object.
Yup, but I think you'll understand by the time you read this line based on your Emacs use alone.
It is as if your application is always running inside the debugger.
You can change anything at any time and those changes are made persistent.
This is one reason why images are prunned for deployment.
You can change anything at any time and those changes are made persistent.
This is one reason why images are prunned for deployment.
Pruned? How do we do that? I mean, how do you distinguish the changes you want to deploy from the changes you want to drop?
Image pruning is really not a good way to do it, it's much better to take a clean base image and load your code into it as part of the deploy process. Pruning a development image is a very old fashioned way to create a production image.
Basically it already knows the system/ide classes and pulls them out, and does some code analysis to remove unused bits of code and so on. It's an interactive process, but it's generally pretty smart.
It's pretty rare that you'd actually make ad-hoc changes and then rely solely upon persistence to preserve those changes. Ultimately, you'd want to write code to produce the outcome programatically. It's more the case that you play around and do little "what ifs", which helps you crystalize your ideas about what you're trying to implement.
The trouble is that just explaining the mechanics of it doesn't really capture the experience, and if you talk about the experience on its own, you end up talking about, er, fishes. Which is to say that it's an almost useless analogy, but one that I don't know how to better.
Still, using Python to pay the bills isn't so bad...
The trouble is that just explaining the mechanics of it doesn't really capture the experience, and if you talk about the experience on its own, you end up talking about, er, fishes. Which is to say that it's an almost useless analogy, but one that I don't know how to better.
Still, using Python to pay the bills isn't so bad...
There's barely any such thing as a debugger, and no such thing as an object graph, and even modifying a function in place is far more complicated than real tools would make it -- but nonetheless, in the sort of browser-based Javascript development I do on an almost daily basis, I sense a faint echo of the je ne sais quoi to which you refer; specifically, iteratively fiddling with a live system until it behaves more like how you want, then baking those changes into the serialized form of it (also called "source code") so that they're incorporated next time the system is instantiated.
Granted, I have only the most trivial experience with Smalltalk; I'm pretty sure at least some of the concepts I have in mind here are entirely meaningless in that context, but I wonder if it would be fair nonetheless to consider the modern browser Javascript environment, for example Firefox with Firebug and a proper REPL instead of the single-line console, as potentially possessing at least some of the flexibility a Smalltalker considers de rigeur.
On the other hand, if you wanted to build, for example, an object-graph generator in pure Javascript, I don't think you could do so, at least not one worth having; unless I'm very much mistaken, Javascript's reflection facilities don't suffice to allow one thing to notice when another thing changes, unless the latter thing explicitly notifies the former of the change. So you'd have what would be essentially static analysis on running code; you could recursively walk properties from the global object on down, following references where necessary, but it'd be dog-slow in modern JS implementations; worse, there'd be no way to keep it synchronized with the actual state of the objects to which it refers, short of rewalking everything to spot the changes, which would be ugly in theory and unusable in practice. So it's probably also accurate to say that the modern browser Javascript environment offers no immediate prospect of attaining anything remotely resembling the facilities a Smalltalker considers de rigeur.
Which is a shame, because what I've seen of Smalltalk has been impressive in the extreme, especially by contrast to the tools whose use I can actually justify in my professional life.
Granted, I have only the most trivial experience with Smalltalk; I'm pretty sure at least some of the concepts I have in mind here are entirely meaningless in that context, but I wonder if it would be fair nonetheless to consider the modern browser Javascript environment, for example Firefox with Firebug and a proper REPL instead of the single-line console, as potentially possessing at least some of the flexibility a Smalltalker considers de rigeur.
On the other hand, if you wanted to build, for example, an object-graph generator in pure Javascript, I don't think you could do so, at least not one worth having; unless I'm very much mistaken, Javascript's reflection facilities don't suffice to allow one thing to notice when another thing changes, unless the latter thing explicitly notifies the former of the change. So you'd have what would be essentially static analysis on running code; you could recursively walk properties from the global object on down, following references where necessary, but it'd be dog-slow in modern JS implementations; worse, there'd be no way to keep it synchronized with the actual state of the objects to which it refers, short of rewalking everything to spot the changes, which would be ugly in theory and unusable in practice. So it's probably also accurate to say that the modern browser Javascript environment offers no immediate prospect of attaining anything remotely resembling the facilities a Smalltalker considers de rigeur.
Which is a shame, because what I've seen of Smalltalk has been impressive in the extreme, especially by contrast to the tools whose use I can actually justify in my professional life.
> Still, using Python to pay the bills isn't so bad...
Well, and pdb isn't bad.
Well, and pdb isn't bad.
It exists. That's better than the alternative, and if this seems like damning with faint praise, it's because there really isn't anything else good to say on the subject -- the debugging facilities available in any Lisp environment, even Emacs, make those offered by Python (or Perl, or Ruby, or Javascript) look pitiful, and from all I've seen of Smalltalk, it is to Lisp as Lisp is to your interpreted language of choice.
One benefit that a lot of commenters here have pointed out is very user-friendly inspection of running code. Kind of a super-REPL. I find that in Python I'm most productive in iPython's browser-based notebook interface (or Mathematica, but I find Mathematica difficult for writing things that go into web-facing applications), which offers similar features.
These notebook interfaces are REPLs, but they're a little more user friendly in the sense that you can edit history in place instead of doing a history completion and then evaluating an additional line.
Has anybody had any experience with these notebook interfaces as well as the smalltalk environment and can give a rundown of the differences?
These notebook interfaces are REPLs, but they're a little more user friendly in the sense that you can edit history in place instead of doing a history completion and then evaluating an additional line.
Has anybody had any experience with these notebook interfaces as well as the smalltalk environment and can give a rundown of the differences?
You can swim with the fish or grow up and play with the big boys (Lisp >> Smalltalk).
Symbol's function definition is void: 'Lisp'
So, it's a language for doped up hippies. That's what I got out of that. I recalled Jerry Garcia's stories about scuba diving and how it was better than LSD.
I have no clue what it means to live amongst your objects and touch and feel and turn and taste them. That article didn't really explain what that means, but I'll take him at his word.
I have no clue what it means to live amongst your objects and touch and feel and turn and taste them. That article didn't really explain what that means, but I'll take him at his word.
Here is a concrete story what happened me few weeks before, while I was working on a Nintendo emulator in Pharo. I was playing with Super Mario, and at the end of the 3rd or 4th level my emulator crashed because of some index miscalculation in a sprite drawing method. When this happens in smalltalk, a debugger window pops up, and the cursor is on the problematic line. I fixed the bug in the debugger and pressed proceed then continued my journey to save Princess Peach :).
In a live environment it is easy to make experimentations because you can get very quick feedbacks, and there is no need to switch between modes like development to execution or execution to development. Catching and fixing certain bugs is also easier as I showed before.
I think there is a need for this kind of development, that's why people try implementing code hotswapping and class reloading capabilities in various programming environemnts. But still most of them are just limited workarounds compared to smalltalk where live coding works fine for decades.
In a live environment it is easy to make experimentations because you can get very quick feedbacks, and there is no need to switch between modes like development to execution or execution to development. Catching and fixing certain bugs is also easier as I showed before.
I think there is a need for this kind of development, that's why people try implementing code hotswapping and class reloading capabilities in various programming environemnts. But still most of them are just limited workarounds compared to smalltalk where live coding works fine for decades.
If the original article had contained something like what you just wrote, it would have been an interesting and worthwhile article.
Sure, downvote me. This article says nothing. You have to be a Smalltalk lifer to get it. It's all metaphors that have no meaning to anyone outside the author's bubble.
Crap article.
Crap article.
Apologies for throwing these quotes in, but they just seem so appropriate in this context:
"Unfortunately, no one can be told what the Matrix is. You have to see it for yourself."
"After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes."
Try the red pill... (And think of turtles rather than rabbits!)
"Unfortunately, no one can be told what the Matrix is. You have to see it for yourself."
"After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes."
Try the red pill... (And think of turtles rather than rabbits!)
Sorry, this is completely unrelated, but I've been trying to email you, and it keeps bouncing. What's happened?
No idea! Try my username at gmail...
(I’m mostly speaking out of my experience with VisualWorks, a commercial Smalltalk implementation, but other implementations are similar.)
I would greatly recommend everyone to give Smalltalk a try. The IDEs are pretty ugly and cumbersome, but don’t let that put you off. Get a feeling of the minimalism of the programming language and the pure form of object orientation. Dig through the code of the standard library — it’s quite easy — and check out the implementations of TrueClass, FalseClass, BlockClosure etc.
Unfortunately, many parts of the Smalltalk IDEs are horribly outdated and make Smalltalk a very poor choice of environment to use for production code.
Smalltalk lives in its own little world, and the tools that you’d normally use during day-to-day development are integrated in the IDE, and there is virtually no possibility of using external tools. The text editors are pretty bad, and you can’t use vim or emacs or Sublime Text. The Smalltalk VCSes are particularly horrible. For version control, you need to use systems such as Monticello or Store, both of which make me cringe just thinking about them again.
I also feel that Smalltalk coders get locked in into their environment. Many Smalltalkers that I have met are quite unfamiliar with what is happening in the outside world. Most of them have never heard of git, for example (and quite a few did not know what Subversion was). When an interesting technology enters the Smalltalk world, people seem to rush to reimplement it in Smalltalk (yes, there is STON — Smalltalk Object Notation).
These were the main reasons why I quit my Smalltalk job. A sad decision, but one that was unavoidable in the long run.
Smalltalk is a nice language and has IDEs with some very nice features that I would love to see in other environments, but it is also severely lagging behind in many other areas. I would like the Smalltalk community to be more aware of what is happening outside and build bridges. Without that mindset, I feel Smalltalk will simply fade out completely.
Source: I used to be a professional Smalltalker for almost three years.