On 2/27/2012 10:31 AM, David Harris wrote:
Alan ---
I appreciate both you explanation and what you are doing. Of course
jealousy comes into it, because you guys appear to be having a lot of
fun mixed in with your hard work, and I would love to part of that. I
know where I would be breaking down the doors if I was starting a
masters or doctorate. However, I have made my choices, a long time
ago, and so will have live vicariously through your reports. The
constraint system, a la Sketchpad, is a laudable experiment and I
would love to see a hand-constructible DBjr. You seem to be
approaching a much more understandable and malleable system, and
achieving more of the promise of computers as imagined in the sixties
and seventies, rather than what seems to be the more mundane and
opaque conglomerate that is generally the case now.
WRT the "mundane opaque conglomerate":
I sort of had assumed that is how things always were and (presumably)
always would be, just with the assumption that things were becoming more
open due to both the existence of FOSS, and the rising popularity of
scripting languages (Scheme, JavaScript, Python, ...).
like, in contrast to the huge expensive closed systems of the past
(like, the only people who really know how any of it works were the
vendors, and most of this information was kept secret).
I had sort of guessed that the push towards small closed embedded
systems (such as smart-phones) was partly a move to try to
promote/regain vendor control over the platforms (vs the relative
user-freedom present on PCs).
(I don't know if I will ever go for a masters or doctorate though, as I
have been in college long enough just going for an associates' degree,
and would assume trying to find some way to get a job or money or
similar...).
Keep up the excellent work,
David
On Monday, February 27, 2012, Alan Kay <alan.n...@yahoo.com
<mailto:alan.n...@yahoo.com>> wrote:
> Hi Julian
> I should probably comment on this, since it seems that the STEPS
reports haven't made it clear enough.
> STEPS is a "science experiment" not an engineering project.
>
I had personally sort of assumed this, which is why I had thought it
acceptable to mention my own ideas and efforts as well, which would be a
bit more off-topic if the focus were on a single product or piece of
technology (like, say, hanging around on the LLVM or Mono lists, writing
about code-generators or VM technology in general, rather than the topic
being restricted to LLVM or Mono, which is the focus of these lists).
but, there are lots of tradeoffs, say, between "stuff in general" and
pursuit of "trying to get a marketable product put together", so trying
for the latter to some extent impedes the former in my case.
although, I would personally assume everyone decides and acts
independently, in pursuit of whatever is of most benefit to themselves,
and make no claim to have any sort of "absolute" position.
(decided to leave out me going off into philosophy land...).
but, anyways, I tend to prefer the personal freedom to act in ways which
I believe to be in my best interests, rather than being endlessly judged
by others for random development choices (such as choosing to write a
piece of code to do something when "there is a library for that"), like,
if I can easily enough throw together a piece of code to do something,
why should I necessarily subject myself to the hassles of a dependency
on some random 3rd party library, and why do other people feel so
compelled to make derisive comments for such a decision?
and, I would assume likewise for others. like, if it works, who cares?
like, if I write a piece of code, what reason would I have to think this
somehow obligates other people to use it, and what reason do other
people seem to have to believe that I think that it does?
like, what if I just do something, and maybe people might consider using
it if they find it useful, can agree with the license terms, ... ?
and, if in-fact it sucks too hard for anyone else to have much reason to
care, or is ultimately a dead-end, what reason do they have to care?
...
but, I don't think it means I have to keep it all secret either, but I
don't really understand people sometimes... (though, I guess I am
getting kind of burnt out sometimes of people so often being judgmental...).
or, at least, this is how I see things.
> It is not at all about making and distributing an "operating system"
etc., but about trying to investigate the tradeoffs between "problem
oriented languages" that are "highly fitted" to problem spaces vs.
what it takes to design them, learn them, make them, integrate them,
add pragmatics, etc.
> Part of the process is trying many variations in interesting (or
annoying) areas. Some of these have been rather standalone, and some
have had some integration from the start.
> As mentioned in the reports, we made Frank -- tacking together some
of the POLs that were done as satellites -- to try to get a better
handle on what an integration language might be like that is much
better than the current use of Squeak. It has been very helpful to get
something that is evocative of the whole system working in a practical
enough matter to use it (instead of PPT etc) to give talks that
involve dynamic demos. We got some good ideas from this.
>
> But this project is really about following our noses, partly via
getting interested in one facet or another (since there are really too
many for just a few people to cover all of them).
>
yep.
> For example, we've been thinking for some time that the pretty
workable DBjr system that is used for visible things - documents, UI,
etc. -- should be almost constructable by hand if we had a better
constraint system. This would be the third working DBjr made by us ...
>
> And -- this year is the 50th anniversary of Sketchpad, which has
also got us re-thinking about some favorite old topics, etc.
> This has led us to start putting constraint engines into STEPS,
thinking about how to automatically organize various solvers, what
kinds of POLs would be nice to make constraint systems with, UIs for
same, and so forth. Intellectually this is kind of interesting because
there are important overlaps between the "functions + time stamps"
approach of many of our POLs and with constraints and solvers.
> This looks very fruitful at this point!
>
> As you said at the end of your email: this is not an engineering
project, but a series of experiments.
>
> One thought we had about this list is that it might lead others to
conduct similar experiments. Just to pick one example: Reuben Thomas'
thesis "Mite" (ca 2000) has many good ideas that apply here. To quote
from the opening: "Mite is a virtual machine intended to provide fast
language and machine-neutral just-in-time translation of
binary-portable object code into high quality native code, with a
formal foundation." So one interesting project could be to try going
from Nile down to a CPU via Mite. Nile is described in OMeta, so this
could be a graceful transition, etc.
> In any case, we spend most of our time trying to come up with ideas
that might be powerful for systems design and ways to implement them.
We occasionally write a paper or an NSF report. We sometimes put out
code so people can see what we are doing. But what we will put out at
the end of this period will be very different -- especially in the
center -- that what we did for the center last year.
> Cheers and best wishes,
> Alan
>
pretty much.
I guess one can distinguish between ideas and design elements and so on,
and the particular artifacts.
often there is a lot of overlap, but many people seem to either go in
one of several ways:
idealizing the idea, but despising its actual implementations (as
somehow "inferior");
idealizing the artifact, and assuming that everyone who wants to use the
idea *must* use the particular artifact (and that failure to do so
necessarily is some sort of "slippery slope" into non-conformance and
chaos...).
sometimes this goes for particular documents, rather than the
implementation per-se, but it is similarly frustrating (as then one can
have people being judgmental about specific lines and paragraphs of some
or another documents, sometimes leading to long flame-wars mixed with
quotations from the documents in question).
then the "idea" people may go as far as to seemingly despise both
reality and any mention of "implementation details" (or start raving
about "possibilities" which are often solidly in the realm of "absurd").
similarly, they will often only care about an idea so long as it is
"new", which lasts about as long as it takes for someone to actually
implement it and find something useful to do with it, at which point
they no longer care (and would assume just throwing it all away and
chasing after some new idea).
but, I think these things miss the whole point of what roles these sorts
of documents were originally intended to serve (allowing both for
multiple divergent implementations, and also for helping maintain
inter-operation within presumably heterogeneous environments).
but, reality has all of this, being a finely integrated mix of ideas,
artifacts, and details, many of which can be torn apart and rebuilt at
will, without (necessarily) tearing down some or whatever "house of
cards" that reality is assumed to be made out of.
but, as I see it, ideas, standards, and their
artifacts/implementations/... are tools, to be used in what ways they
are useful and relevant to the person making the evaluation (like, what
are the costs, and what are the benefits? ...). like, "here is what
exists, what use can I make of it? how can I use it to some benefit? ...".
or such...
>
> ________________________________
> From: Julian Leviston <jul...@leviston.net <mailto:jul...@leviston.net>>
> To: Fundamentals of New Computing <fonc@vpri.org <mailto:fonc@vpri.org>>
> Sent: Saturday, February 25, 2012 6:48 PM
> Subject: Re: [fonc] Error trying to compile COLA
>
> As I understand it, Frank is an experiment that is an extended
version of DBJr that sits atop lesserphic, which sits atop gezira
which sits atop nile, which sits atop maru all of which which utilise
ometa and the "worlds" idea.
> If you look at the http://vpri.org/html/writings.php page you can
see a pattern of progression that has emerged to the point where Frank
exists. From what I understand, maru is the finalisation of what began
as pepsi and coke. Maru is a simple s-expression language, in the same
way that pepsi and coke were. In fact, it looks to have the same
syntax. Nothing is the layer underneath that is essentially a symbolic
computer - sitting between maru and the actual machine code (sort of
like an LLVM assembler if I've understood it correctly).
> They've hidden Frank in plain sight. He's a patch-together of all
their experiments so far... which I'm sure you could do if you took
the time to understand each of them and had the inclination. They've
been publishing as much as they could all along. The point, though, is
you have to understand each part. It's no good if you don't understand it.
> If you know anything about Alan & VPRI's work, you'd know that their
focus is on getting children this stuff in front as many children as
possible, because they have so much more ability to connect to the
heart of a problem than adults. (Nothing to do with age - talking
about minds, not bodies here). Adults usually get in the way with
their "stuff" - their "knowledge" sits like a kind of a filter,
denying them the ability to see things clearly and directly connect to
them unless they've had special training in relaxing that filter. We
don't know how to be simple and direct any more - not to say that it's
impossible. We need children to teach us meta-stuff, mostly this
direct way of experiencing and looking, and this project's main aim
appears to be to provide them (and us, of course, but not as
importantly) with the tools to do that. Adults will come secondarily -
to the degree they can't embrace new stuff ;-). This is what we need
as an entire populace - to increase our general understanding - to
reach breakthroughs previously not thought possible, and fast. Rather
than changing the world, they're providing the seed for children to
change the world themselves.
> This is only as I understand it from my observation. Don't take it
as gospel or even correct, but maybe you could use it to investigate
the parts of frank a little more and with in-depth openness :) The
entire project is an experiment... and that's why they're not coming
out and saying "hey guys this is the product of our work" - it's not a
linear building process, but an intensively creative process, and most
of that happens within oneself before any results are seen (rather
like boiling a kettle).
> http://www.vpri.org/vp_wiki/index.php/Main_Page
> On the bottom of that page, you'll see a link to the tinlizzie site
that references "experiment" and the URL has dbjr in it... as far as I
understand it, this is as much frank as we've been shown.
> http://tinlizzie.org/dbjr/
> :)
> Julian
> On 26/02/2012, at 9:41 AM, Martin Baldan wrote:
>
> Is that the case? I'm a bit confused. I've read the fascinating
reports about Frank, and I was wondering what's the closest thing one
can download and run right now. Could you guys please clear it up for me?
>
> Best,
>
> Martin
>
> On Sat, Feb 25, 2012 at 5:23 PM, Julian Leviston
<jul...@leviston.net <mailto:jul...@leviston.net>> wrote:
>
> Isn't the cola basically irrelevant now? aren't they using maru
instead? (or rather isn't maru the renamed version of coke?)
>
> Julian
>
>
> On 26/02/2012, at 2:52 AM, Martin Baldan wrote:
>
>> Michael,
>>
>> Thanks for your reply. I'm looking into it.
>>
>> Best,
>>
>> Martin
>> _______________________________________________
>> fonc mailing list
>> fonc@vpri.org <mailto:fonc@vpri.org>
>> http://vpri.org/mailman/listinfo/fonc
>
> _______________________________________________
> fonc m
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
