[Help-smalltalk] Directions for GNU Smalltalk (was Re: [RFC] Smalltalk scripting syntax)

[Paolo Bonzini]

> Smalltalk provides sufficient documentation features that can easily be
> extended;  if you choose not to use them you should not expect your code
> to make much sense.  I believe that's what we fundamentally disagree on.
> A library writer isn't a library writer if he doesn't document and
> doesn't write self-documenting code, whatever the language.  Put too
> much emphasis (though I haven't heard of languages being modified for
> reasons like this one)

Because no other language worked so well for years without tools (Smalltalk
barely has tools).  Most other languages either have a syntax that is not
a revolution at all (including Python, Ruby) or have no tools (Tcl comes
to mind, and it fell out of favor compared to the other two or even Lua).

Smalltalk bang syntax is a revolution.  It describes executable code (not
in the sense of "interpretable", as is Ruby or Python syntax) that
reconstructs a working environment.  It's great for some things (i.e.
reconstructing changes to an image after a crash, in IDEs like Squeak
or VisualWorks), it's bad for (almost all) others.

In particular, it's bad for:

1) tools.  We can make a syntax that is as
good as Python or Ruby's (and as non-revolutionary as those) and still
pretty close to Smalltalk.

2) everyday scripting.  You need a more dynamic thing, where every
statement is executed oon the fly and there's no need to declare
temporaries.  I learnt this from your examples in this thread and
I will implement it -- but it's orthogonal to the verbosity and tools
problems.

> on tools and you'll have a language that will be
> barely usable *without* them.

This is a bold statement, and I want to understand more of it.
How can you be sure?  Do you consider Ruby or Python barely usable
without tools?

> I already mentioned (in the other comment)
> things that I see as needing attention, which is documentation
> (including the web site) and package management

Fully agreed.  If time permits, package management may also
make it into the next release (I'm sticking to one-year releases
usually).  If you have ideas for improvements and maybe time to
implement them, we can only be happy about that.

> The language that it's being turned into is not that language.

This is also a bold statement.  Please expand on it, I'm genuinely
interested (they even deserved a subject change!).

Paolo