Google Summer of Code

Thu Jun 9 17:33:51 PDT 2005

"Faré" wrote:
>
> On 6/7/05, Massimo Dentico <m.dentico at virgilio.it> wrote:
> > Premise: these are genuine questions, I have no intention
> > to begin a flame.
>
> Thank you for helping me make these clarifications

You are welcome. As always, I try to address readers of this
mailing list in general.

> > * Is Common Lisp to be considered the favorite language
> >   to develop in the scope of this project?
> >
> > * On which grounds this has been decided?
>
> No. The TUNES project has no "favorite language",

Ok. This to correct the external perception which neglet
the importance of the meta-traslator sub-project
( http://cliki.tunes.org/TUNES%20Meta-Translator ).

> except maybe Slate, which is the only language made
> with explicitly TUNESy ideas.

IIRC, Brian (Rice) sees it more as an intermediate step
which does not preclude alternatives (see his multi-language
bootstrap idea).

> However, Common Lisp is one of the few languages that both
> stresses Live programming (dynamic program evolution) and
> has non-trivial metaprogramming.

Certainly it is the more advanced and long developed in this
respect, but...

> Though it is by no means perfect in either regard,
> it's still way better than most languages,
> so it makes a good exploratory tool for TUNESy ideas.

... not particularly simple and "clean" (as the original kernel),
with not so orthogonal features. But I don't want to blame
Common Lisp here: it was a compromise which tried to satisfy
various lisp dialects' user bases (see the classic "Critique
of DIN Kernel Lisp Definition", by Henry Baker
http://home.pipeline.com/~hbaker1/CritLisp.html ).

> It is not compulsory for TUNES projects to use Common Lisp,
> and it might not be the best language suited for some such projects.
> But it is a natural pick for proposing coding internships,
> and in this specific case, it was an implicit requirement
> for the Lisp NYC to include these project proposals on their site.

Well, of course it is a requirement for Lisp NYC.

What I don't like about current programming languages in general
(Common Lisp is no exception) is that their inventors usually
ignore the scientific knowledge about human "cognitive" skills.
See the quotes on "Psychology of Programming" Cliki node:

    http://cliki.tunes.org/Psychology%20of%20Programming

> I hereby reiterate my call to participate in this Summer of Code,
> either by coding or by submitting more projects. In either case, be quick.
> http://fare.tunes.org/computing/term-project-proposal.html
>
> Please spread the message around.

Some comments (they were pending in my mind since when you have
published your "Term Project Proposals" document):

2.2 Failover Feature for the Transactional Engine

You wrote: "BKNR has a transactional engine based on the Prevalence
technique, whereby a journal of object modifications and other high-level
system updates is kept. Upon failure or system upgrade, transactions
can then be replayed from the latest system snapshot."

I have already expressed my ideas about this "Prevalence technique",
see "In defense of Prevalence" thread:

    http://lists.tunes.org/archives/tunes/2004-February/thread.html

Apparently, I was not successful in even only instilling some doubts
about the Prevalence approach. Let me try again (repetita juvant,
Latins said).

This rehashing of network (or OO) DBs *without* Management
System (MS) is dumb for both...

1) the "network DB" part: accessing data by "navigation" is more
   difficult and less efficient than accessing them by value (this
   is true for data management as for information retrieval: think
   about navigating the web and searching it with search engines;
   sometimes even on a simple, little site you don't find navigating
   what you are searching for and resort to a local search engine or
   a general search engine with site search feature; the same is true
   for File Systems, where you are lost without the availability of
   a searching tool that search into the *content* of your files);

2) the "*without* MS" part: it put us back to pre-DBMS era, where
   each application dictate its own file format, with difficult or
   impossible sharing of data, NO integrity assurance, etc..
   The fact that with Prevalence you don't manage "files of data"
   in the usual sense is not relevant at all here: you end up in
   exactly the same situation as with the CRAP on our hard disks
   even these days, OLE/COM/DCOM/CORBA, etc.. notwithstanding;
   moreover, pretending that XML is the solution is outrageously
   stupid.

The problem is that for integrity assurance without a DBMS,
the programs that interact with your data need to "understand"
data semantics (meaning). So-called OO "encapsulation" is a way
to assure integrity, but is an error-prone, brittle method (pun
intended) beacuse procedural in nature. Most of the time is from
hard to impossible to check procedurally a complex network of
constraints, because is like to write, on a per program base,
an ad-hoc constraints solver (this has a parallel in GUI programming
with call-backs, which is hard in all but the most simpler cases;
see "Separating Application Code from Toolkits: Eliminating the
Spaghetti of Call-Backs", a paper about Garnet, a Common Lisp UI
toolkit based on a constraints solver: http://cliki.tunes.org/Garnet ).

(Note that imperative OO languages with declarative constraints,
aka Constraint Imperative Programming (CIP) languages, exist;
see the Kaleidoscope family: http://cliki.tunes.org/Kaleidoscope )

The advantage of the relational data model is that it offers a clean,
simple medium to express arbitrary structures, manipulations and
integrity, all in a declarative way. A RDBMS factor out these
concerns (and others, like transaction management) from applications;
for example, you have a quite general and powerful constraints solver
at your disposal (this is not completely true for SQL DBMSs, but
I don't want digress -- see if your favorite SQL DBMS *properly*
support DOMAINs, CHECKs, ASSERTIONs.. but nonetheless, SQL have
inherent problems).

Time and money, *probably* (I have not studied it in depth), are better
spent to advance something like AP5, to remain in Common Lisp land:

    http://cliki.tunes.org/AP5

This also shows that there are alternatives to the "monolith"
(centralized) approach to DBMSs implementation.

2.3 Content-addressed Data Store

I consider this layer at the physical (implementation) level only,
in a framework where logical/physical independence is taken for
granted (so, differently from what you have implicitly suggested
in its application).

I suggest to have a look at VSDB (it claims full ACID semantics,
may be used across distributed filesystems, no locking whatsoever):

    http://repetae.net/john/computer/vsdb/

Note that it is oriented toward constant (or rarely updated) databases,
so is somewhat related to the point below (2.4).

2.4 Epistemic Monotonic Logic

"Epistemic Monotonic Logic" is better known as "Monotonic Epistemic Logic"
(1, yours page, vs 26 results from Google phrase searches).

    http://www.google.com/search?q="Epistemic+Monotonic+Logic"
    http://www.google.com/search?q="Monotonic+Epistemic+Logic"

2.5 Distributed Versioning Software

There is no need to another brainless approach to "software versioning".
It is time to depart from the "source program as text" idea and to see
versioning as a particular case of metaprogramming.

So, I suggest to look at Update Programming

    http://cliki.tunes.org/Update%20Programming

at Feature-Oriented Programming

    http://cliki.tunes.org/Feature-Oriented%20Programming

to "Program Slicing, Differencing, Merging, etc." at the
Wisconsin Program-Slicing Project:

    http://www.cs.wisc.edu/wpis/html/#slicing

and in general to the field "Algebra of Programs":

    http://www.google.com/search?q="Algebra+of+Programs"

although a categorical treatment is not to overlook, see
for example various work at Kestrel Institute:

    http://www.kestrel.edu/

> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> *EULA: By reading or responding to this message you agree that all my stated
> or unstated opinions are correct.* "EULA" -- patent pending.

Regards.

--
Massimo Dentico