Building a string from incompatible objects.

On Mon, 8 Jan 2001, Costas Menico wrote:

All I meant was that you are now in the position of saying "that's too
much" vs. someone saying "I find this readable, typable, and useful". It
helps emphaize that this is somewhat a matter of taste. Of course, taste
is *very* important. On the other hand, we should be careful not to assume
that our own taste is representative.

> On the otherhand I feel Smalltalk is not a
> religion either.

Faugh! No one has even remotely suggested that. Or acted as if that were
the case. Certainly not me. Argue against the actual arguments, not
against the alleged "forces of retrograde purity" :)

> It's a real computer development environment and does
> need some enhancements to fulfill user needs.

The problem, of course, is *indentifying* those needs, providing an
enhancement that *fulfills* those needs, and making sure that 1) there
isn't something better and 2) it's not disruptive of other needs.

I fully accept that *you* have such a need. I tried to identify where
fulfilling that need by adding the particular message you desired with the
particular semantics wasn't an overall win when standardize, and when not
standarized, wasn't a win for you if you want to share your code. I
identified other ways of meeting those needs that may make trade offs
between being *as* satisfying to you (considering the problem in
isolation) and not being disruptive wrt to these other needs. By all
*means*, if you like #++ use it. I'll bet that the first thing most peple
will do with your code is replace all uses of your #++ with something
else.

If this doesn't bother you, end of story.

If Dave Harris convinces me that he has an operator family that is
coherent, readable, and worth the trouble of learning, then you may well
have something new that you'll like using and that will have two other
folks pushing it.

> If Smalltalk's mission
> is to develop real world applications

A mission successfully accomplished for *decades* without anything like
#++. Indeed, *many* languages lack auto-coercing concantination operators.

Funny that.

> then market demand and vendor
> competition will make it happen.

If this conditional is supposed to show that #++ will win because it's
necessary for developing real world applications, then I don't think it's
correct :)

Cheers,
Bijan Parsia.

"James A. Robertson" <[hidden email]> wrote in message
news:[hidden email]...
> David Simmons wrote:
> >
> > <[hidden email]> wrote in message
> > news:[hidden email]...
> > > On Mon, 08 Jan 2001 14:58:51 GMT, "Boris Popov"
>
> IMHO, it's not that the language is sacrosanct; it's just that changing
> the syntax (rather than adding methods/classes) is (IMHO) not the best
> route.  Adding complexity isn't a great idea.

Hi James. It's good to see you jumping in before my opinions get out of line
;-)

I agree with you that adding syntax (sin-tax) for its own sake or for mere
convenience is not a good idea. I also agree that adding complexity is not a
good thing. In my strongly held viewpoint, complexity is the antithesis of
what Smalltalk is or should embody as a language and as a complete
platform/system.

I say this with the full recognition/acknowledgement that I have been quite
active in extending Smalltalk for the last ten years. Some of my work in
this area may be flawed or I may not have taken enough care or deliberation
in designing or developing it, but I'd like to believe that I've
continually, in that effort, tried give all such work due deliberation and
consideration.

There was a lot of discourse on the original thread from which this post is
derived, so I will restate my opinions regarding some of the ideas
presented.

First, I was originally informing the participants in the thread about QKS
use of the ${...} operator syntax. I also lobbyied for the ${...} operator
syntax to be used if any syntax was to become standard; and I gave
hints/suggestions about how to add it to a compiler.

I gave a limited set of arguments for the viewpoint of adding this syntax. I
can appreciate and understand dialects not wanting to add any new syntax,
let alone this one.

Second, I was generally opposed to any other syntax suggested.

Third, I suggested using the #<< family of messages as a means for extending
stream protocol to achieve some of the originally posted questions/ideas. I
gave various examples and rationale for using this familiar set of binary
messages.

My initial involvement in the discussions was only to provide this
information to expand posters mindshare on the topic. As I saw more ideas
and discussion unfolding I extended my position to lobby for using the #<<
family of selectors if any such family was to make its way into multiple
dialects or public frameworks.

Fourth, I gave a variety of comments and/or arguments against some suggested
ideas. Particularly I was strongly opposed to the idea that the #<< message
should be universally defined to convert the receiver to a Stream if it was
not one already. This would, in effect, be the same thing as turning the #<<
message into an operator (in much the same way that isNil, notNil, class,
ifTrue:... messages are effectively operators).


-------
SIDEBAR:
-------
I should also add that, historically, the vendors seem to have had minimal
to no collaboration regarding their efforts to extend or alter Smalltalk the
language or Smalltalk the common vernacular. There are changes that have
been made to Smalltalk, there are inconsistencies among dialects, and there
are things that are really worth consideration for availability among all
dialects.

I've been, perhaps to the annoyance of some, fairly strong/agressive in my
efforts to evangelize the idea of exploring change and for ideas of
standardization/extension (and especially vendor collaborative extension) of
Smalltalk's capabilities.

I wouldn't be surprised to find some people viewing some of my
approach/dialogue as being downright arrogant, but it is sometimes hard to
know how best to encourage exploration in this area (so breaking eggs to
make the omelete is necessary). I've also learned that taking a bit of a
stronger view than one really feels is sometimes necessary to "stir-the-pot"
sufficiently to create a catalyst for discussion.

With regard to my posts involving SmallScript, I thing it is probably
obvious to most frequent cls readers that, for me, it represents a
culmination of my experience and development efforts in this field over many
years.

I'd like to believe that the work on SmallScript (which is NOT smalltalk,
but IS a new language that subsumes Smalltalk within it) has some
fundamental new capabilities. My posts periodically bleeding through with
some of my personal frustrations at losing nearly 5 years of time in
enabling Smalltalk to have access to exploring and benefitting from some of
its facilities and overall issues for me with bringing it together because
of my/QKS mistakes and Smalltalk and Apple market related problems doesn't
necessarily assist/help my other goals.

