cases
there are ways to migrate 'things' from one side to other (which no doubt has
some deeper ramifications).
Paul.
>
> From: Kurt Stephens
>To: fonc@vpri.org
>Sent: Tuesday, October 30, 2012 2:03:23 PM
>Subject: Re: [fonc]
H.G. Wells once wrote that an one-eyed man happens upon a blind society does
not become its king, for he cannot even function and is thought to be insane.
To me, Mr. Alan Kay is the one-eyed man.
Ivan
On 2012-10-30, at 11:03 AM, Kurt Stephens wrote:
> On 10/3/12 9:53 AM, Paul Homer wrote:
>
On 10/3/12 9:53 AM, Paul Homer wrote:
> If instead, programmers just built little pieces, and it was the
> computer itself that was responsible for assembling it all together into
> mega-systems, then we could reach scales that are unimaginable today. To
> do this of course, the pieces would have
>
> From: David Barbour
>To: Paul Homer ; Fundamentals of New Computing
>
>Sent: Thursday, October 4, 2012 4:12:34 PM
>Subject: Re: [fonc] How it is
>
>
>Don't get too handwavy about performance of the algorithm before you've
&g
currency) are
> encapsulated within the kernel.
> - All of the formatting and domain issues are encapsulated within the
> transformations.
>
> That would make it fairly easy to know where to place or find any of the
> technical or domain issues.
>
>
> Paul.
>
>
_
> From: David Barbour
>To: Paul Homer ; Fundamentals of New Computing
>
>Sent: Wednesday, October 3, 2012 7:10:53 PM
>Subject: Re: [fonc] How it is
>
>
>Distilling what you just said to its essence:
> * humans develop miniature dataflows
>
ther. They can do their thing in small bits and pieces and be as
>> organized or inconsistent as they like. The system comes together from the
>> intelligence embedded in the kernel, but the kernel isn't concerned with
>> what are essentially domain or data issues. It's
the kernel isn't concerned with what are essentially domain or
> data issues. It's all just bits that are on their way from one place to
> another, and translations that are required along the way. Most of the
> code-specific issues like security melt away (you have access
On Thu, Oct 4, 2012 at 1:06 AM, Pascal J. Bourguignon
wrote:
> And who has the resources to do this work: it seems to me to be a big
> endeavour. Collecting the research "prototype" developed during the
> last 50 years, and develop a such a product.
I'm not sure it has to be that big of an effor
that are on
> their way from one place to another, and translations that are required
> along the way. Most of the code-specific issues like security melt away
> (you have access to a context or you don't) mostly because the linkage
> between the user and data is under control of ju
John Nilsson writes:
> I read that post about constraints and kept thinking that it should be
> the infrastructure for the next generation of systems development, not
> art assets :)
>
> In my mind it should be possible to input really fuzzy constraints
> like "It should have a good looking, blog
Paul Homer wrote:
I'm in a slightly different head-space with this idea.
A URL for instance, is essentially an encoded set of instructions for
navigating to somewhere and then if it is a GET, grabbing the
associated data, lets say an image. If my theoretical user where to
create a screen (or
On Wed, Oct 3, 2012 at 2:37 PM, John Nilsson wrote:
> I read that post about constraints and kept thinking that it should be
> the infrastructure for the next generation of systems development, not
> art assets :)
>
Got to start somewhere. The constraint-logic technology could always be
shifted
xt or you don't) mostly because the linkage
between the user and data is under control of just one single (distributed)
program.
Paul.
>____
> From: David Barbour
>To: Paul Homer ; Fundamentals of New Computing
>
>Sent: Wednesday, October 3,
I read that post about constraints and kept thinking that it should be
the infrastructure for the next generation of systems development, not
art assets :)
In my mind it should be possible to input really fuzzy constraints
like "It should have a good looking, blog-like design"
A search engine woul
AI is not necessary for self-organizing systems. You could use a lot of
independent, small constraint solvers to achieve equivalent effect. But
machine learning could make finding solutions very efficient and more
stable. I've been considering such techniques to help replace use of
stateful program
ecombination).
>
> So I'd basically go backwards :-) No higher abstractions and bigger
> pieces, but rather a sea of very little ones. It would be fun to try :-)
>
>
> Paul.
>
> --
> *From:* Loup Vaillant
> *To:* Paul Home
I discuss a similar vision in:
http://awelonblue.wordpress.com/2012/09/12/stone-soup-programming/
My preferred glue is soft stable constraint logics and my reactive
paradigm, RDP. I discuss a particular application of this technique with
regards to game art development:
http://awelonblue.wordpre
should be a rather more tangible subset of a distributed system
(for background work, one could just fake out a virtual user and then throw
away the output).
Paul.
>
> From: Alan Moore
>To: Fundamentals of New Computing
>Sent: Wednesday, October 3,
*From:* Pascal J. Bourguignon
*To:* Paul Homer
*Cc:* Fundamentals of New Computing
*Sent:* Wednesday, October 3, 2012 3:32:34 PM
*Subject:* Re: [fonc] How it is
Paul Homer mailto:paul_ho...@yahoo.ca>> writes:
> The on-going work to enhance the system wo
and recombination).
>
> So I'd basically go backwards :-) No higher abstractions and bigger
> pieces, but rather a sea of very little ones. It would be fun to try :-)
>
>
> Paul.
>
> --
> *From:* Loup Vaillant
> *To:* Paul Homer ; Funda
__
> From: Pascal J. Bourguignon
>To: Paul Homer
>Cc: Fundamentals of New Computing
>Sent: Wednesday, October 3, 2012 3:32:34 PM
>Subject: Re: [fonc] How it is
>
>Paul Homer writes:
>
>> The on-going work to enhance the system would consist
Paul Homer writes:
> The on-going work to enhance the system would consistent of modeling data,
> and creating
> transformations. In comparison to modern software development, these would be
> very little
> pieces, and if they were shared are intrinsically reusable (and
> recombination).
Yes,
On Wed, Oct 3, 2012 at 6:14 PM, Loup Vaillant wrote:
> Miles Fidelman a écrit :
>
>> Loup Vaillant wrote:
>>>
>>> De : Paul Homer
>>>
If instead, programmers just built little pieces, and it was the
computer itself that was responsible for assembling it all together into
mega-syste
gt;To: Paul Homer ; Fundamentals of New Computing
>
>Sent: Wednesday, October 3, 2012 11:10:41 AM
>Subject: Re: [fonc] How it is
>
>De : Paul Homer
>
>> If instead, programmers just built little pieces, and it was the
>> computer itself that was responsible for assembli
still requires "intelligence" to put the pieces
together, and design the various ways in which they may interoperate...
I really don't know if this helps, or is just me going off on a tangent.
Paul.
---
Loup Vaillant wrote:
Miles Fidelman a écrit :
Loup Vaillant wrote:
De : Paul Homer
If instead, programmers just built little pieces, and it was the
computer itself that was responsible for assembling it all together
into
mega-systems, then we could reach scales that are unimaginable today.
Miles Fidelman a écrit :
Loup Vaillant wrote:
De : Paul Homer
If instead, programmers just built little pieces, and it was the
computer itself that was responsible for assembling it all together into
mega-systems, then we could reach scales that are unimaginable today.
[…]
Sounds neat, but
On Oct 3, 2012, at 7:53 AM, Paul Homer wrote:
> If instead, programmers just built little pieces, and it was the computer
> itself that was responsible for assembling it all together into mega-systems,
> then we could reach scales that are unimaginable today. To do this of course,
> the pieces
Loup Vaillant wrote:
De : Paul Homer
If instead, programmers just built little pieces, and it was the
computer itself that was responsible for assembling it all together into
mega-systems, then we could reach scales that are unimaginable today.
[…]
Sounds neat, but I cannot visualize an inst
De : Paul Homer
If instead, programmers just built little pieces, and it was the
computer itself that was responsible for assembling it all together into
mega-systems, then we could reach scales that are unimaginable today.
[…]
Sounds neat, but I cannot visualize an instantiation of this. Me
org
Subject: Re: [fonc] How it is
Pascal J. Bourguignon a écrit :
> The problem is not the sources of the message. It's the receiptors.
Even if it's true, it doesn't help. Unless you see that as an advice to just
give up, that is.
Assuming we _don't_ give up, who can we
slightly different). With that type of man-power
directed, some pretty cool things could be created.
Paul.
>
> From: BGB
>To: fonc@vpri.org
>Sent: Tuesday, October 2, 2012 5:48:14 PM
>Subject: Re: [fonc] How it is
>
>
>On 10/2/201
Ryan Mitchley a écrit :
On 03/10/2012 10:39, Loup Vaillant wrote:
An example of a killer-something might be a Raspberry-Pi shipped with a
self-documented Frank-like image. By self-documented, I mean something
more than emacs. I mean something filled with tutorials about how to
implement, re-i
On 03/10/2012 10:39, Loup Vaillant wrote:
An example of a killer-something might be a Raspberry-Pi shipped with a
self-documented Frank-like image. By self-documented, I mean something
more than emacs. I mean something filled with tutorials about how to
implement, re-implement, and customise e
Loup Vaillant writes:
> Pascal J. Bourguignon a écrit :
>> The problem is not the sources of the message. It's the receiptors.
>
> Even if it's true, it doesn't help. Unless you see that as an advice
> to just give up, that is.
>
> Assuming we _don't_ give up, who can we reach even those that w
Pascal J. Bourguignon a écrit :
The problem is not the sources of the message. It's the receiptors.
Even if it's true, it doesn't help. Unless you see that as an advice
to just give up, that is.
Assuming we _don't_ give up, who can we reach even those that won't
listen? I only have two answ
On 10/2/2012 5:48 PM, Pascal J. Bourguignon wrote:
BGB writes:
On 10/2/2012 12:19 PM, Paul Homer wrote:
It always seems to be that each new generation of programmers goes
straight for the low-hanging fruit, ignoring that most of it has
already been solved many times over. Meanw
BGB writes:
> On 10/2/2012 12:19 PM, Paul Homer wrote:
>
> It always seems to be that each new generation of programmers goes
> straight for the low-hanging fruit, ignoring that most of it has
> already been solved many times over. Meanwhile the real problems
> remain. There has b
Reuben Thomas writes:
> On 2 October 2012 16:21, John Pratt wrote:
>> Basically, Alan Kay is too polite to say what
>> we all know to be the case, which is that things
>> are far inferior to where they could have been
>> if people had listened to what he was saying in the 1970's.
>
> He's also n
ul.
----
*From:* John Pratt
*To:* fonc@vpri.org
*Sent:* Tuesday, October 2, 2012 11:21:59 AM
*Subject:* [fonc] How it is
Basically, Alan Kay is too polite to say what
we all know to be the case, which is tha
On 2 October 2012 16:21, John Pratt wrote:
> Basically, Alan Kay is too polite to say what
> we all know to be the case, which is that things
> are far inferior to where they could have been
> if people had listened to what he was saying in the 1970's.
He's also not very good at dissemination, or
;ve always felt that it was '2
steps forward, 1.99 steps back".
Paul.
>
> From: John Pratt
>To: fonc@vpri.org
>Sent: Tuesday, October 2, 2012 11:21:59 AM
>Subject: [fonc] How it is
>
>Basically, Alan Kay is too polite to say w
Basically, Alan Kay is too polite to say what
we all know to be the case, which is that things
are far inferior to where they could have been
if people had listened to what he was saying in the 1970's.
Inefficient chip architectures, bloated frameworks,
and people don't know at all.
It needs a re
44 matches
Mail list logo
