Smalltalk scripting syntax

Paolo Bonzini wrote:
>> Sorry, but you've got me confused.  What you've
said above is the exact
>> opposite of what I understand by
"scripting".  Scripting is an
>> interpreted dynamic on-the-fly kind of thing.
> 
> Scripting is also about lots of libraries that are easy
to use and easy
> to write.  Which means, having good tools for
documentation, cross
> referencing, and so on.  Such tools need to understand
the structure
> the program, they cannot just rely on self-discipline
of the library
> writers.
> 

Your argument does not invalidate my concern or rather it
does not
justify taking away something that users appreciate for
something that
tool writers like better.

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) on tools and you'll have a language
that will be
barely usable *without* them.

Slightly off-topic stuff follows.

I am here because I liked what I saw when I started playing
around with
Smalltalk.  GNU Smalltalk is the only variant I've ever used
and I
haven't considered using others because most of them seemed
to be huge
custom graphical environments and weren't free software.  I
looked at
GNU Smalltalk and thought "hey, this is something I'd
want to use and
spend my time on improving".  I already mentioned (in
the other comment)
things that I see as needing attention, which is
documentation
(including the web site) and package management, and I'm
willing to help
as much as I can because I see potential (for the lack of a
better word)
in this language and in this variant of the language in
particular.  The
language that it's being turned into is not that language.

(By the way, I can't be the guy who just hates everything
new because
two months ago I literally didn't know what Smalltalk looks
like.)

Best,
Jānis


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> 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


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk