Re: Object Ontology... Was: [fonc] Fonc on Mac Snow Leopard?

[Julian Leviston]

We're saying the same thing.

Julian.


On 12/05/2010, at 12:32 AM, BGB wrote:

>  
> consider plain arithmentic: numbers and arithmetic are also sterile of 
> meaning and context.
> yet, they are very much useful in a large number of (often unrelated) 
> contexts.
>  
> sometimes, we don't need the thing represented, maybe just a few numbers on 
> which to calculate.
>  
> 

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: Object Ontology... Was: [fonc] Fonc on Mac Snow Leopard?

[BGB]

  - Original Message - 
  From: Julian Leviston 
  To: Fundamentals of New Computing 
  Sent: Monday, May 10, 2010 10:27 PM
  Subject: Object Ontology... Was: [fonc] Fonc on Mac Snow Leopard?


  Salut,


  Comme illustration, j'ai decidé a repondre en français...


  Si tu n'as pas une contexte pour les mots de cette langue, c'est probablement 
assez difficile a comprendre ce que je dis. 



  ---


  (this will help if you don't have any french: 
http://translate.google.com/#fr|en)


  In order to understand what you're trying to say, it might be that I need to 
understand your context a bit better (LOL!)... 


  You say "it is less important the meaning or intended purpose of a library" 
you then go on to say it's more important to know "what does it do?"
  How can  you separate what something does from its context. If I provide you 
with a car, then take you to an extremely cold place like the arctic... you'll 
find the wheels don't work AS THEIR INTENDED PURPOSE very well. What the car 
does has therefore been obscured or shifted by its context.

granted...

however, the question is still "what does it do", rather than "what was it 
intended to do" (since "intention" is also an aspect of meaning, and for this 
context this can be ignored).

for example, in the artic, the usual actions (turning the key, pressing the 
gas, ...) don't tend to exactly do anything (say, it is really cold and the gas 
and battery don't necessarily work well either).

but, even as such, there are still many things which can be done with a car:
lifting it via a crane;
using it like a large weight;
putting it in a large catapult and/or using it to bust down a wall;
...

likewise would be:
a screwdriver can be a projectile throwing weapon;
a large fan can be used as a bludgeon (or to chop carrots, ...);
...


or, examples from programming:
using SSE vectors as 128-bit integers, 128-bit floats, or as 128-bit pointers;
shoving a pointer into the mantissa bits of a double (and using a NaN to encode 
pointers/references);
...

this doesn't necessarily mean that one needs to make use of bugs in libraries, 
more so that they are not confined by the defined usage, only by its defined 
structure and behavior.


all this is common-place, and what is one day a hack or kludge, later becomes 
the defined use in another context.

examples of this are prevalent, from the x86 architecture, to PE/COFF (or 
PE/COFF + CLR/MSIL), ...




  This particular car's intended use is to allow people to comfortably and 
rapidly move their bodies and other things to other places. This is reasonably 
obvious. Its effectiveness is hampered by an unintended context shift... you 
could say its meaning has been obscured by its context shift. Take the car into 
space and you'll find that the context shift has changed its meaning totally. 
It's no longer useful for its INTENDED PURPOSE.

yes, but it still has plenty of other uses...


my point was to strip things of "meaning", rather to say that anything can be 
done anywhere...

however, a world free of meaning can't be readily expressed in words, given 
words are entangled with meaning.
but, in this sense, the world is not necessarily made of words.

sometimes meaning is a friend, sometimes it is an enemy (much like emotions, 
thinking of the future, ...).




  I'm saying the intended purpose of something needs to be recorded as well as 
the form that it takes as well as the context that the form is appropriate to. 
We presently just record the form (you represent this by the word "data").

yes, but form can also be useful in and of itself.




  If I write something in the data that is french of the current times, and you 
see it 200,000 years later, without a context (and the further you travel from 
the original context, the more you'll need to define the context), we end up in 
a circumstance where you can no longer understand the original meaning of the 
sentence.

  Put another way... a husk is useless without the kernel it holds. It has no 
information of its own, it's simply a holder for something else. It has no 
meaning, only form.

yes, fair enough.

however, the issue may not be that the statement has lost meaning, but rather 
that it is not in a usable form.

the statement however, has not ceased to have form, and assuming the machinery 
for processing french were implemented, then its form would become usable (and 
its meaning could be extracted).


choosing the best form for the data may well be a bigger issue than that of 
what it means.

for example:
person A chooses to represent their data in relational database tables;
person B chooses to represent their data in a large set of tree-based 
structures and maybe weighted nodes.

now, consider a piece of data needs to migrate freely beween person A's system 
and pers

Re: [fonc] Fonc on Mac Snow Leopard?

[Alan Kay]

Me too. That was why I suggested that people on this list try to write these.

Cheers,

Alan





From: Dan Amelang 
To: Fundamentals of New Computing 
Sent: Mon, May 10, 2010 8:23:08 PM
Subject: Re: [fonc] Fonc on Mac Snow Leopard?

On Mon, May 10, 2010 at 10:46 AM, John Zabroski  wrote:
> Alan,
>
> If I took the time to write an "idea memo", would you (and possibly others)
> at VPRI take the time to comment on it?  It would mainly be example-driven
> and use an interweaving storywriting style, since I am not well-versed in
> scientific writing style, but, if necessary, I could cite and compare to
> various academic work.

I'll read it.

Dan

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc



  ___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Object Ontology... Was: [fonc] Fonc on Mac Snow Leopard?

[Julian Leviston]

esign:
> it is less important the meaning or intended purpose of a library;
> typically, what is of much greater concern is the more solid aspects:
> what does it do? what API functions does it export? what sorts of semantics 
> and behavior can be expected?
> ...
>  
>  
> context then is not meaning or purpose, rather context is simply more data 
> which serves to help process the prior version...
>  
>  
> - Original Message -
> From: Julian Leviston
> To: Fundamentals of New Computing
> Sent: Monday, May 10, 2010 9:21 PM
> Subject: Re: [fonc] Fonc on Mac Snow Leopard?
> 
> From: http://www.vpri.org/pdf/tr2009016_steps09.pdf
> 
>> The interesting part of this scheme is not just the long established idea of 
>> loose coupling through some form of brokering, but the extent to which 
>> semantic match-ups can be made between our viewing and event mechanisms and 
>> the enormous space of functionalities available. In other words, it is not 
>> that we can do away with some agreement between the sender and the receiver, 
>> but that we want to minimize what has to be agreed on, and especially the 
>> size and extent of what has to be agreed on.
>> As an analogy as well as example, in MIDI, there are literally millions of 
>> timbres, and this makes it difficult to play a midi piece on a synthesizer 
>> that may not have the exact ones the arranger had in mind (or to display a 
>> document that does not travel with its fonts, etc.). In both cases we can 
>> make partially do with classes of timbres and fonts (this is what “General 
>> MIDI” and “standard fonts” do). We can go much further, making models of our 
>> intentions and sending them with the objects in question. Good models allow 
>> much better brokerage and match-up between “visiting actors” and the stage 
>> they are given to perform on.
>> This is an ongoing research problem that is central to many critical scaling 
>> issues in future programming and we expect to extend what can be done as our 
>> research project proceeds.
>> 
> 
> I find that here the need for a context is implicit. Without context, content 
> has no meaning. If I'm "building a sound" or "making a font", then the 
> intention has to be taken with its context... and preferably across a few 
> contexts so that the intention is more clear... or to have a flexible content 
> definition that illustrates the full intention across all contexts. (in 
> exactly the same way that outlines are scalable across many "bitmap 
> resolution" contexts). Perhaps, for example, the font or sound is intended as 
> a subtle sound or font that mixes easily with its background (transparency is 
> not default in a typesetting context, but "mixing" is a default in audio 
> contexts). Perhaps a sound is a bass drum which is intended to cut through a 
> mix... in which case, its default is to do sidechain compression on the rest 
> of the channels in a mix... this "intention of content" is useful and 
> necessary and more developed in certain of our areas than others (for 
> example, fonts in typesetting have a much better 
> intention-defininition-capacity than sounds in music composition).
> 
> I'm essentially talking about content intent being able to be baked in, so 
> that content becomes objects (including function, not just state) that rather 
> than simply specifying some single dimensional output, specifies some 
> intractability with its environment. For example, a certain typestyle that 
> inverted its colour on low contrast backgrounds.
> 
> Where the intent differs from the original authors intent, overriding by 
> "subclassing" style processes would allow specification through customisation.
> 
> Julian.
> 
> 
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[BGB]

I disagree...


personally, I often find it far more useful, not to add meaning to data, but 
rather to strip meaning and intention from the data.

so, content is stripped of nearly all meaning, becomming essentially raw data 
to be interpreted however is as-needed for a given task.

for example, code as well can become data, being itself stripped of "meaning", 
and becomming essentially entries in a database. the database doesn't concern 
itself with how it is to be used, as the code which uses it can use it any way 
it sees fit.

one can then, for example, write something which operates on this data, and in 
turn produces more data, or maybe executable code, ...


so, the big question is not the "meaning" of the data, or even how or what one 
will do with it, but the form this data will take... (FWIW, "meaning" may well 
itself be a misnomer of sorts, when in reality there is no real meaning to 
things beyond that which are attributed to them after the fact).

to some extent this also applies to API design:
it is less important the meaning or intended purpose of a library;
typically, what is of much greater concern is the more solid aspects:
what does it do? what API functions does it export? what sorts of semantics and 
behavior can be expected?
...


context then is not meaning or purpose, rather context is simply more data 
which serves to help process the prior version...


  - Original Message - 
  From: Julian Leviston 
  To: Fundamentals of New Computing 
  Sent: Monday, May 10, 2010 9:21 PM
  Subject: Re: [fonc] Fonc on Mac Snow Leopard?


  From: http://www.vpri.org/pdf/tr2009016_steps09.pdf


The interesting part of this scheme is not just the long established idea 
of loose coupling through some form of brokering, but the extent to which 
semantic match-ups can be made between our viewing and event mechanisms and the 
enormous space of functionalities available. In other words, it is not that we 
can do away with some agreement between the sender and the receiver, but that 
we want to minimize what has to be agreed on, and especially the size and 
extent of what has to be agreed on.
As an analogy as well as example, in MIDI, there are literally millions of 
timbres, and this makes it difficult to play a midi piece on a synthesizer that 
may not have the exact ones the arranger had in mind (or to display a document 
that does not travel with its fonts, etc.). In both cases we can make partially 
do with classes of timbres and fonts (this is what “General MIDI” and “standard 
fonts” do). We can go much further, making models of our intentions and sending 
them with the objects in question. Good models allow much better brokerage and 
match-up between “visiting actors” and the stage they are given to perform on.
This is an ongoing research problem that is central to many critical 
scaling issues in future programming and we expect to extend what can be done 
as our research project proceeds.




  I find that here the need for a context is implicit. Without context, content 
has no meaning. If I'm "building a sound" or "making a font", then the 
intention has to be taken with its context... and preferably across a few 
contexts so that the intention is more clear... or to have a flexible content 
definition that illustrates the full intention across all contexts. (in exactly 
the same way that outlines are scalable across many "bitmap resolution" 
contexts). Perhaps, for example, the font or sound is intended as a subtle 
sound or font that mixes easily with its background (transparency is not 
default in a typesetting context, but "mixing" is a default in audio contexts). 
Perhaps a sound is a bass drum which is intended to cut through a mix... in 
which case, its default is to do sidechain compression on the rest of the 
channels in a mix... this "intention of content" is useful and necessary and 
more developed in certain of our areas than others (for example, fonts in 
typesetting have a much better intention-defininition-capacity than sounds in 
music composition).


  I'm essentially talking about content intent being able to be baked in, so 
that content becomes objects (including function, not just state) that rather 
than simply specifying some single dimensional output, specifies some 
intractability with its environment. For example, a certain typestyle that 
inverted its colour on low contrast backgrounds.


  Where the intent differs from the original authors intent, overriding by 
"subclassing" style processes would allow specification through customisation.


  Julian.


--


  ___
  fonc mailing list
  fonc@vpri.org
  http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Julian Leviston]

From: http://www.vpri.org/pdf/tr2009016_steps09.pdf

> The interesting part of this scheme is not just the long established idea of 
> loose coupling through some form of brokering, but the extent to which 
> semantic match-ups can be made between our viewing and event mechanisms and 
> the enormous space of functionalities available. In other words, it is not 
> that we can do away with some agreement between the sender and the receiver, 
> but that we want to minimize what has to be agreed on, and especially the 
> size and extent of what has to be agreed on.
> As an analogy as well as example, in MIDI, there are literally millions of 
> timbres, and this makes it difficult to play a midi piece on a synthesizer 
> that may not have the exact ones the arranger had in mind (or to display a 
> document that does not travel with its fonts, etc.). In both cases we can 
> make partially do with classes of timbres and fonts (this is what “General 
> MIDI” and “standard fonts” do). We can go much further, making models of our 
> intentions and sending them with the objects in question. Good models allow 
> much better brokerage and match-up between “visiting actors” and the stage 
> they are given to perform on.
> This is an ongoing research problem that is central to many critical scaling 
> issues in future programming and we expect to extend what can be done as our 
> research project proceeds.
> 

I find that here the need for a context is implicit. Without context, content 
has no meaning. If I'm "building a sound" or "making a font", then the 
intention has to be taken with its context... and preferably across a few 
contexts so that the intention is more clear... or to have a flexible content 
definition that illustrates the full intention across all contexts. (in exactly 
the same way that outlines are scalable across many "bitmap resolution" 
contexts). Perhaps, for example, the font or sound is intended as a subtle 
sound or font that mixes easily with its background (transparency is not 
default in a typesetting context, but "mixing" is a default in audio contexts). 
Perhaps a sound is a bass drum which is intended to cut through a mix... in 
which case, its default is to do sidechain compression on the rest of the 
channels in a mix... this "intention of content" is useful and necessary and 
more developed in certain of our areas than others (for example, fonts in 
typesetting have a much better intention-defininition-capacity than sounds in 
music composition).

I'm essentially talking about content intent being able to be baked in, so that 
content becomes objects (including function, not just state) that rather than 
simply specifying some single dimensional output, specifies some intractability 
with its environment. For example, a certain typestyle that inverted its colour 
on low contrast backgrounds.

Where the intent differs from the original authors intent, overriding by 
"subclassing" style processes would allow specification through customisation.

Julian.___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Dan Amelang]

On Mon, May 10, 2010 at 10:46 AM, John Zabroski  wrote:
> Alan,
>
> If I took the time to write an "idea memo", would you (and possibly others)
> at VPRI take the time to comment on it?  It would mainly be example-driven
> and use an interweaving storywriting style, since I am not well-versed in
> scientific writing style, but, if necessary, I could cite and compare to
> various academic work.

I'll read it.

Dan

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[John Zabroski]

Alan,

If I took the time to write an "idea memo", would you (and possibly others)
at VPRI take the time to comment on it?  It would mainly be example-driven
and use an interweaving storywriting style, since I am not well-versed in
scientific writing style, but, if necessary, I could cite and compare to
various academic work.

By the way, I agree small teams with no interference are essential to
building systems.  However, you are conflating community involvement with
community innovation.  Communities should diverge and then cross-pollinate
ideas that have proven successful.  The point to community involvement is
not innovation or invention.  It is simply viral spreading of ideas.  That
is the point I tried to get across to you on the ComputingEd blog.

On Sat, May 8, 2010 at 4:32 PM, Alan Kay  wrote:

