Re: types of people

[Mario.Wolczko@Eng.Sun.COM (Mario Wolczko)]

Date: Tue, 29 Aug 1995 15:13:17 +0200
From: rainer@physik3.gwdg.de (Rainer Blome)
To: jecel@lsi.usp.br
Cc: self-interest@self.sunlabs.com
In-Reply-To: <9508282154.AA02536@obj.Eng.Sun.COM> (Mario.Wolczko@eng.sun.com)
Subject: Re: types of people


jecel wrote:

> [...] how different kinds of people make (and use) different kinds of
> systems [...] there are very few women in OS and language design [...]
> the "types of people" are independent of sex [...]

the available "types of people" (aka communities) are indeed independent of
sex (imo), but the distribution of people over the types isn't.  still, one
shouldn't in general cater for a specific distribution but instead make sth
useful for a wide range of types.

a way to achieve that is to unify concepts used in different communities,
then maybe sell them all the same stuff with just different labels.  in
other words, i think it's possible to make a language feel `just right' for a
far wider range of users than the current languages do.

for example, self has some of scheme in it but could use a lot more still:

  - unified blocks and methods (procedures aka closures)
  - more convenient representation of code as data
  - a macro facility
  
  - closures that may be used out of their lexical context
  - continuations
  
  - transformation of tail recursion into iteration
  - lazy allocation (scheme does not have this by default, but should)

the first three issues are actually visible at the language level.  they
simplify library design and will probably make the system lighter or more
effective.  the last two are implementation issues, invisible at the
language level.  they complicate (do they?) interpreter/compiler
construction but will make the system more efficient.

out-of-context closures and continuations are implementation issues that
are visible at the programming level.  using heap allocation is a simple
way to implement closures but that's slow.  having lazy alloc would help a lot
there (first, alloc on the stack, evacuate to the heap when necessary), but
isn't trivial to implement fast.  still, because it pays off in so many
ways (including providing elegant and fast ways to implement the other
three implementation issues), it seems the way to go.


rainer