I believe that growth and active involvement and discussion of technical
issues and their rationale not only strengthens the language, but provides
an attractive venue for education and community interaction (activity,
discussion, and exploring the frontiers of computing ideas are always good
attractors for community growth and education).

The discussion and exploration of ideas does not mean that all (or perhaps
even most) discussed or proposed ideas should be adopted or their use
encouraged; but encouraging and nurturing discussions about them is a
benefit for everyone.
-------

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

>

[...snip...]

>
> --
> James A. Robertson
> Product Manager (Smalltalk), Cincom
> [hidden email]
>
> <Talk Small and Carry a Big Class Library>

David Simmons wrote in message ...
>"Dave Harris" <[hidden email]> wrote in message
>> How much do you know about early (circa 1971) Smalltalk? As far as I can
>> tell, a message send resulted in the entire message being sent to the
>> receiver and the receiver effectively parsed it, giving it more control
>> over the syntax than now.

That's right.  Every object receives a sequence of unevaluated tokens from
the message send.  The heart of each object is message receiving code --
essentially a pattern matcher that makes sense out of that sequence.  The
matcher ("programmable method dispatch") typically looks at the first token
("a selector") and then decide what to do with the rest, evaluating some of
them in the process.  So the matcher language is the real language core, the
message passing and dispatch are a library on top of it.

This is all in present tense because Smalltalk-72 is alive and well.  Dan
Ingalls implemented the core interpreter and key primitives of ST-72 to run
inside a Squeak image.  Gave me that Jurassic Park feeling first time I saw
it.  It is available together with the system source (there was no image
back then; the system boots by loading the source).  The source and the
comments make a very interesting reading by itself (ever wanted to know a
map of Alto hardware registers?)

The syntax is very different and with the difference in how the language is
built, ST-72 is a totally different language.  Especially the first time you
see it in a "proper" font, with all the eyeballs and pointing hands.  There
are a few interesting glimpses of roots of the current syntax, like you can
see where the leading colon of a block argument declaration comes from.

>I've never read that paper; I'll have to find it (unless you perchance mail
>it to me :). But I was aware that the syntax of early Smalltalk
>implementations was much more flexible.

It was published in _History of Programming Languages, Part II_.  Hopefully
the online version also includes the illustrations the printed one has.
There is also an appendix explaining the design and giving the interpreter
source (one page of a fairly transparent language).  This seems to be an
earlier version of the language than the one used in the examples in the
paper itself, and also a few things were apparently mixed up in typesetting.
(You notice it if you try to implement something based on that).

--Vassili

On Mon, 8 Jan 2001, David Simmons wrote:
[snip]

Wow. Lots of stuff. I'm way to wacked to say much useful except: Get
SmallScript out there so we can play with it! ;)


> > Apologies if you know this stuff better than me - which is quite likely.
> > Most of what I know comes from Kay's "Early History of Smalltalk" paper,
> > which I found online recently.
>
> I've never read that paper; I'll have to find it (unless you perchance mail
> it to me :). But I was aware that the syntax of early Smalltalk
> implementations was much more flexible.

First, I'll point to some generic cool history papers on:

        http://users.ipa.net/~dwighth/

http://users.ipa.net/~dwighth/smalltalk/St76/Smalltalk76ProgrammingSystem.html

Does Smalltalk-76, with nothing about syntax extentions.


I wish Parc would put the Smalltlak-72 Instruction Manual online, then
list it on their historical docs page:

        http://www.parc.xerox.com/publications/pubs-hst.html

But here's a good message from Alan to the Squeak list:

        http://www.egroups.com/message/squeak/15947

"P.S. At PARC we had complete control over our character sets and fonts,
and very little interest in ASCII...  Smalltalk-72 could deal with
sequences of keywords with spaces in between them -- and it was a
"zero-overhead" extensible language: that is, each class was defined as a
syntactic recognizer of the messages it could receive in a very
straightforward manner. The resulting syntax was much more "scripting
like" than Smalltalk-80 (and even quite a few of today's "scripting
languages").
     This was a really good idea for a while, but started to degenerate
into a Tower of Babel via poor choices for syntactic forms in the heat of
programming (even by good programmers).
     Smalltalk-76 (by Dan) was a really interesting meeting ground between