> In a subsequent email to the one below I mentioned some of the things that
> interested parties could do to participate.
>
> Let me ask you what kinds of projects do you think are done best by
> "community oriented styles of innovation", and just how much actual
> innovation happens (and has happened in the last 30 years)?
>
> Or whether the Linux kernel or the Smalltalk kernel or etc., were done by a
> community? Even Eric Raymond admits that what really goes on even for
> moderately innovative stuff in "open source" is that there is a small
> dedicated group from 1 to usually less than 10 people who work hard together
> to make a kernel, and this then empowers many people to contribute using its
> powers and styles.
>
> And the aims of STEPS are not "innovative" but "inventive". Increments on
> previous stuff are not barred, but what is required generally is careful
> design thinking. This is somewhat analogous to the difference between
> painting a picture or composing music and building a building.
>
> So I would suggest simply reading all of the STEPS related documents, then
> pick some part that seems interesting (whether we are already working on it
> or not), and come up with an "idea memo" such as this one (
> http://www.vpri.org/pdf/m2009014_membrane.pdf) by Ted Kaehler. (Since you
> are interested in "innovation", it might be a good idea to look at the
> processes of some of the great inventors of our field -- this is a technique
> that Ivan Sutherland (the inventor of computer graphics itself and much much
> more) used when working on hard projects.) We write quite a few of them, and
> post some of them on the website.
>
> One of the reasons we work this way is that brainstorming has proved to be
> very weak for difficult projects. But idea memos are things that can be
> pondered offline, and can sometimes lead to worthwhile insights. (Basic idea
> here is that really good ideas of the kind that are needed for these kinds
> of projects are very difficult to come by -- "most ideas are mediocre down
> to bad" -- and sifting people's opinions in the moment doesn't get deep
> enough.)
>
> Most idea memos don't get acted on (this one of Ted's is an example), but
> it was a very good thing for him to write it.
>
> So I again encourage the community to read what is written -- and to take
> some part of this project and try to find a point of view on it that gets at
> its intrinsic relational complexity. Devise math to express it. Devise a
> language that can both express and run it. Write up the ideas in a few
> pages. Etc.
>
> This is a little more like the way the scientific community goes about its
> business. And so did the "classic ARPA research community" that I come from
> on tough projects such as the inventions of personal computing, GUI,
> object-oriented programming, Desk Top Publishing, Laserprinting, Ethernet,
> Internet, etc.
>
> Cheers,
>
> Alan
>
> --
> *From:* Jakob Praher 
> *To:* fonc@vpri.org
> *Sent:* Sat, May 8, 2010 12:25:12 PM
>
> *Subject:* Re: [fonc] Fonc on Mac Snow Leopard?
>
> Hi Alan,
>
> just out of curiosity: I am wondering why VPRI is not aiming at a more
> community oriented style of innovation. Do you think the communcation effort
> is not worth the cost since you do not gain enough or even loose some
> freedom and / or speed by discussing archictural concepts more publicly?
> Does this imply that in your opinion open (source) projects only work (good)
> if there is something to be build incrementally (like a bazaar).
>
> I am also asking since I am interested in innovation through open
> communities. I am wondering why there is not more discussions (which I am
> sure you have internally at the VPRI) brought onto lists. Maybe one could
> discuss not only the implementation but also concepts behind the desi

Re: [fonc] Fonc on Mac Snow Leopard?

[Alan Kay]

More proof of concept.

One of the points here is to go far beyond the almost 40 year old Smalltalk, 
not to re-embrace it.

Cheers,

Alan





From: Jakob Praher 
To: fonc@vpri.org
Sent: Sun, May 9, 2010 3:08:48 PM
Subject: Re: [fonc] Fonc on Mac Snow Leopard?

Regarding syntax understanding: Yes I am aware of OMeta as well as the
original work on PEGs. (And also of PEG/LEG work by Ian).  I see is
that OMeta is used in the Lively Kernel also to understand Smalltalk
Syntax. Is this just proof of concept or is there some attempt to be
able to run Squeak programs on the browser through lively?

