Re: LFM + LFSP = LFE?

[Jay Sulzberger <address@hidden>]

On Fri, 13 Jun 2003, Avi Bryant wrote:

>
> 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?
>
> 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

Having a file format for Squeak code is part of object orientation.  An
object can be picked up and moved from place to place, and yet remain, in
some aspects, the same in the new place as it was in the old.

Squeak is very good and I think its file format should be good too.
A good file format system for Squeak should provide that:

1. A file object have an installation method which should work cross
several Smalltalks, and further, should be callable from the command line
of standard *n*x shells, and, in case the installation succeeds, result in
a Smalltalk image with the file object loaded, even on systems without any
Smalltalks before the call.

2. A file object have a history faculty, which respects the original file,
as a piece of text, and all the versions, as text, and cleanly separates
the meta from the source texts.

oo--JS.