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 call it a visual context), they'd just drag-and-drop an image-type
into the position they desired. They'd have to have some way of tying that to
'which image', but for simplicity lets just say that they already created
something that allows them to search, and then list all of the images from a
known database context, so that the 'which image' is cascaded down from their
earlier work. Once they 'made the screen live' and searched and selected, the
underlying code would essentially get a request for a data flow that specified
the context (location), some 'type' information (an image) and a
context-specific instance id (as passed in from the search and list). The
kernel would then arrange for that data to be moved from
where-ever it is (local or remote, but lets go with remote) and converted (if
its base format was something the user's screen couldn't handle, say a custom
bitmap). So along the way there might be a translation from one image format to
another, and perhaps a 'compress and decompress' if the source is remote.
That whole flow wouldn't be constructed by a programmer, just the translations,
say bitmap->png, bits->compressed and compressed->bits. The kernel would work
backwards, knowing that it needed an image in png format, and knowing that
there exists base data stored in another context as a bitmap, and knowing that
for large data it is generally cheaper to compress/decompress if the network is
involved. The kernel would essentially know the absolute minimum about the
flow, and thus could algorithmically decide on the optimal amount of work.
For most basic systems, for most data, once the user navigated into something
it's just a matter of shifting the data. I've done an end-run around any of the
processing issues, by jumping dumping them into the kernel. From your list,
scatter-gather, queries and views, etc. are all left up the the translations.
Incremental is just having the model in the context handles updates. ACID is a
property of the context.
I haven't given any real thought to issues like pulls or bi-directional but I
think that the screen would just send a flow back to the original context in an
observer style pattern associated with the raw pre-translated data. If any of
that changed in the context, the screen would redo any 'dirty' flows, but that
might not be a workable approach for millions of users watching the same data.
The crux of this (crazy) idea is really that the full intelligence necessary
for moving the data about and playing with it is highly fragmented. Programmers
don't have to write massive intelligent sets of instructions, they just have to
know how data goes from one format to another. 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 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 to a context 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 <[email protected]>
>To: Paul Homer <[email protected]>; Fundamentals of New Computing
><[email protected]>
>Sent: Wednesday, October 3, 2012 5:27:12 PM
>Subject: Re: [fonc] How it is
>
>
>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 synchronization of
>bidirectional views between data models, you would probably be interested in
>RDP (https://github.com/dmbarbour/Sirea/blob/master/README.md).
>
>
>Though, reuse of data models is necessarily more sophisticated than you are
>imagining. There are many subtle and challenging issues in any conversion
>between data models. I discuss a few such issues here:
>(http://awelonblue.wordpress.com/2011/06/15/data-model-independence/)
>
>
>
>
>
>
>
>
>On Wed, Oct 3, 2012 at 11:34 AM, Paul Homer <[email protected]> wrote:
>
>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
edited later. The code is the primary thing they are creating,
while the data is just a side-effect of using that code.
>>
>>
>>
>>Way back I got introduced to seeing it the other way around. Data is
everything. It's what the user types in, which is moved into some
data-structures in memory and then is eventually restructured for
persistence to be stored for later usage. Data sometimes contains
'static linkages', that is one datam points to another explicitly.
Sometimes the linkages are dynamic. A piece of code has to be run to
make the connection between the data. In this perspective, code is
nothing more than dynamic linkages or transformations between
data-structures/formats (one could see the average of a bunch of floats
for example as a transformation to a more simplified summation of the
original data). The system is really just a massive flow of data, while
the code is just what helps it get from place to place.
>>
>>
>>In the second perspective, an inventory system allows the data to flow
from the users to the persistence medium. Sometimes the users need the
data to flow back to them again, possibly summarized, or just for
re-editing. The core of the system holds very simple data, basically a
series of physical items, each with many associated properties and
probably a bunch of cross-relationships. The underlying types, properties and
relationships form a model of the data. For our modern systems that model might
be implemented as a relational schema, but it could also be more exotic like
NoSQL.
>>
>>
>>
>>In this sort of system, if the model where stored explicitly in the
persistence and it is simple enough that the users could do data entry
directly on a flat representation of it on the screen, then the whole
system would be as simple as flinging the data back and forth between
the disks and the screen. However as we all know, systems are never this
trivial in the real world.
>>
>>
>>
>>Users need to navigate to specific data, and they often want the computer to
fill in any 'global context information' for them as they move around.
As well, they generally enter data in a simplified format, store the
data in another, and then want a third way to view it. All of this
amounts to a series of transformations happening to the data as it flows back
and forth. Some transformations are simple, such as displaying a
floating point number as a string truncated to some level of precision.
Some are very complex, such as displaying a report that cross-checks the
inventory to determine data or real-life problems. But all of the things on
the screen are either directly data, or algorithmic transformations of
the existing data.
>>
>>
>>
>>As for programming, this type of system could be build by first specifying
>>the model. To add to this would be a series of transformations, each
basically a black box that specifies a set of input and a set of output. With
the model and the transformations, someone could lay out a series
of screens for the users (or power users could do it themselves). The
underlying kernel of the system would then take requests for the screens and
use that to work out the flow from or to the database. One could
generalize this a bit further by ignoring any difference between the
screen and the disks, and just thinking of them as a generalized 'context' of
some
type.
>>
>>
>>What I like about this idea is that once someone creates a model, it can be
re-used as is, elsewhere. Gradually industries will build up common models
(with less being secret). And as they add billions of little
transformations, these too can be shared. The kernel (if it it possible
to actually write one :-) only needs to exist once. Then all that
remains is for people to toss screens together as they need them (this
part of programming is likely to never be static). As for performance, once a
flow has been established, it would be possible to store and reuse any
static data or transformation sequences, and that auto-optimization
would only exist in the kernel so it could focus precisely on what
provides the best results.
>>
>>In a grand sense, you can see everything on the screen -- even little rounded
>>corners, images and gadgets -- as just data that has flowed there from the
>>disk somewhere (or network :-). The transformations behind something like a
>>windowing system can appear daunting, but we know that they all started life
>>as data somewhere that moved and bounced through a huge number of different
>>data-structures, until finally ending up as a set of bits toggled in a screen
>>buffer.
>>
>>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).
>>
>>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 <[email protected]>
>>>To: Paul Homer <[email protected]>; Fundamentals of New Computing
>>><[email protected]>
>>>Sent: Wednesday, October 3, 2012 11:10:41 AM
>>>
>>>Subject: Re: [fonc] How it is
>>>
>>>
>>>De : Paul Homer <[email protected]>
>>>
>>>> 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. Meaning,
>>>I have no idea what assembling mechanisms could be used. Could you
>>>sketch a trivial example?
>>>
>>>Loup.
>>>
>>>
>>>
>>>
>>_______________________________________________
>>fonc mailing list
>>[email protected]
>>http://vpri.org/mailman/listinfo/fonc
>>
>>
>
>
>
>--
>bringing s-words to a pen fight
>
>
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