Am 09.05.10 23:41, schrieb Jakob Praher: 
>
>  
>Personally I was very excited about the Carl Hewitt's work on
>ActorScript  [1]
>lately. IMHO something like Lively Kernel could provide the client
>infrastructure for this Client Cloud
>computing. What is your opinion on his work? I also liked the notation
>he uses in the paper.
>
>>What I  do not like about JS is its imperative verboseness. I also have
>mixed feelings about JSON. I like the idea of beeing able to express
>something more denotational, e.g. in ways that keeps focussing on the
>simplest solution, and then use something like equational reasoning to
>derive at more performant and complex systems. In the end syntax
>matters and maybe there is no syntax that works for every solution.
>
>>So I see a high value in building Syntax understanding into libraries
>(This kind of homoiconicity is what I like from LISP-like langauges).
>Also Gilad Bracha did some work on parser combinators using a Self like
>language called Newspeak [2]. I found the IDE (I think it was called
>Hopscotch) very interesting in that it mirros the browser. Indeed the
>current version is running on top of Squeak. Maybe Lively and Newspeak
>could join forces? Taking the Idea of Hopscotch beyond a single
>language would be great.  Mozilla Lab's Bespin Project focuses on a
>kind of Emacs for the Web. What I would really like to see is some kind
>of Worldwide live development environment where projects are really
>living things and people can take different views on them. With real
>semantic mappings between individual notations and syntax.
>
>>-- Jakob
>
>>[1] - http://arxiv.org/abs/0907.3330
>>[2] - http://newspeaklanguage.org/
>
>>Am 09.05.10 01:06, schrieb Alan Kay:
> 
>>> 
>>By
>>the
>>way, people on this list should look at Dan Ingalls' Lively Kernel.
>>(http://www.lively-kernel.org/)
>>
>
>>>>Dan is also one of original authors of the NSF proposal for STEPS and
>>we claim successes in the Lively Kernel as STEPS successes as well. 
>>
>>>>That said, LK is much more like the bootstrapping of Squeak was, in
>>that a known architecture was adapted to the purpose of using JS as
>>"the machine code for a new operating system and live environment".
>>Again, there was the small dedicated team at Sun under the direction of
>>the master designer/builder (Dan). And once they got a few versions
>>bootstrapped they opened it up to interested open sourcers, and there
>>is a "lively" mailing list for Lively.
>>
>>>>We like Lively and pay a lot of attention to it because it covers some
>>of the functional ground that needs to be covered for a complete
>>system. The main difference is that they are not trying for really
>>small really relational models. However, the adaptation of the
>>Smalltalk architecture here is very efficient for building things (as
>>it was almost 40 years ago). So this is worth looking at.
>>
>>>>And we could imagine this as what STEPS might be like to a community,
>>except that we are trying to invent new more compact more powerful ways
>>to express programmatic ideas. At best, something like this is several
>>years in STEPS' future.
>>
>>>>Cheers,
>>
>>>>Alan
>>
>>
>>
>>
>>
>>

From: >>Jakob Praher 
>>To: fonc@vpri.org
>>Sent: Sat, May 8,
>>2010
>>12:25:12 PM
>>Subject: Re: [fonc]
>>Fonc on Mac Snow Leopard?
>>
>> >>Hi Alan,
>>
>>>>just out of curiosity: I am wondering why VPRI is not aiming at a more
>>community oriented style of innovation. Do you think the communcation
>>effort is not worth the cost since you do not gain enough or even loose
>>some freedom and / or speed by discussing archictural concepts more
>>publicly? Does this imply that in your opinion open (source) projects
>>only work (good) if there is something to be build incrementally (like
>>a bazaar). 
>

Re: [fonc] Fonc on Mac Snow Leopard?

[Alan Kay]

Hi Jakob,

I'm always interested in Carl's ideas (he's one of the few in our field that 
really has unusual and interesting slants on computation).

The whole point of the OMeta in JS embedding is that both JS syntax and 
semantics can be buried (that is JS winds up being like an assembly code). If 
it had more reflection, then much more could be done.

Cheers,

Alan





From: Jakob Praher 
To: Fundamentals of New Computing 
Sent: Sun, May 9, 2010 2:41:53 PM
Subject: Re: [fonc] Fonc on Mac Snow Leopard?

Personally I was very excited about the Carl Hewitt's work on
ActorScript  [1]
lately. IMHO something like Lively Kernel could provide the client
infrastructure for this Client Cloud
computing. What is your opinion on his work? I also liked the notation
he uses in the paper.

What I  do not like about JS is its imperative verboseness. I also have
mixed feelings about JSON. I like the idea of beeing able to express
something more denotational, e.g. in ways that keeps focussing on the
simplest solution, and then use something like equational reasoning to
derive at more performant and complex systems. In the end syntax
matters and maybe there is no syntax that works for every solution.

So I see a high value in building Syntax understanding into libraries
(This kind of homoiconicity is what I like from LISP-like langauges).
Also Gilad Bracha did some work on parser combinators using a Self like
language called Newspeak [2]. I found the IDE (I think it was called
Hopscotch) very interesting in that it mirros the browser. Indeed the
current version is running on top of Squeak. Maybe Lively and Newspeak
could join forces? Taking the Idea of Hopscotch beyond a single
language would be great.  Mozilla Lab's Bespin Project focuses on a
kind of Emacs for the Web. What I would really like to see is some kind
of Worldwide live development environment where projects are really
living things and people can take different views on them. With real
semantic mappings between individual notations and syntax.

-- Jakob

[1] - http://arxiv.org/abs/0907.3330
[2] - http://newspeaklanguage.org/

Am 09.05.10 01:06, schrieb Alan Kay: 
> 
>By
>the way, people on this list should look at Dan Ingalls' Lively Kernel.
>(http://www.lively-kernel.org/)
>

>>Dan is also one of original authors of the NSF proposal for STEPS and
>we claim successes in the Lively Kernel as STEPS successes as well. 
>
>>That said, LK is much more like the bootstrapping of Squeak was, in
>that a known architecture was adapted to the purpose of using JS as
>"the machine code for a new operating system and live environment".
>Again, there was the small dedicated team at Sun under the direction of
>the master designer/builder (Dan). And once they got a few versions
>bootstrapped they opened it up to interested open sourcers, and there
>is a "lively" mailing list for Lively.
>
>>We like Lively and pay a lot of attention to it because it covers some
>of the functional ground that needs to be covered for a complete
>system. The main difference is that they are not trying for really
>small really relational models. However, the adaptation of the
>Smalltalk architecture here is very efficient for building things (as
>it was almost 40 years ago). So this is worth looking at.
>
>>And we could imagine this as what STEPS might be like to a community,
>except that we are trying to invent new more compact more powerful ways
>to express programmatic ideas. At best, something like this is several
>years in STEPS' future.
>
>>Cheers,
>
>>Alan
>
>
>
>
>
>

From: >Jakob Praher 
>To: fonc@vpri.org
>Sent: Sat, May 8, 2010
>12:25:12 PM
>Subject: Re: [fonc]
>Fonc on Mac Snow Leopard?
>
> >Hi Alan,
>
>>just out of curiosity: I am wondering why VPRI is not aiming at a more
>community oriented style of innovation. Do you think the communcation
>effort is not worth the cost since you do not gain enough or even loose
>some freedom and / or speed by discussing archictural concepts more
>publicly? Does this imply that in your opinion open (source) projects
>only work (good) if there is something to be build incrementally (like
>a bazaar). 
>
>>I am also asking since I am interested in innovation through open
>communities. I am wondering why there is not more discussions (which I
>am sure you have internally at the VPRI) brought onto lists. Maybe one
>could discuss not only the implementation but also concepts behind the
>design?
>
>>Having a daytime job I know that sometimes catching up with a lively
>community is a challenge, on the other hand seeing where things are
>going and maybe also join forces in early stages might be interesting,
>no? For i

Re: [fonc] Fonc on Mac Snow Leopard?

[Jakob Praher]

Regarding syntax understanding: Yes I am aware of OMeta as well as the
original work on PEGs. (And also of PEG/LEG work by Ian).  I see is that
OMeta is used in the Lively Kernel also to understand Smalltalk Syntax.
Is this just proof of concept or is there some attempt to be able to run
Squeak programs on the browser through lively?

Am 09.05.10 23:41, schrieb Jakob Praher:
> Personally I was very excited about the Carl Hewitt's work on
> ActorScript  [1] lately. IMHO something like Lively Kernel could
> provide the client infrastructure for this Client Cloud computing.
> What is your opinion on his work? I also liked the notation he uses in
> the paper.
>
> What I  do not like about JS is its imperative verboseness. I also
> have mixed feelings about JSON. I like the idea of beeing able to
> express something more denotational, e.g. in ways that keeps focussing
> on the simplest solution, and then use something like equational
> reasoning to derive at more performant and complex systems. In the end
> syntax matters and maybe there is no syntax that works for every solution.
>
> So I see a high value in building Syntax understanding into libraries
> (This kind of homoiconicity is what I like from LISP-like langauges).
> Also Gilad Bracha did some work on parser combinators using a Self
> like language called Newspeak [2]. I found the IDE (I think it was
> called Hopscotch) very interesting in that it mirros the browser.
> Indeed the current version is running on top of Squeak. Maybe Lively
> and Newspeak could join forces? Taking the Idea of Hopscotch beyond a
> single language would be great.  Mozilla Lab's Bespin Project focuses
> on a kind of Emacs for the Web. What I would really like to see is
> some kind of Worldwide live development environment where projects are
> really living things and people can take different views on them. With
> real semantic mappings between individual notations and syntax.
>
> -- Jakob
>
> [1] - http://arxiv.org/abs/0907.3330
> [2] - http://newspeaklanguage.org/
>
> Am 09.05.10 01:06, schrieb Alan Kay:
>> By the way, people on this list should look at Dan Ingalls' Lively
>> Kernel. (http://www.lively-kernel.org/)
>>
>> Dan is also one of original authors of the NSF proposal for STEPS and
>> we claim successes in the Lively Kernel as STEPS successes as well.
>>
>> That said, LK is much more like the bootstrapping of Squeak was, in
>> that a known architecture was adapted to the purpose of using JS as
>> "the machine code for a new operating system and live environment".
>> Again, there was the small dedicated team at Sun under the direction
>> of the master designer/builder (Dan). And once they got a few
>> versions bootstrapped they opened it up to interested open sourcers,
>> and there is a "lively" mailing list for Lively.
>>
>> We like Lively and pay a lot of attention to it because it covers
>> some of the functional ground that needs to be covered for a complete
>> system. The main difference is that they are not trying for really
>> small really relational models. However, the adaptation of the
>> Smalltalk architecture here is very efficient for building things (as
>> it was almost 40 years ago). So this is worth looking at.
>>
>> And we could imagine this as what STEPS might be like to a community,
>> except that we are trying to invent new more compact more powerful
>> ways to express programmatic ideas. At best, something like this is
>> several years in STEPS' future.
>>
>> Cheers,
>>
>> Alan
>>
>>
>> 
>> *From:* Jakob Praher 
>> *To:* fonc@vpri.org
>> *Sent:* Sat, May 8, 2010 12:25:12 PM
>> *Subject:* Re: [fonc] Fonc on Mac Snow Leopard?
>>
>> Hi Alan,
>>
>> just out of curiosity: I am wondering why VPRI is not aiming at a
>> more community oriented style of innovation. Do you think the
>> communcation effort is not worth the cost since you do not gain
>> enough or even loose some freedom and / or speed by discussing
>> archictural concepts more publicly? Does this imply that in your
>> opinion open (source) projects only work (good) if there is something
>> to be build incrementally (like a bazaar).
>>
>> I am also asking since I am interested in innovation through open
>> communities. I am wondering why there is not more discussions (which
>> I am sure you have internally at the VPRI) brought onto lists. Maybe
>> one could discuss not only the implementation but also concepts
>> behind the design?
>>
>> Having a daytime job I know 

Re: [fonc] Fonc on Mac Snow Leopard?

[Jakob Praher]

Personally I was very excited about the Carl Hewitt's work on
ActorScript  [1] lately. IMHO something like Lively Kernel could provide
the client infrastructure for this Client Cloud computing. What is your
opinion on his work? I also liked the notation he uses in the paper.

What I  do not like about JS is its imperative verboseness. I also have
mixed feelings about JSON. I like the idea of beeing able to express
something more denotational, e.g. in ways that keeps focussing on the
simplest solution, and then use something like equational reasoning to
derive at more performant and complex systems. In the end syntax matters
and maybe there is no syntax that works for every solution.

So I see a high value in building Syntax understanding into libraries
(This kind of homoiconicity is what I like from LISP-like langauges).
Also Gilad Bracha did some work on parser combinators using a Self like
language called Newspeak [2]. I found the IDE (I think it was called
Hopscotch) very interesting in that it mirros the browser. Indeed the
current version is running on top of Squeak. Maybe Lively and Newspeak
could join forces? Taking the Idea of Hopscotch beyond a single language
would be great.  Mozilla Lab's Bespin Project focuses on a kind of Emacs
for the Web. What I would really like to see is some kind of Worldwide
live development environment where projects are really living things and
people can take different views on them. With real semantic mappings
between individual notations and syntax.

-- Jakob

[1] - http://arxiv.org/abs/0907.3330
[2] - http://newspeaklanguage.org/

Am 09.05.10 01:06, schrieb Alan Kay:
> By the way, people on this list should look at Dan Ingalls' Lively
> Kernel. (http://www.lively-kernel.org/)
>
> Dan is also one of original authors of the NSF proposal for STEPS and
> we claim successes in the Lively Kernel as STEPS successes as well.
>
> That said, LK is much more like the bootstrapping of Squeak was, in
> that a known architecture was adapted to the purpose of using JS as
> "the machine code for a new operating system and live environment".
> Again, there was the small dedicated team at Sun under the direction
> of the master designer/builder (Dan). And once they got a few versions
> bootstrapped they opened it up to interested open sourcers, and there
> is a "lively" mailing list for Lively.
>
> We like Lively and pay a lot of attention to it because it covers some
> of the functional ground that needs to be covered for a complete
> system. The main difference is that they are not trying for really
> small really relational models. However, the adaptation of the
> Smalltalk architecture here is very efficient for building things (as
> it was almost 40 years ago). So this is worth looking at.
>
> And we could imagine this as what STEPS might be like to a community,
> except that we are trying to invent new more compact more powerful
> ways to express programmatic ideas. At best, something like this is
> several years in STEPS' future.
>
> Cheers,
>
> Alan
>
>
> ----------------
> *From:* Jakob Praher 
> *To:* fonc@vpri.org
> *Sent:* Sat, May 8, 2010 12:25:12 PM
> *Subject:* Re: [fonc] Fonc on Mac Snow Leopard?
>
> Hi Alan,
>
> just out of curiosity: I am wondering why VPRI is not aiming at a more
> community oriented style of innovation. Do you think the communcation
> effort is not worth the cost since you do not gain enough or even
> loose some freedom and / or speed by discussing archictural concepts
> more publicly? Does this imply that in your opinion open (source)
> projects only work (good) if there is something to be build
> incrementally (like a bazaar).
>
> I am also asking since I am interested in innovation through open
> communities. I am wondering why there is not more discussions (which I
> am sure you have internally at the VPRI) brought onto lists. Maybe one
> could discuss not only the implementation but also concepts behind the
> design?
>
> Having a daytime job I know that sometimes catching up with a lively
> community is a challenge, on the other hand seeing where things are
> going and maybe also join forces in early stages might be interesting,
> no? For instance there could be other people doing PoC work.
>
> Thanks,
> Jakob
>
> Am 08.05.10 18:03, schrieb Alan Kay:
>> Glad you are interested, but don't hold your breath. We've got quite
>> a bit more to do this year.
>>
>> It's not an incremental project like many open source people are used
>> to. We actually throw away much of our code and rewrite with new
>> designs pretty often.
>>
>> Cheers,
>>
>> Alan
>>
>> --

Re: [fonc] Fonc on Mac Snow Leopard?

[BGB]

yep.

seems an interesting way to do things, as then the emphasis can be kept on the 
design rather than on the implementation.

in general, I agree. we don't need "one true app X" or "one true implementation 
Y". there are already enough of these...

it is better then if technology can be kept open, with documented designs and 
modular implementations, such that even with a potentially large project one 
can still pursue better designs, cleaner and better implementation strategies, 
experiment with alternative ways of doing things, ...

so, if one wants to try something, they can write a new part and test it, and 
throw away parts later that don't work out so well.


I have tried this in the context of my efforts as well, although there is still 
a lot of emphasis on making everything work and be usable, and in many cases 
things have "settled" and become difficult to change.


this has led some to me implementing parts in ways which not everyone has 
agreed with, for example, I chose a textual assembler rather than using a 
binary-API for the assembler, or micro-crafting machine-code fragments in the 
codegen. however, as I see it, this really doesn't matter so much, and the 
textual assembler is easier to use and more general purpose (although if really 
needed, one can gain around a 5x speedup by bypassing the ASM preprocessor and 
parser and direct-driving the assembler internals). but, really, for most 
things, how likely is this to matter?...

as I see it, one can optimize things, but I tend to somewhat dislike optimizing 
things in ways which compromise the usability of their external interface.

I say this after having just gained a 40x speedup (for larger inputs) in a tool 
based on my C compiler, based on a few optimization tricks: copying over some 
code (from elsewhere in the project) which uses a tree-structure for the 
metadata database (vs linear lookups), and making use of hash-tables in a few 
places (to shortcut a few more linear searches).

nevermind the core of my compiler is still built around XML processing... as I 
see it, the merits are worth the costs...

I also have an x86 interpreter, with many core parts (such as the instruction 
decoder) based on string-processing, but it performs within 70x of native, so 
it is good enough... (many other interpreters are faster, but most other 
interpreters don't have to deal with segmentation or address-translation 
either, and this eats up a bit more of the time...).

I guess I am also odd in that I write most of my interpreters in plain C 
(typically not ASM), and use JIT and SMC more as a tool to opening up some 
doors, and not simply in some attempt to optimize things (although it can be 
used for this as well).

as I see it, the big thing in optimizing is not how to make doing an operation 
X times faster, but rather often how to not do it in the first place...


I guess a bit of a difference though is that I end up doing a lot of cloning, 
where I see designs elsewhere, and then implement my own version.


granted, there may often be a lot of variance between my implementation of 
something and the implied implementation of the thing.

like, me remembering a while ago when I ended up pointing out my BGBScript 
implementation to someone, and them being confused by a lot of what was being 
dumped out on the screen (mostly internal messages intended for debugging). a 
lot of the information was coming back using Scheme-style value formatting, 
since this is what my typesystem largely uses internally.

"x=[1,2,3];"
=>
"(set! x (array 1 2 3))"
"#(1 2 3)"
...

well, along with some messages showing the results of attempting to "reduce" 
expressions, showing a disassembly of the internal bytecode, ...

bytecode (written in a slightly different style): "mark push_1 push_2 push_3 
array dup store(x) ret".


note that a lot of stuff also uses a signature system, basically composed of 
strings with sequences of characters used to encode various value types, 
references into the metadata database, ...

(if anyone has seen the internals of the Java ".class" fileformat and the IA64 
ABI, this is a big part of the system, but there are many other details...).


  - Original Message - 
  From: Alan Kay 
  To: Fundamentals of New Computing 
  Sent: Saturday, May 08, 2010 9:03 AM
  Subject: Re: [fonc] Fonc on Mac Snow Leopard?


  Glad you are interested, but don't hold your breath. We've got quite a bit 
more to do this year. 

  It's not an incremental project like many open source people are used to. We 
actually throw away much of our code and rewrite with new designs pretty often.

  Cheers,

  Alan


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Pascal J. Bourguignon]

On 2010/05/09, at 10:21 , Christopher Bratlien wrote:


Just dipping my toe into this conversation.

I think it's cool that Javascript has protoype inheritence of Self,  
and Lively Kernel gives Javascript its Morphic back. Also, LK is  
spawning ideas such as Lively Fabrik http://www.lively-kernel.org/repository/lively-wiki/Fabrik.xhtml


I would love to interact with a visual (and lively, steppable) model  
of the metacircular evaluator from Scheme/SICP done in Javascript.  
Page 13 of the Lisp 1.5

allows a reader to contemplate evaluating:

(LAMBDA (X Y) (CONS (CAR X) Y)); ((A B) (C D))

Has somebody already modeled this exercise visually? I would like to  
see a running, in my face, in the browser, model of this.




There's the Alligator-and-egg stuff:

http://visual-languages.blogspot.com/2009/07/alligator-eggs-revisited.html
http://visual-languages.blogspot.com/2009/07/alligator-eggs-for-last-time.html
http://worrydream.com/AlligatorEggs/

--
__Pascal Bourguignon__
http://www.informatimago.com




___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Jakob Praher]

I will do so. I like the idea of an idea memo.
>
> One of the reasons we work this way is that brainstorming has proved
> to be very weak for difficult projects. But idea memos are things that
> can be pondered offline, and can sometimes lead to worthwhile
> insights. (Basic idea here is that really good ideas of the kind that
> are needed for these kinds of projects are very difficult to come by
> -- "most ideas are mediocre down to bad" -- and sifting people's
> opinions in the moment doesn't get deep enough.)
> Most idea memos don't get acted on (this one of Ted's is an example),
> but it was a very good thing for him to write it.
This is perfectly fine. Tracking relations between memos might help to
also visualize the dialectic processes.
>
> So I again encourage the community to read what is written -- and to
> take some part of this project and try to find a point of view on it
> that gets at its intrinsic relational complexity. Devise math to
> express it. Devise a language that can both express and run it. Write
> up the ideas in a few pages. Etc.
> This is a little more like the way the scientific community goes about
> its business. And so did the "classic ARPA research community" that I
> come from on tough projects such as the inventions of personal
> computing, GUI, object-oriented programming, Desk Top Publishing,
> Laserprinting, Ethernet, Internet, etc.
>
Thank you for your insights!
Jakob

> 
> *From:* Jakob Praher 
> *To:* fonc@vpri.org
> *Sent:* Sat, May 8, 2010 12:25:12 PM
> *Subject:* Re: [fonc] Fonc on Mac Snow Leopard?
>
> Hi Alan,
>
> just out of curiosity: I am wondering why VPRI is not aiming at a more
> community oriented style of innovation. Do you think the communcation
> effort is not worth the cost since you do not gain enough or even
> loose some freedom and / or speed by discussing archictural concepts
> more publicly? Does this imply that in your opinion open (source)
> projects only work (good) if there is something to be build
> incrementally (like a bazaar).
>
> I am also asking since I am interested in innovation through open
> communities. I am wondering why there is not more discussions (which I
> am sure you have internally at the VPRI) brought onto lists. Maybe one
> could discuss not only the implementation but also concepts behind the
> design?
>
> Having a daytime job I know that sometimes catching up with a lively
> community is a challenge, on the other hand seeing where things are
> going and maybe also join forces in early stages might be interesting,
> no? For instance there could be other people doing PoC work.
>
> Thanks,
> Jakob
>
> Am 08.05.10 18:03, schrieb Alan Kay:
>> Glad you are interested, but don't hold your breath. We've got quite
>> a bit more to do this year.
>>
>> It's not an incremental project like many open source people are used
>> to. We actually throw away much of our code and rewrite with new
>> designs pretty often.
>>
>> Cheers,
>>
>> Alan
>>
>> 
>> *From:* DeNigris Sean 
>> *To:* Fundamentals of New Computing 
>> *Sent:* Sat, May 8, 2010 8:55:29 AM
>> *Subject:* Re: [fonc] Fonc on Mac Snow Leopard?
>>
>>> We don't plan to wind up using any one else's GC  so I wouldn't
>>> worry.
>>
>> Not worried - just excited to play with this stuff!
>>
>> Sean 
>>
>>
>> ___
>> fonc mailing list
>> fonc@vpri.org
>> http://vpri.org/mailman/listinfo/fonc
>>   
>
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>   

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Christopher Bratlien]

Just dipping my toe into this conversation.

I think it's cool that Javascript has protoype inheritence of Self, and
Lively Kernel gives Javascript its Morphic back. Also, LK is spawning ideas
such as Lively Fabrik
http://www.lively-kernel.org/repository/lively-wiki/Fabrik.xhtml

I would love to interact with a visual (and lively, steppable) model of the
metacircular evaluator from Scheme/SICP done in Javascript. Page 13 of the
Lisp 1.5
allows a reader to contemplate evaluating:

(LAMBDA (X Y) (CONS (CAR X) Y)); ((A B) (C D))

Has somebody already modeled this exercise visually? I would like to see a
running, in my face, in the browser, model of this.

Ok, I'm pulling my toe back out of the water now...

Best wishes,
Chris

On Sat, May 8, 2010 at 6:06 PM, Alan Kay  wrote:

> By the way, people on this list should look at Dan Ingalls' Lively Kernel.
> (http://www.lively-kernel.org/)
>
> Dan is also one of original authors of the NSF proposal for STEPS and we
> claim successes in the Lively Kernel as STEPS successes as well.
>
> That said, LK is much more like the bootstrapping of Squeak was, in that a
> known architecture was adapted to the purpose of using JS as "the machine
> code for a new operating system and live environment". Again, there was the
> small dedicated team at Sun under the direction of the master
> designer/builder (Dan). And once they got a few versions bootstrapped they
> opened it up to interested open sourcers, and there is a "lively" mailing
> list for Lively.
>
> We like Lively and pay a lot of attention to it because it covers some of
> the functional ground that needs to be covered for a complete system. The
> main difference is that they are not trying for really small really
> relational models. However, the adaptation of the Smalltalk architecture
> here is very efficient for building things (as it was almost 40 years ago).
> So this is worth looking at.
>
> And we could imagine this as what STEPS might be like to a community,
> except that we are trying to invent new more compact more powerful ways to
> express programmatic ideas. At best, something like this is several years in
> STEPS' future.
>
> Cheers,
>
> Alan
>
>
> --------------
> *From:* Jakob Praher 
> *To:* fonc@vpri.org
> *Sent:* Sat, May 8, 2010 12:25:12 PM
>
> *Subject:* Re: [fonc] Fonc on Mac Snow Leopard?
>
> Hi Alan,
>
> just out of curiosity: I am wondering why VPRI is not aiming at a more
> community oriented style of innovation. Do you think the communcation effort
> is not worth the cost since you do not gain enough or even loose some
> freedom and / or speed by discussing archictural concepts more publicly?
> Does this imply that in your opinion open (source) projects only work (good)
> if there is something to be build incrementally (like a bazaar).
>
> I am also asking since I am interested in innovation through open
> communities. I am wondering why there is not more discussions (which I am
> sure you have internally at the VPRI) brought onto lists. Maybe one could
> discuss not only the implementation but also concepts behind the design?
>
> Having a daytime job I know that sometimes catching up with a lively
> community is a challenge, on the other hand seeing where things are going
> and maybe also join forces in early stages might be interesting, no? For
> instance there could be other people doing PoC work.
>
> Thanks,
> Jakob
>
> Am 08.05.10 18:03, schrieb Alan Kay:
>
>  Glad you are interested, but don't hold your breath. We've got quite a
> bit more to do this year.
>
> It's not an incremental project like many open source people are used to.
> We actually throw away much of our code and rewrite with new designs pretty
> often.
>
> Cheers,
>
> Alan
>
>  --
> *From:* DeNigris Sean  
> *To:* Fundamentals of New Computing  
> *Sent:* Sat, May 8, 2010 8:55:29 AM
> *Subject:* Re: [fonc] Fonc on Mac Snow Leopard?
>
>We don't plan to wind up using any one else's GC  so I wouldn't
> worry.
>
>
>  Not worried - just excited to play with this stuff!
>
> Sean
>
>
> ___
> fonc mailing listf...@vpri.orghttp://vpri.org/mailman/listinfo/fonc
>
>
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Alan Kay]

By the way, people on this list should look at Dan Ingalls' Lively Kernel. 
(http://www.lively-kernel.org/)

Dan is also one of original authors of the NSF proposal for STEPS and we claim 
successes in the Lively Kernel as STEPS successes as well. 

That said, LK is much more like the bootstrapping of Squeak was, in that a 
known architecture was adapted to the purpose of using JS as "the machine code 
for a new operating system and live environment". Again, there was the small 
dedicated team at Sun under the direction of the master designer/builder (Dan). 
And once they got a few versions bootstrapped they opened it up to interested 
open sourcers, and there is a "lively" mailing list for Lively.

We like Lively and pay a lot of attention to it because it covers some of the 
functional ground that needs to be covered for a complete system. The main 
difference is that they are not trying for really small really relational 
models. However, the adaptation of the Smalltalk architecture here is very 
efficient for building things (as it was almost 40 years ago). So this is worth 
looking at.

And we could imagine this as what STEPS might be like to a community, except 
that we are trying to invent new more compact more powerful ways to express 
programmatic ideas. At best, something like this is several years in STEPS' 
future.

Cheers,

Alan






From: Jakob Praher 
To: fonc@vpri.org
Sent: Sat, May 8, 2010 12:25:12 PM
Subject: Re: [fonc] Fonc on Mac Snow Leopard?

 Hi Alan,

just out of curiosity: I am wondering why VPRI is not aiming at a more
community oriented style of innovation. Do you think the communcation
effort is not worth the cost since you do not gain enough or even loose
some freedom and / or speed by discussing archictural concepts more
publicly? Does this imply that in your opinion open (source) projects
only work (good) if there is something to be build incrementally (like
a bazaar). 

I am also asking since I am interested in innovation through open
communities. I am wondering why there is not more discussions (which I
am sure you have internally at the VPRI) brought onto lists. Maybe one
could discuss not only the implementation but also concepts behind the
design?

Having a daytime job I know that sometimes catching up with a lively
community is a challenge, on the other hand seeing where things are
going and maybe also join forces in early stages might be interesting,
no? For instance there could be other people doing PoC work.

Thanks,
Jakob

Am 08.05.10 18:03, schrieb Alan Kay: 
> 
>Glad you are interested, but don't hold your breath. We've got
>quite a bit more to do this year. 
>
>>It's not an incremental project like many open source people are used
>to. We actually throw away much of our code and rewrite with new
>designs pretty often.
>
>>Cheers,
>
>>Alan
>
>
>
>

From: >DeNigris Sean 
>To: Fundamentals of
>New Computing 
>Sent: Sat, May 8, 2010
>8:55:29 AM
>Subject: Re: [fonc]
>Fonc on Mac Snow Leopard?
>
> 
>We don't plan to wind up using any one
>>else's GC  so I wouldn't worry.
>>
>
>
>Not worried - just excited to play with this stuff!
> 
>
>
>Sean 
>
>
>___
>fonc mailing list
>fonc@vpri.org http://vpri.org/mailman/listinfo/fonc 



  ___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Kevin DeGraaf]

I wouldn't mind seeing the throw-away projects.  If I didn't think
there was something to learn from failure, I would leave the startup
world...

Kevin.

On Sat, May 8, 2010 at 9:03 AM, Alan Kay  wrote:
> Glad you are interested, but don't hold your breath. We've got quite a bit
> more to do this year.
>
> It's not an incremental project like many open source people are used to. We
> actually throw away much of our code and rewrite with new designs pretty
> often.
>
> Cheers,
>
> Alan
>
> 
> From: DeNigris Sean 
> To: Fundamentals of New Computing 
> Sent: Sat, May 8, 2010 8:55:29 AM
> Subject: Re: [fonc] Fonc on Mac Snow Leopard?
>
> We don't plan to wind up using any one else's GC  so I wouldn't worry.
>
> Not worried - just excited to play with this stuff!
> Sean
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Alan Kay]

