Environments -- how to proceed (Re: [squeak-dev] The Inbox: Traits-pre.307.mcz)

> On Mon, Nov 23, 2015 at 6:30 AM, Frank Shearar <[hidden email]>
> wrote:
>
> There's definitely a pattern there: someone has a great idea for a
>> fairly advanced capability, heroically tries to do all the work solo,
>> or with minimal help from the community, burns out and the work never
>> gets finished.
>
>
>>
> Traits, or things close enough to traits that you end up splitting
>> hairs to tell them apart, are a core feature of so many languages
>> nowadays (Ruby, Newspeak, Scala, Perl 6, Rust, off the top of my
>> head), while we let the idea die on the vine, for want of tooling
>> support. And I'm sure Environments will, too.
>>
>> Sure, if it's not providing value, and no one's willing to do the
>> work, just kill the thing and be done. I'd rather see people pitch in
>> and help _make_ the dang thing a proper part of the system. ("Thing"
>> here applies mostly to Environments, but Islands and Traits too.) But
>> I'm also not going to run around pointing fingers: I'm too burned out
>> to do anything to help, so I'll just shut up now.
>>
>
> Yup, that about sums it up.
>
> Over the last year or so, I've attempted to resume work on Environments
> several times only to get discouraged and give up. The "easy" part is done,
> and what remains is tracing through gnarly legacy code and figuring out
> where the SystemDictionary assumptions are. It's hard.
>
> The reason I started working on OmniBrowser 10 years ago was because
> Nathanael Schärli commented that the hardest part of getting the Traits
> prototype working was adding tool support. The idea was to make a modular
> tool set that could easily be modified and *make language improvements
> easier*. That failed. OB ended up being a great IDE once Lukas did the
> refactoring support, but nobody uses it. I spent years trying to hunt down
> the underlying reasons for that and remove the obstacles, but in the end,
> "not exactly like the tools I already know" and "requires installation"
> proved insurmountable.
>
> This is why I wanted to develop Environments in the trunk and not have it
> be an optional thing. That worked fairly well, but then I ran into the
> exact same problem that Nathanael did with Traits.
>
> I really want Environments to succeed. I do. I wrote the cleanest code I
> could, with tests and comments. I engaged with the community from the
> beginning and throughout the process trying to build support for the idea
> and knowledge about the implementation. Eventually, I had to take a break
> and deal with meatspace things like moving and a new job, but I was
> determined to get back into it as soon as I could.
>
> After time away from it, though, thinking about Environments fills me with
> despair. Nobody cares. Nobody wants to make Squeak better. The only thing
> the Squeak community values is compatibility with Alan's demos, and a
> version of Etoys that nobody uses. Ok, that's over the top. But to a first
> approximation it's true. It's why we lost the Pharo folks.
>
> So here's my proposal: let's decide as a community whether we want
> Environments or not. I pledge to help implement the decision either way. If
> people want to go back to the classical ST-80 global namespace, I'll help
> with that. Or we can figure out what would be required for Environments to
> actually be worth keeping and I'll help work on that too.
>
> Thoughts?
>
> Colin