[squeak-dev] The Inbox: Traits-pre.307.mcz

Colin Putney colin at wiresong.com
Mon Nov 23 18:50:26 UTC 2015


On Mon, Nov 23, 2015 at 6:30 AM, Frank Shearar <frank.shearar at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20151123/d48fc074/attachment.htm


More information about the Squeak-dev mailing list