In a subsequent email to the one below I mentioned some of the things that 
interested parties could do to participate.

Let me ask you what kinds of projects do you think are done best by "community 
oriented styles of innovation", and just how much actual innovation happens 
(and has happened in the last 30 years)?

Or whether the Linux kernel or the Smalltalk kernel or etc., were done by a 
community? Even Eric Raymond admits that what really goes on even for 
moderately innovative stuff in "open source" is that there is a small dedicated 
group from 1 to usually less than 10 people who work hard together to make a 
kernel, and this then empowers many people to contribute using its powers and 
styles.

And the aims of STEPS are not "innovative" but "inventive". Increments on 
previous stuff are not barred, but what is required generally is careful design 
thinking. This is somewhat analogous to the difference between painting a 
picture or composing music and building a building.

So I would suggest simply reading all of the STEPS related documents, then pick 
some part that seems interesting (whether we are already working on it or not), 
and come up with an "idea memo" such as this one 
(http://www.vpri.org/pdf/m2009014_membrane.pdf) by Ted Kaehler. (Since you are 
interested in "innovation", it might be a good idea to look at the processes of 
some of the great inventors of our field -- this is a technique that Ivan 
Sutherland (the inventor of computer graphics itself and much much more) used 
when working on hard projects.) We write quite a few of them, and post some of 
them on the website.