a compilable and a readable syntax. Smalltalk-80's syntax (I
believe) could have adopted a stronger theory of uniformity that would
have yielded more pleasing results (I don't like it).
     I still like the idea of easy syntactic extension (and most of the
possible routes to metaprogramming), but experience seems to say that
"making it easy" should not generally be the same as "put it at the same
level of expression". There should be "fences" that you have to jump over
to do the metaprogramming, but once jumped, the metaprogramming should be
easy and not obscure .... (Squeak needs a LOT OF WORK to be in accord with
this principle.)"""

> My (most likely flawed) understanding was that it had conceptual features
> for altering the syntax; like lisp (no surprises here if you're have some
> knowledge of the trends of that day and of the Smalltalk developer's
> eventually direct rivalry relationship with lisp developer's where Smalltalk
> was the younger and significantly less respected sibling). Based on what
> you've described it would have been a very slow interpreter -- which I would
> guess would have been a significant motivating factor for changing it.

 From what Alan wrote above, I don't think so.

The *really* cool thing is that you can run Smalltalk-72 in Squeak:
        http://minnow.cc.gatech.edu/squeak/989

(Note I forget which version of Squeak this was released for. I'm pretty
sure they plan to role it into the main release, as well as a Smalltalk-76
simulator.)

> Based on my direct discussion with Alan (in the early-mid 90's) about the
> early evolution of Smalltalk, my understanding of the very first versions of
> Smalltalk were that it's design/implementation was simple and had very
> limited relationship to the Smalltalk's available by the early to mid 90's.
[snip]

My impression is that there wasn't a lot of focus on the VM or tuning the
GC, but the class libraries I suspect were more Squeaklike in their
constant flux.

Cheers,
Bijan Parsia.

On Mon, 8 Jan 2001, David Simmons wrote:

It's the person who comes in to poof your pillow.

> And what did Bijan mean when he used
> the phrase "anti-fluff"?
[snip]

Just that some of us were whining about #++ the auto-coercer as being a
bit of silly fluff, and here Costas was saying that the operator that
added a space was somehow "too much" ("This to me is fluff.")

I was just struck my his resistance to what was essentially his own
position on the very same basis that others did his original proposal.

We could run the whole debate all over again with a little substitution
except that Costas would be on the side of the angels this time :)

Of course, *that* part of the debate has degerated into ye olde "My
favorite language has foo and if you wan't to attract millions of people
the way my favorite langauge does, you'll have to drag yourself out of the
mire of hoary language purism and adopt foo. It's marketing. You must
understand marketing. Otherwise Smalltalk will continue dying." As boring
as it is fallacious.

The interesting part of the debate (investigation rather) has split into
the (going strong) "what're some good general ways of easing string/user
message construction/printing?" and the (kinda quiet but getting some
steam) "how do we handle significant syntactic variation?"

Cheers,
Bijan Parsia.

David Simmons wrote in message
<2Qs66.101422$[hidden email]>...
>Costas,
>
><opinion>
>I've monitored this thread pretty much from the beginning. I don't
>understand the semi-antagonistic attitude some posters have had to your
>ideas (well actually I do, I just wish I didn't). You openly asked for
>advice and ideas, you proposed and explored many ideas in the spirit of
good
>discourse.
>
>In that same spirit some people disagreed with some ideas (some other
people
>chose to make comments that were not exactly in that spirit, and I for one
>wish they wouldn't expose their attitudes so plainly).
>
>It's a great thing to have open hearty debate and discussion and voice
one's
>opinion on the topic, its a whole other thing to criticize/denigrate the
>individuals participating in such discourse.

I don't think spirit of good discourse precludes antagonistic attitude, as
long as that attitude is towards ideas rather than the poster.  I very much
enjoyed the discussions started by Costas, as they made me better realize
some of the values I see in Smalltalk.  Speaking for myself, my
antagonistic, when it was indeed antagonistic, attitude, was the result of
disagreement between those values and the proposed ideas and nothing else.
Costas, I sure hope you will continue to bring up your ideas even if I
cannot, and will not, promise to always agree with them--<in a tragic
voice>especially if you don't drop this ludicrous operator idea (just
kidding :).

>The passion most smalltalker's feel about their smalltalk is a great
>strength; and so too is their healthy resistance to change. As long as that
>resistance isn't blind or close minded.

Precisely.  I personally haven't noticed close-mindedness in the disagreeing
posts.  The authors were explaining the reason behind their opinions.  Not
all disagreement is because of close-mindedness.  Maybe I have missed some
of the other posts.

>But I have observed, that as a result, the "vocal" community sometimes
>pushes the implicit view that Smalltalk and "ParcPlace/Cincom" Smalltalk
are
>one and the same thing, and when that happens and/or they implicitly sneer
>at any or all the other Smalltalk dialects that exist or treat them as
>inferior; the community and the language suffers.

Speaking for myself, this is not the view I would be pushing implicitly or
explicitly, because this is nowhere close to how I feel.  Maybe I am wearing
rose-coloured glasses, but I thought this was the general feeling in this
community, regardless of the dialect.  I have seen occasional posts that
could be interpreted otherwise, but I thought they were more of slips of
tongue rather than truly deeply rooted attitudes.  (Besides, in those posts
that I remember, VisualWorks was at the receiving end of disdain for ugly
looks, dated tools or proprietary control.  Some of these are deserved, or
mostly deserved, or were deserved until recently, or--about proprietary
control--this is after all real world, folks).

As a side note, as I pointed out before, VisualWorks is not CincomSmalltalk.
Cincom Smalltalk is a marketing label for both Smalltalk dialects owned by
Cincom, VisualWorks and ObjectStudio, and let's not diminish the role of
ObjectStudio by equating VisualWorks and Cincom Smalltalk.

>There are many things inside of current Smalltalk implementations
(including
>Cincom's, IBM, Squeak, QKS, etc.) that are merely happenstance of their day
>and would benefit from being redesigned (that includes both old and new
>capabilities).

Absolutely.

>Unfortunately, some of the criticisms/arguments I've seen about new ideas
>are based primarily on familiarity with this happenstance stuff, or just on
>the notion that it is different from what the "proscribed" way/philosphy
>we've had "forever" is.

As I am never tired of saying, nothing is black and white.  Innovation is
good, but defending old ways in not necessarily bad either.  Not all new
ideas are good, and not all the ways things have been "forever" are bad.
The best we can do is indeed stick to the spirit of good discourse, not take
things personally, and not declare ideas good or bad simply based on what
side--old or new--they are on.

>Smalltalk is more than just its CS language; which means, all the more,
that
>continually exploring new ideas and techniques is important to its health
>and longevity. It is a system, it is about the frameworks, and it is about
>design, and it is about a way of thinking about software.

There is book I found a tremendously interesting reading, with the opening
chapters very much related to the whole topic of these language extension
threads.  It's been a while since I read it but it's been on my mind a lot
throughout this whole and other related discussions.  The connection is very
extensive and not always direct, so I won't go any further than recommending
the book itself.  It is _Patterns of Software_ by Richard Gabriel.  Yes it
is about "those" patterns, but it is about their philosophical rather than
the applied side.  There are no Visitors or Flyweights or code examples in
it (OK maybe there is one or two).  There is a lot about the architectural
patterns, motivation and philosophy behind them (they *are* much more than
just a cookbook of arhitectural templates) and the _experience of applying
them_.  That experience in particular, that I did not see mentioned in any
of the software pattern books, is extremely interesting and brings a lot of
thought related to language extension, innovation, frameworks and
abstractions.  (In short, I enjoyed it a lot, though of course YMMV).

>But, sometimes, the thoughts and arguments (like some of the ideas they are
>about :) are not well founded, deeply considered, or exhibit a backward
>thinking or close-minded attitude (a bit of the stick-in-the-mud view).

And sometimes the thoughts and arguments perceived in a message are not at
all what the author had, and the sneering, or disdain or close-mindedness
are there just because one sees them.  Like those Rorchach tests.  One of
the best things one can do is imagine that the other poster is a talented,
open-minded and frendly Smalltalker who tries to help you appreciate the
things that she sees and you don't.  It may not be true, but it helps :)

Cheers,

--Vassili

--
Vassili Bykov
[hidden email]

Bijan Parsia wrote in message ...
>(Note I forget which version of Squeak this was released for. I'm pretty
>sure they plan to role it into the main release, as well as a Smalltalk-76
>simulator.)

ST-72 is pretty much version-independent.  It's nothing but a few classes to
implement the interpreter core plus a small system source file to load.  It
works in 2.7 and 2.8, that's for sure.  Dan said he had a ST-76 image when I
asked him at SqueakEnd'00, and might do something to bring it to life.  I
wouldn't hold my breath though, ST-76 is much closer to the current
Smalltalk so should be more of a curio than something to experiment with.

--Vassili

"David Simmons" <[hidden email]> wrote:


>I'll bite, what the heck is a fluffer? And what did Bijan mean when he used
>the phrase "anti-fluff"?
>

If you ever watched Seinfeld you may recognize it as Seinfeldian.
Somehow this thread is becoming that.

Regards,

Costas

Bijan Parsia <[hidden email]> wrote (abridged):
> > I strongly feel that any asymmetric operation should have
> > an asymmetric operator (if it has an operator at all).
> > [... side effects ...]
>
> Well, #<< the bitshift has no side effects. Nor does #->
> the Association constructor.

Both are asymmetric, though. The bit about side-effects is just a very
strong kind of asymmetry.


> I'm curious as to what you thought about my symatry claim about most
> Smalltalk binary messages (i.e., that while you don't necessarily
> get the same result, swapping the argument and receiver usually
*makes
> sense*)? I don't know how valuable this property *really* is, but it
> seems reasonable.

I don't know of any counter-examples. Until you pointed it out, I
hadn't noticed it, so it is not important to me and I don't see any
benefit in it. The other languages I know don't have that constraint.
(Notably #<< in C++ and #@ in Eiffel.) In maths, A * B may be valid
but B * A not, eg if A and B are matrixes.

I would be more sympathetic to an argument that operators should not
have side-effects :-)


> I'm still wondering if it's *really* more readable, and what other
> operators would work to fill in the rest of operations. I mean, is
> it really worth replacing #print: with #<< and that's it?

Well, I am not suggesting we replace #print:. I am suggesting we
create a generalised #nextPut: or #add:, which is far more common.
That cropped up as a result of the two recent discussions.

Operators are not reserved to mathematical and logical operations. We
already have #@, #-> and #,. I believe some people add #? meaning
#ifNil: and app-specific uses sometimes crop up. I feel that operators
are pretty deep down in the box of tricks, but they are there to be
used if we need them.

The way in which #nextPut: is used seems ideally suited to an
operator. This is partly a matter of precedence. Currently I find I
frequently have to use brackets or semi-colons to force the intended
parse manually. You seem to disparage this argument as being about
"saving keystrokes". To me having to override default precedence of
#nextPut: frequently is a code smell telling us that the default
precedence is wrong. Language/library design at this level does
matter.

I've not really put my mind to carving up the rest of the library, but
not much else strikes me as being wrong. This is hardly surprising
given that people have been fiddling with Smalltalk for decades.

As I mentioned earlier, Eiffel uses #@ as a synonym for #at: and I
think that would have been a good idea for Smalltalk. They are even
pronounced the same; #@ is quite intention-revealing. The dictionary
lookup concept is fundamental and widely-used, and I often need
brackets with #at: expressions. However this is pretty much a
non-starter because of the prior use with Point.

So, yes, one new operator is all that's on the table.


> Aren't we now just looking for an operator for operators sake?
> Given the untowardness of many of the possibilities, I'm not
> sanguine of the chances for getting a decent family of operators
going.

I'm not sure what you mean. Given the decision to use an operator,
some concrete operator has to be chosen. That's all I was discussing
(while trying to draw out some general principles). If there is no
good candidate we should probably junk the idea, but I think #<+ is
good enough. We're only talking about one operator, not #++ *and* #<<
*and* #<+.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      [hidden email]      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

<[hidden email]> (David Simmons) wrote (abridged):
> > I think the current compromise is a good one, and I should like
> > to see it more fully exploited.
>
> I may be confused here :-). Which "compromise" are you referring to?

I mean the current Smalltalk syntax, with its 3 levels of precedence,
as a compromise between the more austere syntax of (eg) Scheme, the
flexibility of early Smalltalk, the inflexibility of C++, and
complexity of many other languages.

By "other languages" I mean things like Cecil and (I believe) Haskell,
which allow you to define new operators with user-defined:

(a) precedence
(b) infix/prefix
(c) binding (left to right or right to left)

which strikes me as being too much. In a way, less readable than
allowing a totally different syntax inside some `'-type escape
mechanism, because then at least we know we are "not in Kansas any
more" when we read it.


> I've never read that paper; I'll have to find it (unless
> you perchance mail it to me :).

I got it from:
 
http://dev.acm.org/pubs/articles/proceedings/plan/154766/p69-kay/p69-k
ay.pdf

I assume it is generally available; the copyright notice says that
non-commercial copying is OK if the ACM are acknowledged. I'll suggest
it is added to the http://users.ipa.net/~dwighth/ site in case it
disappears from ACM.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      [hidden email]      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

On Tue, 9 Jan 2001, David Simmons wrote:

> <[hidden email]> wrote in message
> news:[hidden email]...
> > On Mon, 08 Jan 2001 14:58:51 GMT, "Boris Popov" <[hidden email]>
> > wrote:
[snip]
Notice the use of "can".

> Let's say we all appreciate your efforts
> and
> > >I am pretty sure that someone will now extend the streams (an strings)
> > >protocols with ">>"s , "++"s etc. But let's try not to make it standart.

If we can come up with a good, clean, coherent protocal, I don't see a big
problem in aiming to standardizing it. Experience in the field would be
nice first, of course.

[snip]
> > >useful ( I am not talking about string concatenation protocol only ) we
> > >can't make them the part of a standart right away.

Notice again the clear temperance of the remarks.

[snip]
> > If I read into this is what you are saying is, that we should not
> > tamper with the language as it exists any further.

That is a wildly, wildly uncharitible reading. It is not even implicit in
the text.

> There is nothing
> > else we should add or, this language needs. And if we need something
> > and maybe useful to everyone don't bother just keep it to yourself.

Hardly, "Share it on the wiki" doesn't *remotely* suggest "keep it for
youself."

If there is *any* hostility to new ideas or the needs of others, I think
it is coming from the other direction.

> Costas,
>
> <opinion>
> I've monitored this thread pretty much from the beginning. I don't
> understand the semi-antagonistic attitude some posters have had to your
> ideas (well actually I do, I just wish I didn't). You openly asked for
> advice and ideas, you proposed and explored many ideas in the spirit of good
> discourse.

Well, let me explain my current fully antagonistic attitude, which *is
not* what I started out with. (Side note: I wish that when folks make
these sorts of accusations, they would be a tad more specific about the
actual words that exhibit the negative property.)

I object to so-called arguments that go, "All Smalltalk (or Squeak
or...) needs is feature/structure/construct foo and it will be wildly
popular and you'll all be rich and happy." or "The reason Smalltalk is
dying is that it lacks feature foo." or "Smalltalk should be a living,
evolving thing, and it isn't if you fail to capitulate to my *ad hoc*,
poorly thought out suggestion."

Aside from the fact that there is *no* evidence presented for these claims
(they function merely as debate killing appeals to authority), they
presume values that aren't universally shared. I, for one, have no great
desire for "world domination". I do like that Smalltalk and its community
to be a thriving, healthy system, but it can do that while embracing, for
example, a non-C/Visual Basicish syntax. I've pointed to Ruby as one very
cool language for people who really don't want to learn or don't like
Smalltalkish syntax and would prefer something more Perl/Algolish, but are
very interested in Smalltalky semantics.

Now, suppose for a moment Ruby takes over the world. Cincom releases
RubyWorks and IBM VisualAgeRuby. (I don't think this is going to happen,
btw, but let's pretend.) Has Smalltalk necessarily "lost"? Is this a
tragedy for Smalltalk?

I don't *think* so, though it *may* be disruptive for many people and
institutions. I could adapt to Ruby *right now*, but I prefer not to. If I
have to use a "mainstream" language instead of Smalltalk, Prolog, Erlang,
or a Lisp, I'd prefer Ruby even to Python. Will I be sad if longtime
interesting Smalltalker's go and "join the Ruby camp"? Sure, if that means
we don't talk about interesting stuff anymore. But I'm happy if there's
interesting backflow from that community.

The case is clearly different if you have a certain kind of business (the
most obvious being a Smalltalk vender :)). But it's not uniformly bleak,
either.

So, resisting the flow of new ideas, even those "not invented here", and
resisting not-so-great ideas backed up by sleazy arguments are not the
same thing.

I get especially torqued off when people say, "You have to have
*maaaarketing*!" Or "Yes, this is *evil marketing*, but it's a *necessary*
evil." It's espeically frustrating when this is intoned in support of what
I think is *bad* (i.e., *ineffective*) marketing.

Why do people think that marketing is any easier than language design?
Plenty of ad campaigns fail in all sorts of non-obvious ways. I wouldn't
put forth a *serious* *dogmatic marketing argument without at least *some*
research into the particular situtation *and* a "sell-by" date.

Add unsupported, dogmatic claims with unsupported, *false* claims ("most
languages have autocoercing string concatinations") ("most people in this
thread agree with me"), etc. etc. and I don't see that the *ideas* are at
issue.

None of this entails that people who put forth such lines are bad, stupid,
mean or whatever people. But I don't see that a hostile attitude to such
argument styles is necessarily a serious vice. It's not necessarily a
virtue either, but expressing irritation does have *some* communicative
value.


> In that same spirit some people disagreed with some ideas (some other people
> chose to make comments that were not exactly in that spirit, and I for one
> wish they wouldn't expose their attitudes so plainly).

What do you make of Costas' reading of Boris's comment? I found it unfair,
hostile, and somewhat denigrating of Boris (though not *directly*).
 
> It's a great thing to have open hearty debate and discussion and voice one's
> opinion on the topic, its a whole other thing to criticize/denigrate the
> individuals participating in such discourse.

Yes, but let's be fair and open about it. Costas was fairly quick to
attribute attitudes and (lame) ideas to his opponents. I don't see that
the reverse was generally true. I'm *happy* to supply further specific
examples.

[snip]
> For a long time people have been asking what's the deal with Smalltalk, what
> can we do to make it more successful, why hasn't it become successful.

I think Smalltalk has been successful in a number of different ways. It's
continued influence on the industry is amazing. It seems to be supporting
a strong and healthy market.

> As to community and individual attitude about the Smalltalk language, it is,
> in my experience, a very sensitive thing among born-again or longtime users
> of Xerox/ParcPlace and/or its direct smalltalk derivatives.

Maybe. But having a different, grounded view of the success and criteria
of success doesn't make you an hyper-sensitive born-again or longtime
user.

(I'm neither, btw.)

And, as someone with such a view, it's not necessarily *surprising* when
people present claims that do not even take the possibility of your view
in to account *even when* presented with them. Where *is* the
objectionable arrogance in such exchanges?

Note that many people who disagreed with Costas' selector nevertheless
provided aid and advice on its implementation as well as pragmatic
arguments about its use. OTOH, he solicited, IIRC, "gut reactions" and
"judgments of taste" as to the use of his #++ proposal. Several of the "I
don't want Smalltalk to become ASCII soup" were really (or charitably read
as) "I don't find that to my taste". Costas himself, as I pointed out,
found the && (auto-coercing concatination with padding) operator not to
*his* taste (aka "fluff"), but provided no marketing, readability,
typability, etc. arguments *against* it.

So, if you ask "Do you like it?" and people say, "No, it's ugly?" what's
to object to?

[Hmm: I'm not sure if the above section is actually apropos to this
thread. I may be confusing it with another, but I'm too lazy to go back
and check at the moment :)]

 [snip]
> strength; and so too is their healthy resistance to change. As long as that
> resistance isn't blind or close minded.

Of course, but is this a problem *in this thread*?

[snip]
> But I have observed, that as a result, the "vocal" community sometimes
> pushes the implicit view that Smalltalk and "ParcPlace/Cincom" Smalltalk are
> one and the same thing, and when that happens and/or they implicitly sneer
> at any or all the other Smalltalk dialects that exist or treat them as
> inferior; the community and the language suffers.

I haven't seen that. Particularly in this thread. Pointers?

> I fully understand and respect when the Cincom Smalltalk employees want to
> do everything possible to push Cincom Smalltalk as the leading Smalltalk in
> every aspect. It's natural that they or any other Smalltalk dialect's
> employees (or developer/designers for open-source versions) want to take
> pride in their product and or see it have a successful, perhaps
> leading/dominant, position.

I certainly don't feel that way. I tend to point to Squeak things because
that's what I'm familar with. But, for example, I believe I brought
SmallScript into the discussion :)

> OTOH if the Smalltalk community doesn't maintain an open mind about ALL the
> Smalltalk dialect's or treats any of the supported dialects with an attitude
> of disdain (as I've seen done with Dolphin Smalltalk vis-a-vis Cincom)

Really? I mean at any serious level? Everyone seems to like Dolphin. But
it clearly has different design goals (and history) than VisualWorks (for
example). I do find a touch annoying when people say, "Well *Dolphin* uses
native widgets; VisualWorks should to!!" (Not that this happens all *that*
often.)

> then
> the language and its advocates will continue to suffer as Smalltalk has for
> the most recent five years of its long history.

The last year or two seem to be a healthy period. You don't find it so?

> The language itself is not sacrosanct, nor is any given dialect's
> implementation or any given dialect's development team an unspoken
> authoritative body for what is or is not "proper" for Smalltalk.

I didn't see anyone claim that. I certainly mentioned "Smalltalky" values
but the seem compatible with most of most implementations.

[snip]
> That having been said, the community itself is still not particularly
> unified (squeak still stays mostly in its own group).

Well, there's me, Lex, and loads of other folks :) Some people don't like
newsgroups.

> Comp.lang.smalltalk is
> not "comp.lang.smalltalk.cincom", and unfortunately we don't see the squeak
> community exhibiting any motivation or desire to move to a
> "comp.lang.smalltalk.squeak".

If we did, it would serve a different purpose, I think.

> I've seen that the Dolphin community felt the need for a separate group

Well, they started out as a private newsgroup on a private newsserver. I
don't know the history, but it could easily be because they wanted to be
able to focus on Dolphin (in a tech supporty kind of way) and it's not
trivial to get a new news group accepted.

IBM has a private VAST newsgroup, too.

> and
> I believe they are quite sensitive to some of the dialect bigotry that
> sometimes rears its head. Smalltalk/MT (which has some really great and
> unique features) often gets short-shrift here in this "dialect neutral"
> comp.lang.smalltalk group. As does Bistro, or Smalltalk/X, etc.

"Short-shrift" as in "not discussed" or "short-shrift" as in "denigrated
and dismissed". If the former, I think it's generall the job of users of
the dialects to rectify. If the latter, that's different, but I have'nt
seen all that much of it.

Squeak gets mocked of course, but we enjoy it :)

> Often enough, the "vocal" community members have limited awareness, or
> experience with these one or another dialects so they promote their primary
> dialect as if it were the only Smalltalk (and I'm sure I'm as guilty as
> anyone in this area). That response is natural, but it is unfortunate for
> Smalltalk as a whole, and in particular for the community of lurkers on
> comp.lang.smalltalk.

Ah. So it is mere unfamiliarity that's the primary problem?

> As the community and its "vocal" members go forward I believe it is
> important that they make every effort to allow and even encourage various
> ideas, disenting opinions.

This is why I hate unspecific euphamisms such as "vocal members": I can't
tell if it's meant to apply to me. How on earth am I do regulate my
behavior in response to criticism if it's totally unclear whether the
criticism applies? *If* I were to do the things you complain of, I'd
certainly think I should change what I do. But I'm both vocal (ahem...to
put it mildly) and unable to find myself in your descriptions. Nor do I
find the objects of your complaints in the other vocal members of this
thread (which, presumably, is what prompted this post), including yourself
;)

> And that they work to see beyond the
> patterns/habits they've acquired/developed in their own particular Smalltalk
> of choice.

And vice versa ("But Python does it *this* way and Python's more
popular.")

> There are many things inside of current Smalltalk implementations (including
> Cincom's, IBM, Squeak, QKS, etc.) that are merely happenstance of their day
> and would benefit from being redesigned (that includes both old and new
> capabilities).

Definitely. Does *anyone* dispute that?

> Unfortunately, some of the criticisms/arguments I've seen about new ideas
> are based primarily on familiarity with this happenstance stuff, or just on
> the notion that it is different from what the "proscribed" way/philosphy
> we've had "forever" is.

Well, I've certainly argued that gratuitious change to something
unfamiliar and arguably undesirable is not a good idea, particularly for
something like printing/string building. I've argued that Costas using #++
himself is not really a great idea if he intends to share code. But if he
derives *such* huge benefits from it that it eliminates the downsides as
far as he's concerned then my blessings, for what they're worth. That I
believe it *completely* unlikely that that's the situation is a different
story ;)
[snip]
> There are many new ideas that have been explored or provided in various
> dialects which might be of value to the community. Overall, in all my years
> in this community, it has been very open and good about this kind of thing
> and their resistance to change has primarily exhibited a healthy
> conservative approach.

Agreed. Note that I'm hoping to set up a structure for introducing
langauge extensions and libraries in a semi-formal way (short of
standards, more than mere posts) inspired by the Scheme Request For
Implementation (SRFI) model (see http://srfi.schemers.org/).

> But, sometimes, the thoughts and arguments (like some of the ideas they are
> about :) are not well founded, deeply considered, or exhibit a backward
> thinking or close-minded attitude (a bit of the stick-in-the-mud view).


Oh the humanity! ;)

> This thread has, unfortunately, exposed some of these kind of factors in
> individual and perhaps "vocal" community sentiment that have likely played a
> negative role in Smalltalk's successful growth vis-a-vis other languages.

Yes, this is not what I've seen. Pointers welcome.

> So, my personal message to you Costas is not to take this too personally.

Why he should take it personally *at all* is a mystery to me. If I make a
stupid claim or dumb argument I try not to blame the people who point out
my errors.

> I,
> for one, am encouraging you to keep exploring

Of course.

> and I thank you for bringing
> the line of discussion

Well, technically, he only raised the issue of #++. That sparked a number
of different replies, some of which turn the discussion toward more
general design issues.

> and your rich exploration of it to this forum.

Uhm. Now I have to be mean. I don't see that *Costas* had a rich
exploration, though there were many rich explorations in this thread.

Note, I don't think that this is a *personal* or *moral* failing...or an
assessemnt of Costas' general capabilities. But I strongly disagree with
the argumentative techniques he used and have, in *any forum*,
consistently strongly opposed them, and thus oppose the praise and
encouragement of them.

This should be *distinct* from discouraging Costas (or *anyone*) from
participating in the forum. Just as "I don't like #++ and don't think
it's a good idea" should be distinct from "Only a moron like you would
proposed something like #++...go back to your filthly, lame Visual Basic
world and leave us alone." which should be distinct from, "I don't care
for #++ and think you'll raise more problems than you'll solve, but here's
some ways to do it."

Cheers,
Bijan "The Sanctimonious Smalltalker" Parsia.

On Sun, 7 Jan 2001 22:52:11 -0500, Bijan Parsia
<[hidden email]> wrote:
Well, at least ObjectStudio got me hooked on Smalltalk. Even though
some might say that this is no wonder since I came from C++. ;-)

>> Is ObjectStudio not being used
>> anymore?
According to the traffic on comp.lang.smalltalk.objectstudio in recent
weeks one might think so. But I'm sure there must be others out
there...

>Actually, I would bet that use is growing somewhat now that Cincom is
>bundling it with VisualWorks and shifting gears to becoming
>a more general Smalltalk vendor. ObjectStudio was much more a vertical
>market app.
I'm not sure if its use is actually growing since the same unfriendly
licence policy of VisualWorks also applies to ObjectStudio (VW and OS
are bundled as Cincom Smalltalk). At least my company is currently
considering other Smalltalk alternatives due to that.

>From what I've heard, ObjectStudio is quite interesting but often -- for
>historical reasons -- rather non-standard. (I dearly hope that
>#+ isn't *instead of* #, but I'm not sure.) There is slow movement toward
>making it ANSI conformant, I believe.
Yes it's true, there are non-standard issues in ObjectStudio due to
its history. But given the fact that VW and VAST have been the market
leaders I'm not surprised if they are closer to the ANSI standard.

Regarding #+ instead of #,:
#, is available but most String concatenations in the base classes are
done with #+ and #++ and so does our code. But I have noticed that
more recent developments of Cincom now use #,.

And there is at least one non-standard feature in ObjectStudio which I
have not seen in any other Smalltalk but which I would prefer if it
was the standard. In ObjectStudio you normally define Array literals
using {} instead of #(). E.g.

ObjectStudio: {1 2 #SomeSymbol 'abc'}
Standard: #(1 2 SomeSymbol 'abc')

The obvious advantage is that within {} you can write Symbol literals
as you would in any other context, i.e. prefixed with #. What I like
in Smalltalk is that some simple yet powerful concepts are the
foundation of the language and are consistently applied throughout the
whole system (including if-then-else logic which follows the usual
receiver - message logic). But I feel that this consistency is broken
in the case of standard Array literals containing Symbols. Hardly the
end of the world but still...

Regards,
Paul Wallimann

[hidden email] wrote in message
<[hidden email]>...
You can prefix symbol literals with a # within #() in any Smalltalk, it's
just that you don't have to (unless they are symbol literals of the form
#'symbol with spaces').

{} is found in several Smalltalk implementations as an array constructor,
though with a meaning quite different from that of #(). It has a form of a
no-argument block, i.e. expects a sequence of expressions inside the braces.
They are evaluated and their results are used to populate the array. In
other words, {3 factorial. 3 + 4} is about the same as "(Array with: 3
factorial with: 3 + 4)".

--Vassili

<[hidden email]> wrote in message
news:[hidden email]...
>
> The obvious advantage is that within {} you can write Symbol literals
> as you would in any other context, i.e. prefixed with #.

Writing Symbol literals prefixed with # within arrays is hardly unique to
ObjectStudio. Most (all?) modern Smalltalk implementations allow this.

-Eric

David Simmons wrote:

<snip>

<snip>

Your efforts at improving Smalltalk "(and especially vendor collaborative
extension) of Smalltalk's capabilities" is anything but arrogant. I'd
say it is enlightened. Smalltalk could be advanced farther and faster
if the vendors would divide up the pie of extensions and each develop
a piece, in as dialect portable a manner as possible. Since you have
more of a vision for collaborating than is apparent among the other
vendors, perhaps you could arrange an exploratory session with them to
discuss the possibilites. A byproduct might be achieving more portability
between dialects.

Collaboration beyond ANSI Smalltalk would strengthen the group of small
Smalltalk vendors. Even big companies such as the major auto companies
collaborate, such as in developing B2B exchanges and industry standards.
Surely it must be easier for small companies to get together.

Bruce Samuelson wrote:
100% on the mark.

David should if anything be even _more_ "arrogant" and "aggressive."
The fact is, he is in the very nice position of being able to not only
consider the technological outlook but to also *act on his opinions*
without having to battle through multiple layers of management hierarchy
(which is very much like having to wade through a tar pit...).

Some of us have to walk a mile in order to advance 10 feet.....

pete

No to belabor the point but I think you have taken things a little too
personally.  I never insulted anyone intentionally. Maybe we have
cultural differences where something I said is insulting to you. I am
sorry if that was the case.

Regards,

Costas

On Wed, 10 Jan 2001, Costas Menico wrote:

> No to belabor the point but I think you have taken things a little too
> personally.

To belabor the point, I really am *not* taking it personally. I don't
think you've attacked me or anyone else personally. I don't even think
you've *insulted* anyone. I do think you've misread some of what people
wrote in a rather frustrating way that tends to get my hackles up, but
that's hardly a mortal sin :)

>  I never insulted anyone intentionally. Maybe we have
> cultural differences where something I said is insulting to you. I am
> sorry if that was the case.

No need to be sorry! If cultural differences explain why you read what
people said the way you did then that would help explain why *you* may
have felt testy.

The reason I point to exactly where I think a misreading occured isn't to
rub anyone's *face* in it, but to provide useful feedback.

And please don't take my contrary-to-David-Simmons' assessment of your
material contribution to the thread as expressing a desire for you to shut
up and go away. It wasn't.

Cheers,
Bijan Parsia.

On Tue, 9 Jan 2001 12:20:04 -0800, "Vassili Bykov"
<[hidden email]> wrote:

Yes, you're right. I have just checked with VW and Dolphin and it
works as expected. But again, ObjectStudio seems to deviate from the
standard as it does not allow # inside #().

But now you make me curious:
1) Is there an official way of defining Symbols in Array literals or
are both ways approved by the ANSI standard?

2) Do you know why #() was chosen for Array literals in the first
place? I mean # is normally used for denoting Symbols. Is there (maybe
historically) a connection between Symbols and Arrays apart from the
fact that both are Collections which would explain the use of # in
both cases? At least VW, Dolphin and OStudio do not evaluate to true
when I execute #(1 2 3) == #(1 2 3) in a Workspace whereas #Foo ==
#Foo does of course.

Paul

<[hidden email]> wrote in message
news:[hidden email]...
QKS Smalltalk supports # inside nested literals.
    #(#(#(#())))
    "or"
    #(#abc #def nil #123 #'aSymbol' #'aSymbol%#''$@49' 'string' #())

When printed, array const literals are printed with all the # symbols
explicitly presented. There have been variants in QKS Smalltalk formatters
that only printed them where needed to disambiguate forms, but that approach
is no longer used. The same printer system also handles recursive references
to elements within any form of Array/List.

    |x| := {}.
    x add: x.    "{{* Recursive List -25855 *}}"

Really. Hmmm.

My understanding is (was) that # denotes a const canonical literal. Shows
what I know? QKS Smalltalk was not derived from the Xerox ST-80 seeds so I
didn't know better ;)

    QKS Smalltalk always guaranteed (and the frameworks are
    designed assuming that), by definition, "#expr == #expr"
    should ALWAYS return true.

This rule/idea is the same for static literal consts of the form ##.
    ##someConstPoolOrNamespaceVariableOrOtherValue

QKS Smalltalk always generates #(...) as canonical literals.

    #aSymbol
    #<=> "or any other combination of unicode binary selector chars"
    #<><><><><<>> "a really long binary selector symbol"
    #'...arbitrary content const canonical literal symbol...'
    #(...anArrayConst canonical literal...)
    #{...aGUID/UUID const canonical literal...)

        o  The #{...} was extended in SmallScript to support the
           Cincom/VW path expression behavior (as per CampSmalltalk#1
           discussion w/Eliot Miranda). One of my technical issues
           with the path-literal form was the #== / const issues.
           The AOS Platform/SmallScript/QKS Smalltalk namespace
           system's lazy/demand loading module loading capabilities
           don't require (or use) this kind of path-literal.

    '...aString or StyledString const canonical literal...'

Note: The "const" behavior is runtime enforced for all the instances. I.e.,
attempting to write to the various indexed or structured storage (incl.
character) data areas generates an exception. The named slots are currently
writeable, but that may or may not be disabled. Similarly, attempting to
reshape (change behavior, etc) any object with the "const" property turned
on will generate an exception.

All these forms are managed by the AOS Platform/VM's literal table and, like
symbols, string-const-literals, guid-const-literals, etc. the gc (internal
finalizer system) informs the literals manager when they're no longer
referenced (unless their properties indicate they're a persistent gc-root in
which case they're never gc'ed).

The literals manager then removes them from the canonical literals
collection. If that collection has shrunk to have more than xx% it is then
resized to take less space and the elements are rehashed.

----
A more liberal interpretation than I used when I originally designed QKS
Smalltalk ~91, would be that the $# within source indicates that the value
is "statically" derived at compile time but is not necessarily constant or
canonical/unique. Based on what you've described, I would surmise that this
is the approach taken by the smalltalk dialects you've cited.

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

>
> Paul