On 30 September 2016 at 14:36, Chris Muller <asqueaker at gmail.com> wrote:

> >> I don't like the idea of CurrentEnvironment at all. IMO global state
> >> stinks.
> >> It would mean that a lotta behavior would change by simply switching one
> >> shared variable...
> >> I see it more like a not so clever workaround to make tools still work
> in
> >> presence of environments with minimal changes.
> >
> >
> > Global state does indeed stink, which is why Environments is so nice,
> > because "global" isn't global anymore.
>
> This deserves some qualification.  Its true that writable globals
> stink, you never know what state its going to be in, and updating it
> introduces contention, etc.  However, Class names don't suddenly point
> to a different class object within the context of a running
> application, and no one ever replaces Smalltalk with a new instance.
> These globals are just "there" -- read-only bindings which don't
> suffer the stinky issues associated with writable globals.
>
> I'm glad Nicolas started the other thread asking "what's it for?"  To
> me, that's the most important question -- is there something actually
> truly useful gained in exchange for complicating the language and
> tools?  Is it only about everyone being able to have elegant,
> prefix-less class names all loaded into one image?  Most of the
> use-cases mentioned in this and the other threads were just "cool ways
> to handle a one-off problem."
>
> For the real world, we have been wanting smaller, more modular images.
> The conditions of having less code and responsibility in those smaller
> images bodes them less likely to benefit from Environments.  Multiple
> small images passing messages over the network lets those Smalltalk
> applications run on multiple processor cores, compared to one
> monolithic image with all the code loaded and disambiguated via a
> hierarchy of Environment imports/exports and running on just one
> process core.
>
> In 15 years, I think I've had just one name collision between classes
> of different packages (neither of which used prefixes).  I think I
> simply renamed one of them.  Dynamic system.  With Environments, I
> would still have had to write some code to do various
> imports/exports/renames, etc.. and so it doesn't actually save me any
> development effort.  I guess it boils down to letting me keep pretty,
> but ambiguous, names in the code.  But, I actually prefer prefixes...
>
> Not trying to be a party pooper, but complexity is commonplace,
> simplicity is rare.  If we still have a simple system, we should value
> that aspect and try to keep it that way.  At least _optionally_...
>
> Best,
>   Chris
>

Well, there's simple, and there's simplistic, and these are not the same
thing. Environments abstracts, and makes uniform, the binding of names to
variables (which includes classes and globals). Instead of the single, and
therefore specialised, and therefore apt to make klunky, mapping of names
to things, the implementing of Environments focuses attention on a often
neglected part of programming.

But I've had these discussions before, and I don't have the energy to
pursue them, therefore I don't really have a voice in the matter.

I am, however, sick to death of things being invented in Smalltalk, only to
die in its birthplace, while the rest of the world sees value, and
wholeheartedly takes up the concept. I'm not saying you're doing this now,
Chris, but I have often, often heard people in the Squeak community say
"oh, it was Too Complicated, it Wasn't Simple, Not Worth It" while Ruby,
Perl, Clojure, Fortress, Scala all say "yep, great idea, thanks!".

frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20161001/a933d3fe/attachment-0001.htm