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

[Paolo Bonzini]

>>> Put too much emphasis 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?
> 
> Heh.  It's a bold statement, I agree.  No, I do not consider Python to
> be useless without tools.

Ok, so this gives me some confidence that you didn't mean the
proposed Smalltalk extension to be useless without tools.
Ironically, I consider current Smalltalks to be barely usable
without tools (browser), given the problems with the bang
syntax.  AFAIU, you consider the bang syntax amendable instead;
this may be the main disagreement, right?

> Which is why I don't really
> need anything else than a text editor and Python.  Hell, I don't even
> need the text editor.

I can tell you it's the same with Smalltalk -- both current and
proposed syntax.  But the productivity will improve a lot, I think.

Besides, it is just syntactic sugar, you can steer away from it
or you can try it.

>>> 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!).
> 
> It's entirely my own opinion and it's based on one simple fact:  I
> wouldn't use it.  I find that the changes you're proposing address some
> of the things that I like most about Smalltalk (extreme simplicity, one
> paradigm)

Here is where I don't understand your point.  The syntax
doesn't add paradigms.  It only touches the most basic constructs
of Smalltalk, which are the ones that are used to structure a
program -- classes, methods, namespaces.  These changes surely don't
add as much complexity as there is in Python's syntax (iterators, for
example: if these enter the GNU Smalltalk class library, it will not
grow new keywords like "yield"; likewise for splicing).  

In fact, the class/class-instance variable example shows how the
new syntax emphasizes the duality between instance variables/methods
and class-instance variables/class methods, while the current bang
syntax only expresses this for the methods, and suggests a wrong
correspondence between instance and class variables.

If a syntax helps improving one's language usage, I find that a
good point in favor of it.

As far as scripting, your suggestions will not be implemented immediately
due to lack of time, but they are a prerequisite for the next release.

Please, tell me which points you disagree on.

Paolo