One of the reasons we work this way is that brainstorming has proved to be very 
weak for difficult projects. But idea memos are things that can be pondered 
offline, and can sometimes lead to worthwhile insights. (Basic idea here is 
that really good ideas of the kind that are needed for these kinds of projects 
are very difficult to come by -- "most ideas are mediocre down to bad" -- and 
sifting people's opinions in the moment doesn't get deep enough.)

Most idea memos don't get acted on (this one of Ted's is an example), but it 
was a very good thing for him to write it.

So I again encourage the community to read what is written -- and to take some 
part of this project and try to find a point of view on it that gets at its 
intrinsic relational complexity. Devise math to express it. Devise a language 
that can both express and run it. Write up the ideas in a few pages. Etc.

This is a little more like the way the scientific community goes about its 
business. And so did the "classic ARPA research community" that I come from on 
tough projects such as the inventions of personal computing, GUI, 
object-oriented programming, Desk Top Publishing, Laserprinting, Ethernet, 
Internet, etc.

Cheers,

Alan




____
From: Jakob Praher 
To: fonc@vpri.org
Sent: Sat, May 8, 2010 12:25:12 PM
Subject: Re: [fonc] Fonc on Mac Snow Leopard?

 Hi Alan,

just out of curiosity: I am wondering why VPRI is not aiming at a more
community oriented style of innovation. Do you think the communcation
effort is not worth the cost since you do not gain enough or even loose
some freedom and / or speed by discussing archictural concepts more
publicly? Does this imply that in your opinion open (source) projects
only work (good) if there is something to be build incrementally (like
a bazaar). 

