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

[parasti]

Paolo Bonzini wrote:
>>>> 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?

I've written some stuff about this below, I hope that'll make it clear.

I do not necessarily advocate the actions that take place under the hood
when, say, an exclamation point is encountered by the parser.  As far as
I'm concerned, due to Smalltalk's free-form syntax, statements need to
be terminated.  A period would be perfectly fine for that as well.  To
put it simple I am "against" the proposed modifications and not
necessarily "for" the current situation.

>>>> 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).  

Smalltalk's paradigm is objects and messages.  Smalltalk's syntax is
basically "object message".  There are practically no exceptions to this
rule.  It's a one-to-one mapping from a paradigm to syntax;  the syntax
fully represents the language.  What I meant in my last reply is that
the proposed syntax violates or rather ignores that aspect.  Perhaps
what you really want is a language that looks like Smalltalk, but
doesn't have these "limitations" -- there's no sin in that.  Just don't
call it "Smalltalk".

Python's syntax is flawed and I recognize that.  It's only truly
marvellous property is the "indentation matters" rule.  To the point,
just because you can get something better than Python doesn't mean it
will be better than what you have right now.

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

I personally think the problem is that the commonly-used class
definition selector contains classVariableNames and not
classInstanceVariableNames.  (Or a shorter equivalent.)  Thus I don't
see it as a problem with the syntax...

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

Heh.  I do not expect anyone to immediately jump in on implementing them
and I'm entirely aware that they might not ever get implemented.  No
problem there.

Jānis