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