I am also asking since I am interested in innovation through open
communities. I am wondering why there is not more discussions (which I
am sure you have internally at the VPRI) brought onto lists. Maybe one
could discuss not only the implementation but also concepts behind the
design?

Having a daytime job I know that sometimes catching up with a lively
community is a challenge, on the other hand seeing where things are
going and maybe also join forces in early stages might be interesting,
no? For instance there could be other people doing PoC work.

Thanks,
Jakob

Am 08.05.10 18:03, schrieb Alan Kay: 
> 
>Glad you are interested, but don't hold your breath. We've got
>quite a bit more to do this year. 
>
>>It's not an incremental project like many open source people are used
>to. We actually throw away much of our code and rewrite with new
>designs pretty often.
>
>>Cheers,
>
>>Alan
>
>
>
>
____
From: >DeNigris Sean 
>To: Fundamentals of
>New Computing 
>Sent: Sat, May 8, 2010
>8:55:29 AM
>Subject: Re: [fonc]
>Fonc on Mac Snow Leopard?
>
> 
>We don't plan to wind up using any one
>>else's GC  so I wouldn't worry.
>>
>
>
>Not worried - just excited to play with this stuff!
> 
>
>
>Sean 
>
>
>___
>fonc mailing list
>fonc@vpri.org http://vpri.org/mailman/listinfo/fonc 



  ___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Jakob Praher]

Hi Alan,

just out of curiosity: I am wondering why VPRI is not aiming at a more
community oriented style of innovation. Do you think the communcation
effort is not worth the cost since you do not gain enough or even loose
some freedom and / or speed by discussing archictural concepts more
publicly? Does this imply that in your opinion open (source) projects
only work (good) if there is something to be build incrementally (like a
bazaar).

I am also asking since I am interested in innovation through open
communities. I am wondering why there is not more discussions (which I
am sure you have internally at the VPRI) brought onto lists. Maybe one
could discuss not only the implementation but also concepts behind the
design?

Having a daytime job I know that sometimes catching up with a lively
community is a challenge, on the other hand seeing where things are
going and maybe also join forces in early stages might be interesting,
no? For instance there could be other people doing PoC work.

Thanks,
Jakob

Am 08.05.10 18:03, schrieb Alan Kay:
> Glad you are interested, but don't hold your breath. We've got quite a
> bit more to do this year.
>
> It's not an incremental project like many open source people are used
> to. We actually throw away much of our code and rewrite with new
> designs pretty often.
>
> Cheers,
>
> Alan
>
> 
> *From:* DeNigris Sean 
> *To:* Fundamentals of New Computing 
> *Sent:* Sat, May 8, 2010 8:55:29 AM
> *Subject:* Re: [fonc] Fonc on Mac Snow Leopard?
>
>> We don't plan to wind up using any one else's GC  so I wouldn't
>> worry.
>
> Not worried - just excited to play with this stuff!
>
> Sean 
>
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>   

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Casey Ransberger]

