In a recent post, Christopher Petrilli speculates on why people don't get Smalltalk. This response remains only half-baked, but I'm choosing to let it go anyway. To quote:
Also, it reminds me a bit of what happened when I worked on Zope and the ZODB (Zope Object Database), which contained almost everything originally for the system. People wanted to work on things as though they were files. There were two reasons for this.
First, the tools sucked in Zope. A HTML textarea is not an acceptable editor. This was eventually resolved with FTP and WebDAV support. The second, though, was an innate distrust of the object database for some reason. Even though it was an append-only, transactional, recoverable, storage system, people would rather store it in a brain-dead file system because they felt it was "safer." Irrational, completely and totally, and much of the same criticism is launched at the concept of system "images" in Smalltalk.
I think it's wrong to underestimate the problems with Smalltalk's system image and the ZODB. In fact, I'd say the image is perhaps the biggest problem with Smalltalk.
Well, starting from causes, I think Smalltalk's insularity is its greatest flaw. This is in part because Everything Is An Object, and objects have fairly specific conventions. There's a considerable barrier between The Rest Of The World and Smalltalk. It's not just that the syntax looks weird to people -- though that doesn't help -- but it also looks weird to other programming languages. You can't easily map C or other libraries into Smalltalk. You can't make analogous interfaces to the interfaces found in other languages -- you can't even make a freakin' function! Sure you can do everything you need to without functions, but you can't directly map other system's APIs onto Smalltalk syntax, which means you can't map people's past programming experience, or their past programs. (It doesn't help either that Smalltalk's OO nature encourages everything to be a framework, instead of building mere libraries, but that's a topic for a different day)
These could be resolved if someone really wanted to do so (though no group of people seems to want it enough to effect the basic culture of the language in order to break down that insularity of syntax). But the image provides other problems. The image isn't strictly required -- I believe GNU Smalltalk has no image, or at least got along without one at one time, and the Smalltalk-ish Objective C has no image. But the image has become an almost fundamental part of the Smalltalk environment, and the environment is hard to disassociate from Smalltalk itself. You can't write scripts for Smalltalk, except for scripts that work in the Smalltalk environment (doIt kind of scripts). You can't run Smalltalk from the command line or as a CGI script. (This is true of Java too, but Java succeded despite this due to extreme effort on Sun's part.) It's also hard to isolate a "program" in Smalltalk -- it's all one big heap of code, you may have added methods to Object, who knows what. This customization/localization of the environment is something where Python has successfully resisted, Ruby is backtracking on, while Perl is commiting suicide to allow total customization based on Wall's personal philosophy and that language's bizarre community.
I'm sure Smalltalk has tools that solve this too. But I think those tools are basic prerequesites to a successful language, and I don't know if the Smalltalk community has treated them as such. Many of Smalltalk's tools seem to be so commercialized that it doesn't seem like it matters much. Some happy Smalltalkers in the financial community get to try all this stuff out, while the larger world doesn't have access -- and so the rest of the world stopped caring. At least the part of the world that was willing to pay attention to cool technical stuff. The corporations that could shell out the cash aren't what drives technology advancements, because they are too concerned about risk, and anyway, corporations don't create things, only people do.
Well, that's a long diatribe. And I feel like I have only just begun. Anyway, I think Smalltalk is too perfect. Its ideas may one day have their time. Maybe the idea of a "program" will go away some day -- I personally would shed no tears if it did. But Smalltalk doesn't offer us a path from here to there, and the world isn't willing to jump all at once.
Update: Please read or comment on this post, which I hope will be less misunderstood.
Right before Java burst onto the scene, IBM was putting considerable weight behind Smalltalk in their efforts to have a business language that could move across systems [ie, as agents, etc]. It would have been interesting to see what would have come of that.
Ian - see my response here:
http://www.cincomsmalltalk.com/blog/blogView?showComments=true=3256315899
Seriously, take a look at a Smalltalk system before you let loose with so much misinformation again....
>you can't even make a freakin' function!
Actually anonymous functions are first-class in Smalltalk, so you can store them in variables, and pass them as parameters and...
Does Java have functions? C#? Eiffel?
They are OO languages.
If a static final method counts as a function then just define a class side method in Smalltalk.
> a long diatribe
a not very informed diatribe :-(
# Isaac Gouy
>You can't easily map C or other libraries into Smalltalk
Looks like you never really looked at Smalltalk and it's flexibility.
Some examples: VisualWorks has DLLC-Connect to easily import and wrap
C functions into Smalltalk. Smalltalk MT, a windows based Smalltalk can import
any C DLL and you can call it in any Smalltalk method with Smalltalk Objects
as arguments using the WINAPI as receiver. So you can easily write:
|result|
result := 100 factorial.
(WINAPI MessageBox: NULL
with: result asString
with: 'Can you do this in another language'
with: MB_YESNO | MB_ICONHAND)
But it's alway better to encapsulate this API call in a class method (for instance
as #owner:text:title:style: method in the class MessageBox) so you can write it
more readable:
|result|
result := 100 factorial.
MessageBox owner: NULL
text: result asString
title: 'Can you do this in another language?'
style: MB_YESNO | MB_ICONHAND
The keyword message tell you what the arguments are, this is much more readable.
Or have a look at the new S#/Smallscript language. Internally it's a normal Smalltalk
which is able to support different syntax styles, so you can either write:
User32::MessageBox(NULL,'Hello','World',0)
which is more C-Style or
MessageBox
owner: NULL
text: 'Hello'
title: 'World'
style: 0
which is Smalltalk style. More C-Style in Smallscript:
stdout << 'Hello' << 'World'
or the Smalltalk way
stdout
nextPutAll: 'Hello';
nextPutAll: 'World'
You may say that the C-Style is shorter, but Smalltalk is more readable (even
to non programmers who dont know about the "<<" operator)
Since the Smalltalk language is defined in itself you are able to add
syntax suggar to any Smalltalk language out there - but typically you
dont want to mix C-like syntax with the much easier Smalltalk style ("Object
receives message"). Most ST systems hide API stuff in designated classes
to get independent from the underlying system and stay portable.
Another example:
C/C++ and Smalltalk have no "repeat until" language construct by default
(even if it can be simulated with other language constructs, there is no
repeat until keyword). The Pascal language has one.
If you want it too in Smalltalk you are able to change you Smalltalk system
just by adding a method #repeatUntil: in the block closure class.
Now you are able to write:
|count|
count := 0
[ Transcript show: count printString.
count increment ]
repeatUntil: [ count = 3 ].
You should also note that a smalltalk block ([...]) is a normal object so you
can construct and call it at runtime!
To get support for a new language construct in other languages you typically
have to change the parser/compiler or ask the vendor to do that.
Another example:
Most commercial Smalltalk systems dont support Interfaces (as Java does).
But if you need them you change the system or install the "SmallInterfaces"
package and you can work with them in Smalltalk too.
People switch from language A to B because they like a new feature in B.
They start to port all their code to language B and feel happy until
language C appears.
The main problem is that the IT continuously start to solve problems with
new languages instead of focusing on the problem they want to solve.
People will never get the power of Smalltalk if the continue to compare
it with A, B or C or lament about it's syntax.
Smalltalk is not only a language - it's language is mapped to a dynamic
object system. So if you need Interfaces, Enums, Structs, Pre-/Postconditions,
new language constructs, ... you can easily add them if you need.
If you talk about Smalltalk using an image, I can just quote Kent Beck:
"Source code in files. How quaint.".
Bye
Torsten
# Torsten Bergmann
Hmmmm. I seldom respond to blogs but this time I just couldn't hold it back.
Whatever happened to the concept of sticking to at least a few facts? Let me just add a few:
The "can't make functions" is just totally bogus. Heard of blocks? Heard of class methods? In fact - Smalltalk can handle "functions" even better than say Java.
The "can't interface with libraries" is totally bogus too. Has been trivial to do that in a number of Smalltalks since years and years. Personally I know it is dead easy in Squeak, VW, Dolphin, Smallscript and probably a bunch others too.
The "can't do command line stuff/scripts" is... have a guess? Bogus. I can mention a few Smalltalks that excel at this like GST, Smallscript or SharpSmalltalk but it is also trivial to do using say Squeak which hasn't even focused on it much. Why? Because image based development is preferred by anyone who knows diddly squat about Smalltalk! Sigh.
Ugh, lost the energy to correct even more glaring faults here. And don't bother emailing me if you are not interested in learning something. I should have learned by now that discussing languages or tools with people who only know one side of the things compared is just hopeless.
/Göran
Unfortunately your tool removed the formatting of the Smalltalk code
in the above examples, so it would look much better with the correct
tabs in it.
Torsten
# Torsten Bergmann
One word: FUD.
it's funny. these people talk like smalltalk will come back from the dead.
# anonymous
My dear friend... when you learn to program, maybe you'll use smalltalk. Keep in C, at this moment it's enough for you.
# Alberto Torres