Time to think about parallel Smalltalk stuff

Brian T. Rice water at tunes.org
Tue Jan 25 01:07:26 UTC 2005


Mark Miller <markm at caplet.com> said:

> [cross posted]
> 
> Brian Rice wrote:
> > While E has a narrow focus on security, the concurrency model may be 
> > taken without the security/crypto design implications that go with it. 
> 
> I see it as a "primary" focus rather than a narrow one, but perhaps this is 
a
> matter of taste. In any case, I agree that E's concurrency model is of value
> independent of E's security model. And thanks.

Sorry; I really didn't think anyone would notice this, and was sort of 
ranting based on some undiscussed frustrations with trying a deeper 
integration of E and Smalltalk-ish implementations than Squeak-E or E-on-
Squeak or even E-on-CL (I've been conversing with Kevin Reid  on IRC for some 
time now).

> > In my case, I am working with such an option for Slate as a concurrent 
> > language extension, and eventually cryptographic security can be added 
> > as an optional transport layer.
> 
> So, are you interested in building something secure or not? I'm confused.

Yes, but gradually. The implementation has started from the bare working 
prototype, so we don't support a lot of things that are necessary for full-E 
semantics yet, and have been focussing on getting the language and library 
design correct and fully debugged - security issues have been kept in mind, 
but only in regards to library designs and partly on language design. I 
basically collect every email I possibly can that's relevant and 
collate/sort/glean from them.

The approach to take on all of E's semantics partially relies on some 
language features which are currently not implemented, though they were 
present in previous Slate versions (namely, subjective programming), as well 
as things like weak references and network programming support - these are 
all currently missing due to various historical choices and lack of developer 
time (everyone works on this part time, with ZERO funding).

> > I also want to focus on Erlang-style 
> > signalling between processes, which goes a step further than broken 
> > promise resolution in E.
> 
> Sounds like a promising approach. I like Erlang. As you develop this, I'd 
like
> to hear more about it, and I'm sure other e-lang'ers would too. Thanks.

Okay. I'll write something up on that soon, but I have to address remaining 
basic concurrency issues first.

> > Of course, the E fellows aren't directly helpful with this kind of 
> > effort, simply because their whole focus is security and their example 
> > of E. It's difficult to bring up an issue with them and not get just 
> > the security slant, so I've had to work it out myself.
> 
>  From web searching
> 
> http://www.google.com/search?
as_q=Brian+Rice&num=50&hl=en&btnG=Google+Search&as_epq=&as_oq=&as_eq=&lr=&as_f
t=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=eros-
os.org&safe=off
> 
> the only messages I could find that you've posted to e-lang are
> http://www.eros-os.org/pipermail/e-lang/2004-August/010007.html
> and
> http://www.eros-os.org/pipermail/e-lang/2004-July/009938.html
> 
> Could you please point us at the message where you asked about concurrency,
> and we were unhelpful in our responses? I would appreciate it if you'd give
> the e-lang community another chance before writing us off as unhelpful. If 
you
> are indeed interested in concurrency without security, please make that 
clear,
> and perhaps you'll find us more helpful. Thanks.

Well, I'm interested in concurrency /before/ security, since we currently 
have NO concurrency, which that email stated. I'm guilty here of turning 
hyperbole into lying, and I do apologize. :( I'll try to be more 
forthcoming / straightforward in the future. I was mostly annoyed that there 
was zero response from my email, and that E's implementation is so steeped in 
Java backwardsness that I spent months just trying to decipher any lessons it 
had (there's an extended rant based on this with my frustrations with the E 
language as a whole - I'm subscribed to the mailing list, and 80% of the 
content is noise and confusion surrounding this horrible inflexible syntax! 
I'm aghast. After a year toying with E, I still can't read it or program in 
it.). Only recently did I realize how simple a large part of it is to port, 
although there are a couple of extremely sticky points when you want an 
efficient implementation on a VM with one-bit-tagged references rather than 
full References, and also where open implementation is the principle of 
design.

> > Also, from what I understand from following the Croquet and E projects, 
> > it seems that the interest from Croqueteers towards E has not seen a 
> > real follow-through, at least from the E perspective, so don't count on 
> > them to deliver a full solution to the integration issues. It's a tough 
> > task and requires a lot of focus.
> 
> I agree, though I'm still hopeful that the Croquet project might yet decide 
to
> take security seriously before it's too late. But if you're not interested 
in
> security, what problems with Croquet are you referring to?

I am interested in security, so I am referring to that, but also the 
concurrency model requires a fairly deep re-thinking to integrate properly - 
an activity that I don't think they have time for. I've also been monitoring 
the Croquet list and it's been inundated with publicity-fallout, since people 
are posting many different ideas and there's very little response to it. They 
have to focus on the technical aspects and get those out of the way - and 
once that's done, they'll have a large body of working code to maintain - the 
Squeak situation all over again!

I do apologize again for the exaggerations and manner of introduction. It 
really did bother me that I didn't get a response after people had been 
casting about for ideas on how to integrate and even cross-posting 
announcements on collaboration. I am often frustrated: I have this fully open 
system and project organization that allow for lightning-fast integrations of 
ideas when utilized, and it feels like no one cares! We created this project 
*specifically* to integrate hundreds of good ideas, and have this nice long 
period of gestation before it's useful enough that users might flock to use 
it, so it should be taken advantage of! But I have this tendency to try to 
keep things quiet on the PR front since people interpret talk as promises, 
but the number of people interested in contributing to a kernel system is 
really quite small (so we clearly can't keep all of them with such a tiny 
group). Even just one person weighing in and contributing can have a huge 
effect!

I don't know quite what else to say. You or someone in your project should 
check out the website and reference manual and make some kind of commitment 
to the effort. We /will/ make it worth your while if the collaboration is 
beneficial - that is the deal we offer - you'll get back what you put into 
it, and optimistically, more.




More information about the Squeak-dev mailing list