Re: LFM + LFSP = LFE?

[Michael Vanier <address@hidden>]

> Date: Fri, 13 Jun 2003 18:20:10 -0700 (PDT)
> From: Avi Bryant <avi@beta4.com>
> 
> On Fri, 13 Jun 2003, Paul Prescod wrote:
> 
> > Okay, fair enough. But it seems to me (as just a guess) that there must
> > be something about Smalltalk that dissuades people from just using it as
> > if it were Ruby. After all, if it were as good as Ruby at scripting and
> > as good at Smalltalk at introspection one would expect it to be more
> > popular than Ruby (or Python, or ...). One would also expect Fowler to
> > be smart enough to realize that he could stay in the language he loves
> > and yet use the text-based environment he is used to. Is there something
> > in Smalltalk's model that discourages him from using it as a text-based
> > scripting language?
> 
> That's certainly an interesting question, and it relates directly to
> Mike's question as to why nobody has come up with a scripting-friendly
> format for Smalltalk code.  I claimed that it would be trivial to set up a
> Smalltalk image to play more or less like a Python or Ruby interpreter,
> but the fact is that nobody has bothered to do it yet.  Why not?
> 
> I've considered doing it a couple of times, but it always ends up being
> too absurd to think about.  It's a bit like asking why someone hasn't come
> up with a punch card syntax for Python - it's possible that you could ease
> adoption for people that were used to programming that way, but would it
> really not be easier just to teach them to use an interactive text editor?
> If such a system existed (either punch card input for Python, or text file
> input for Smalltalk), would anyone actually use it for more than a day
> or two before figuring out that there was a better way of doing things?

Hmm... sounds an awful lot like lisp programmers saying "why would anyone
want to use a non-s-expression-based syntax when there's clearly a better
way of doing things?"  I agree with that sentiment, but that isn't going to
change the way people are.

> The other problem is that although the basic scripting support would be
> easy, it would take a long time to make all of the tools and libraries in
> Squeak command line friendly.  There's no textual UI for the Debugger, or
> the SUnit TestRunner.  Nobody bothers with HTML API docs because it's
> easier to just browse the code in the image and look at the comments.
> Even if you did build a JavaDoc like tool to extract these comments, they
> were written assuming that you could see the code, or select and execute
> bits of them as you were reading them.  There's a deep cultural assumption
> that anyone using the code is using it from within the Squeak environment
> - why wouldn't they be?
> 
> If anyone actually thinks that a clean, "scripting" file format for Squeak
> would make them much more likely to use/learn Smalltalk, then I will take
> an hour this weekend and hack something out.  But I would really recommend
> that these people take the time to try out the full environment instead.
> And if Squeak is too odd looking or intimidating (it was for me the first
> 2 or 3 times I looked at it), then try a more sedate dialect like
> Smalltalk/X (which is freely available for Linux and Windows, and very
> nice except that it doesn't support full continuations).
> 
> Cheers,
> Avi
> 

I'll give you a couple of reasons why I would like this:

-- I've never liked the fonts in squeak.  It took me quite a lot of work to
   import fonts I *did* like into squeak.

-- The browser environment, nice as it is, cannot compete with emacs as a
   code editor (although emacs doesn't have the browsing features... it
   depends on what you value more).

-- I want to be able to write scripts in smalltalk that I can use
   transparently from the command line, just like I would do with python or
   ruby.

Consider the gauntlet thrown ;-)  BTW GNU Smalltalk gets around some of
these problems, although you can't start the file with 

    #! /usr/bin/env gst

to make it executable like you can with python.  Also, there's the syntax
issue.  I think a deeper issue is that python (and ruby, and PLT scheme)
have a notion of modules that goes beyond anything I've seen in Smalltalk
(although I gather that this is a big topic of current debate).  Not having
a decent module system is pretty much a show-stopper for modern scripting
languages; I'm glad that the PLT folks have put so much effort into theirs.

Mike