On 11/23/15, Colin Putney colin@wiresong.com wrote:

On Mon, Nov 23, 2015 at 6:30 AM, Frank Shearar frank.shearar@gmail.com 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

Environments as such work in the sense that having added them does not do any harm besides that it broke saving and loading projects. So in this sense a first result has been achieved.

I understand that there is progress as well on the issue of fixing loading and saving projects. I wonder what is still needed to make work fully.

Are there any other shortcomings cause by the introduction of environments?

And then there is surely lack of documentation. I do not know how to use environments. I assume there are examples but they are hidden in emails many months or even years ago and are difficult to trace.

At the moment I think I could live with limited tool support for environments.

--Hannes