Smalltalk Considered Unfriendly
28 February, 2007
Is it true that Smalltalk is too isolated and suffers from extreme shyness? Do we need to learn to play, reach out and integrate better with other languages and tools? Check out Alan Lovejoy‘s article: Smalltalk Considered Unfriendly
The Weekly Squeak 
28 February, 2007 at 21:54
It is sad to say but SmallTalk is too monolitic for the last ten years of Programming Language Evolution. The real missed point is: how is it easy to add stuff to a language? Perl, Ruby and Python have a very simple set of concepts build around the “module” word. Everyone can add stuff to these languages, and this stuff will work even with future release.
All this three languages have a global repository, simple to use.
SqueakMap is nice, but was harder to carry out, and still is far from perfect.
In Smalltalk, migrating code from Squeak X.y to Squeak X. (y+1) is a pain, if you are based on other libraries. This is the big problem in my own opinion
1 March, 2007 at 11:20
Giovanni,
you are referring to Squeak, where topics like the one you mention make life harder than in other Smalltalk implementations. The picture is quite different in the commercial Smalltalks: look at VA Smalltalk, VisualWorks or Dolphin. It is easy to create modules, frameworks or whatever you might want to call this stuff and it is easy to load it into an image.
Where exactly do you see Smalltalk fall behind Ruby or Python wrt building / distributing modules?
4 March, 2007 at 20:15
The essays would have been relevant 5 years ago, but now things are swinging back the monolithic way (e.g. every modern web framework has it’s own web server).
19 March, 2007 at 17:37
As a linux/Squeak person one project I have wanted to do but never found the time is to build a Squeak based linux shell to use instead of bash/csh/sh. Let’s call this shell squash. Squash should more or less be able to replace these shells so that I could use Squash as my login shell.
Also, I should be able to write a squash shell script
functionally equivalent to a bash script or sh script.
The difference is that a squash script should be squeak code or something close to it. In particular the squash shell
should be a smalltalk running image and all standard code in a squeak image should be available.
The one big drawback of squash is that while squash can
run a bash script or sh script. Bash and sh would not
be able to run a squash script since they not running a smalltalk image. (Starting a squeak image to run a squash script would be too slow I think.)
The nice thing about a squash shell or shell script
is that they would be portable across operating systems,
dependent upon the contents of the scripts themselves of course.
Then connection of all this to the “friendly Smalltalk issue” is that this would be one way of developing smalltalk friendly code. It certainly doesn’t solve all the problems but it helps.
Ralph