Burning the disk packs with the midnight oil? Sounds like so much fun:)



On May 8, 2010, at 9:03 AM, Alan Kay  wrote:

> Glad you are interested, but don't hold your breath. We've got quite a bit 
> more to do this year. 
> 
> It's not an incremental project like many open source people are used to. We 
> actually throw away much of our code and rewrite with new designs pretty 
> often.
> 
> Cheers,
> 
> Alan
> 
> From: DeNigris Sean 
> To: Fundamentals of New Computing 
> Sent: Sat, May 8, 2010 8:55:29 AM
> Subject: Re: [fonc] Fonc on Mac Snow Leopard?
> 
>> We don't plan to wind up using any one else's GC  so I wouldn't worry.
> 
> 
> Not worried - just excited to play with this stuff!
> 
> Sean 
> 
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[David Girle]

Understood that you need to keep this fluid.  It would still be
helpful to periodically snapshot stable builds, so that folks could
experiment as they read the vpri papers.

Regards,

David

On Sat, May 8, 2010 at 10:03 AM, Alan Kay  wrote:
> Glad you are interested, but don't hold your breath. We've got quite a bit
> more to do this year.
>
> It's not an incremental project like many open source people are used to. We
> actually throw away much of our code and rewrite with new designs pretty
> often.
>
> Cheers,
>
> Alan
>
> 
> From: DeNigris Sean 
> To: Fundamentals of New Computing 
> Sent: Sat, May 8, 2010 8:55:29 AM
> Subject: Re: [fonc] Fonc on Mac Snow Leopard?
>
> We don't plan to wind up using any one else's GC  so I wouldn't worry.
>
> Not worried - just excited to play with this stuff!
> Sean
>
> ___
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>

___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Alan Kay]

Glad you are interested, but don't hold your breath. We've got quite a bit more 
to do this year. 

It's not an incremental project like many open source people are used to. We 
actually throw away much of our code and rewrite with new designs pretty often.

Cheers,

Alan





From: DeNigris Sean 
To: Fundamentals of New Computing 
Sent: Sat, May 8, 2010 8:55:29 AM
Subject: Re: [fonc] Fonc on Mac Snow Leopard?


We don't plan to wind up using any one else's GC  so I wouldn't worry.
>
Not worried - just excited to play with this stuff!


Sean 


  ___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[DeNigris Sean]

> We don't plan to wind up using any one else's GC  so I wouldn't worry.


Not worried - just excited to play with this stuff!

Sean ___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Alan Kay]

We don't plan to wind up using any one else's GC  so I wouldn't worry.





From: DeNigris Sean 
To: Fundamentals of New Computing 
Sent: Sat, May 8, 2010 8:44:45 AM
Subject: Re: [fonc] Fonc on Mac Snow Leopard?

> the Boehm/Weiser GC as included in the sources does not compile on Snow 
> Leopard - this is not a COLA problem.

So no future for mac users then ;-).  Bummer...

There is a MacPort of gc7.1 that I successfully installed.  Is there any way to 
use that?

I tried various sneaky things, including:
1. put the 7.1 sources in fonc's gc6.7 folder
2. Added -D_XOPEN_SOURCE to CFLAGS
3. Put the macport lib files in the gc6.7 folder
But none worked out.

Thanks.
Sean
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc



  ___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[DeNigris Sean]

> the Boehm/Weiser GC as included in the sources does not compile on Snow 
> Leopard - this is not a COLA problem.

So no future for mac users then ;-).  Bummer...

There is a MacPort of gc7.1 that I successfully installed.  Is there any way to 
use that?

I tried various sneaky things, including:
1. put the 7.1 sources in fonc's gc6.7 folder
2. Added -D_XOPEN_SOURCE to CFLAGS
3. Put the macport lib files in the gc6.7 folder
But none worked out.

Thanks.
Sean
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Fonc on Mac Snow Leopard?

[Haupt, Michael]

Sean,

the Boehm/Weiser GC as included in the sources does not compile on Snow Leopard 
- this is not a COLA problem.

Best,

Michael

Am 08.05.2010 um 00:54 schrieb "DeNigris Sean" 
mailto:s...@clipperadams.com>>:

When compiling fonc-stable from "svn checkout 
 
http://piumarta.com/svn2/idst/tags/idst-376 fonc-stable" on Mac Snow Leopard 
(10.6.2), I got the following warnings (full trace at message end)...

./mark_rts.c: In function ‘GC_approx_sp’:
./mark_rts.c:379: warning: function returns address of local variable

dyn_load.c: In function ‘GC_init_dyld’:
dyn_load.c:1223: warning: passing argument 1 of 
‘_dyld_register_func_for_add_image’ from incompatible pointer type
dyn_load.c:1224: warning: passing argument 1 of 
‘_dyld_register_func_for_remove_image’ from incompatible pointer type
dyn_load.c:1236: warning: ‘_dyld_bind_fully_image_containing_address’ is 
deprecated (declared at /usr/include/mach-o/dyld.h:241)

I removed -Werror from object/boot/Makefile, just to see if it would compile, 
with no joy.

Someone else posted not being able to compile on 10.6 in September of last year 
(http://vpri.org/mailman/private/fonc/2009/001145.html).
  Is there a working version or workaround?  Has anyone been successful in Snow 
Leopard?

Thanks.

Sean DeNigris
s...@clipperadams.com

Full trace:
~/fonc-stable$ make
/bin/sh -ec 'for dir in object function; do ( cd $dir; make ); done'
./boot/configure   boot/Makefile id/Makefile idc/Makefile idc/idc st80/Makefile 
&& touch .config-stamp
i386-apple-darwin10.3.0:
  TARGET = i386-apple-darwin10.3.0
  PREFIX = /usr/local/lib/idc/i386-apple-darwin10.3.0/
  CC = cc
  CFLAGS = -g -Wall -Wreturn-type -Werror -fno-common
  MFLAGS = -arch i486
  OFLAGS = -O
  O3FLAGS= -O3 -march=prescott -fomit-frame-pointer -falign-functions=16 
-funroll-loops
  PGFLAGS= -O3 -march=prescott -falign-functions=16 -funroll-loops
  CCFLAGS=
  LDFLAGS=
  LDLIBS =
  OBJEXT =
  CCFLAGS_O  = -c
  LDFLAGS_O  =
  LDLIBS_O   =
  OBJEXT_O   = .o
  CCFLAGS_SO =
  LDFLAGS_SO = -bundle -flat_namespace -undefined suppress
  LDLIBS_SO  =
  OBJEXT_SO  = .so
  GCDIR  = gc6.7
  SYSARCH= i386
  SYSOS  = darwin
creating boot/Makefile
creating id/Makefile
creating idc/Makefile
creating idc/idc
creating st80/Makefile
cp -p idc/idc boot/.
/bin/sh -ec '( cd boot; make )'
rm -rf include/gc
cp -pr ../gc6.7/include include/gc
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/_object.o.c  -o _object.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/Array.o.c  -o Array.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/ArrayedCollection.o.c  -o 
ArrayedCollection.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/Association.o.c  -o 
Association.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/AVLTree.o.c  -o AVLTree.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/BlockClosure.o.c  -o 
BlockClosure.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/ByteArray.o.c  -o ByteArray.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/Character.o.c  -o Character.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/Collection.o.c  -o 
Collection.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/Dictionary.o.c  -o 
Dictionary.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/Fraction.o.c  -o Fraction.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/Float.o.c  -o Float.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/GetOpt.o.c  -o GetOpt.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/IdentityDictionary.o.c  -o 
IdentityDictionary.o
cc -Iinclude -g -Wall -Wreturn-type -Werror -fno-common -arch i486 -DNDEBUG 
-DSYSARCH=\"i386\" -DSYSOS=\"darwin\"  -O -c  src/IdentitySet.o.c  -o 
IdentitySet.o
cc -Iinclude -g -Wall -Wreturn-type