Smalltalk Considered Unfriendly

Comments

4 responses to “Smalltalk Considered Unfriendly”

1. 

   28 February, 2007

   Giovanni Giorgi

   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

   LikeLike

   Reply
2. 

   1 March, 2007

   Joachim

   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?

   LikeLike

   Reply
3. 

   4 March, 2007

   Jason

   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).

   LikeLike

   Reply
4. 

   19 March, 2007

   Ralph Boland

   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

   LikeLike

   Reply