Yes, I'm aware of it, and watched a demo of it after StrangeLoop. I did not
see that visi:io was suitable for open systems, more like a spreadsheet.
The design reminded me also of tangible values (
http://conal.net/papers/Eros/).
I'm interested in finding out what RDP can do for spreadsheets, i.e.
Are you guys aware of David Pollacks visi:io/visi:pro projects, it seems fairly
similar to what you are describing. He's creating a simple datamodel/process
language with strong type system constraints, that allows individuals to create
domain specific plugins to a cloud processing / local GUI p
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
Distilling what you just said to its essence:
- humans develop miniature dataflows
- search algorithm automatically glues flows together
- search goal is a data type
A potential issue is that humans - both engineers and end-users - will
often want a fair amount of control over which tran
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
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 perhaps
we could c
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
Your idea of "first specifying the model... then adding translations" can
be made simpler and more uniform, btw, if you treat acquiring initial data
(the model) as a "translation" between, say, a URL or query and the result.
If you're interested in modeling computation as continuous synchronizatio
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
Sure, but isn't my wheel rounder :-)
Of course, from my quick peek Linda still seems somewhat code-oriented:
"Linda is a model of coordination and communication among several
parallel processes operating upon objects stored in and retrieved from
shared, virtual, associative memory."
If I buil
On 10/3/2012 2:46 PM, Paul Homer wrote:
I think it's because that's what we've told them to ask for :-)
In truth we can't actually program 'everything', I think that's a
side-effect of Godel's incompleteness theorem. But if you were to take
'everything' as being abstract quantity, the more we
Paul,
This sounds a little like Linda and TupleSpaces... what was that you were
saying about re-inventing the wheel over and over?
LOL...
Alan Moore
On Wed, Oct 3, 2012 at 11:34 AM, Paul Homer wrote:
> A bit long, but ...
>
> The way most people think about programming is that they are wri
I think it's because that's what we've told them to ask for :-)
In truth we can't actually program 'everything', I think that's a side-effect
of Godel's incompleteness theorem. But if you were to take 'everything' as
being abstract quantity, the more we write, the closer our estimation comes to
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
A bit long, but ...
The way most people think about programming is that they are writing 'code'. As
a lessor side-effect, that code is slinging
around data. It grabs it from the user, throws it into memory and then
if it is interesting data, it writes it to disk so that it can be looked at or
On 10/3/2012 9:53 AM, Paul Homer wrote:
"people will clean things up so long as they are sufficiently painful,
but once this is achieved, people no longer care."
The idea I've been itching to try is to go backwards. Right now we use
programmers to assemble larger and larger pieces of software,
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
+1
Aiming the message at children means that we don't need to "trick them, or
force them."
-Carl Gundel
-Original Message-
From: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] On Behalf Of Loup
Vaillant
Sent: Wednesday, October 03, 2012 4:40 AM
To: fonc@vpri.org
Subject: Re: [fon
"people will clean things up so long as they are sufficiently painful, but once
this is achieved, people no longer care."
The idea I've been itching to try is to go backwards. Right now we use
programmers to assemble larger and larger pieces of software, but as time goes
on they get inconsisten
I like a nice Benedict with a mimosa on a Saturday brunch, but lots of my
friends in Seattle think it's gross and/or immoral that I eat chicken eggs
and pig meat (actually I've quit the pig part, so I don't get the Bennie
anymore.) I think kids do need some guidance, but the things they're really
g
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
32 matches
Mail list logo
