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 <[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 > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
