Re: What databases have taught me

Bruno Desthuilliers wrote:
> Marshall wrote:
> >
> > Certainly Python has an active community and is growing. And I would
> > agree that much of its success comes from good design, and not
> > just the fact that it has a lot of libraries and a solid community.
> > (Although I could critique its halfhearted handling of functional
> > idioms, such as lambda and fold.)
>
> Yes, Python lambdas are really restricted - while still usable and
> useful - and there are few other limitations when compared to a full
> blown FPL (like read-only closures etc). In practice, there's almost
> always another (usually clean and not too complicated) way to achieve
> the same results, so that feeling of arbitrary limitation when coming
> from a real FPL had often more to do with superficial similarities and
> not knowing how to properly do the thing in Python than with a real
> limitation. Well, IMHO at least !-)

No disagreement here. However my personal feeling is that most or all of the functional idioms, and also the Python idioms, including list comprehensions (which was borrowed from Haskell if I'm not mistaken) actually have better counterparts in the relational algebra. I say this not intending to disparage either FP or Python.

> The fact is anyway that there's a clear evolution toward more
> declarative idioms in Python, and a growing support for this (like list
> comprehensions, generalized into generator expressions - now extended
> into full-blown coroutines...). AFAIC, I see the OO/imperative part of
> Python much as toolkit for building higher-level declarative idioms, and
> having a mostly coherent and consistent model (here an object model) is
> of great help for this.

Fair.

> > I'm not sure how much I'd
> > read in to Google's hiring of Guido;
>
> Given that a substantial part of it's job at google is to work on
> Python, I take it as a sure sign that Google intend to strongly support
> the language.

Oh, certainly.

> > though it is true that Python
> > is used at Google, it's used mostly as versatile glue, and not
> > so much for anything performance-sensitive.
>
> Most performance-sensitive parts are in C++. FWIW, I think that one of
> the strength of Python is here : code the hi-level logic (the 'glue')
> with a hi-level language, and the critical parts in a lower level language.
>
> You can read this for more on Google's use of Python:
> http://panela.blog-city.com/python_at_google_greg_stein__sdforum.htm
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/d7ed5b2061c5cc0d/

Hmmm. Well, there were some factual inaccuracies in those references (although the authors are both probably better Python programmers than I.)

> >
> >>But that's only anecdotical, since, may I quote:
> >>"""
> >>we do not limit ourselves, (or sometimes, even concern ourselves)
> >>with what products are out there today
> >>"""
> >
> > Brilliant, heh heh.
> >
>
> Eh... Would have been a shame not to reuse this !-)
>
> >>
> >>>The second point is that while many features of type systems
> >>>are discussed in print, especially the much-misunderstood
> >>>difference between languages that support static analysis,
> >>>and those that do not (sometimes called "dynamically typed"),
> >>
> >>Dumb question: isn't there a third category ? IIRC, in objective-C and
> >>CommonLisp, it's possible to mostly relie on (what's commonly called)
> >>dynamic typing, but yet provide type declarations when desired ?
> >
> >
> > There are a bazillion categories. The optional-declarations category
> > is certainly worth mentioning, but it is independent of nominal vs.
> > structural.
>
> Is it really ? Seems like it mixes both scheme, no ?

Not really. You can have dynamically typed optional-annotation languages (you mentioned Lisp), statically-structurally-optionally annotated languags (Haskell) or statically-nominally-optionally- typed languaes (Scala.)

The dimensions to the typing question a manifold and diverse. I have been studying the subject for many years now and while my taxonomy continues to improve, it is by no means settled.

> > There are also optional-declaration, statically typed
> > languages,
> > such as anything in the type-inference category, of which
> > Hindley-Milner is the most famous kind, and of which SML is
> > an example.
>
> Same as in Haskell and OCaml IIRC ?
>
> Don't bother answering, I'll check by myself...
>
> >>
> >>>there is an issue that gets almost no attention, but which
> >>>I believe is actually quite important: the difference between
> >>>nominal and structural type systems.
> >>>
> >>>Most statically typed languages, and all popular ones, are
> >>>nominally typed, not structurally typed. Essentially what this
> >>>means is that if you have two identical types with different
> >>>names, are they consider the same type ("structural") or
> >>>different types ("nominal.") SQL is structurally typed, and
> >>>furthermore has a product type as its fundamental
> >>>collection. Most "dynamically typed" languages are structural
> >>>rather than nominal, and I believe it is that, and not
> >>><shudder> "duck" typing, that gives them a good bit of
> >>>their interest.
> >>
> >>Globally agree. The main problem with "nominal" static typing IMHO is
> >>the "nominal" part.
> >
> > Yeah. While it's a tradeoff, like everything else, I have to say
> > I think nominal typing might have gotten over-much use. :-)
>
> The "problem" is that AFAICT - please correct me if I'm wrong -
> structural typing can't really garantee semantic correctness. But FWIW,
> nominal typing doesn't either, and arbitrarilly restrict otherwise valid
> constructs.

Well, I suppose it depends on what you mean by semantic correctness. Certainly structural typing introduces the possiblility of "accidental" type compatibility, but I consider this a minor problem. (I never hear SML programmers complain about it, for example.) In contrast, I often hear, ahem :-), Python, Ruby, and Lisp programmers talk about the power of retroactive abstraction (that is, making two types compatible after-the-fact)

> >
> >>>I believe a structurally, statically typed language
>
> If I may ask, is the "statically typed" part here for correctness or for
> performance ?

My chief interest is in correctness, although of course static typing help dramatically with performance. It is also a benefit for documentation
purposes. Nonetheless, dynamically typed (strictly speaking untyped) languages gain expressiveness benefits from the lack of a static type system, so it's a tradeoff, and one that smart people are on different sides of. (Aka, I respect the "opposition" while still knowing
clearly where my interest lies.)

> >>> with a
> >>>product type as its fundamental collection, (along with
> >>>some relational operators) would be *most* interesting.
> >>
> >>Could you elaborate on (of give pointer to) what's "product type" exactly ?
> >
> >
> > I actually didn't say it very well. What I was trying to describe
> > was a set-of-product-types type. (That's what I was trying to
> > get at when I said "collection.")
> >
> > A product type is simply a
> > struct, or in Python terms a tuple. (I can't remember whether
> > Python tuples are ordered or named?)
>
> Python has both tuples (ordered, unnamed) and dicts (named, unordered -
> hashtable really), and easily translates one into the other (but with
> lost of ordering). FWIW, dicts are the "central" datatype in Python,
> used for namespaces, objects and classes.
>
> > A set-of-products is
> > a relation, much like SQL tables.
>
> table = set(dict(id=1, name='toto'),
> dict(id=2, name='titi'),
> dict(id=3,name='tata'))
>
> But this won't cut it... The problem is that unicity is inforced on
> object's identity, which is a "technical" identity, not a "semantic"
> identity. The following would be legal, yet ruin the whole stuff:
>
> table.add(dict(id=1, name='toto'))
>
> FWIW, a *real* integration (*not* embedded SQL) of RM/RA in a general
> purpose, hi-level programming language would really interest me - it's
> something I've been thinking of since 2002, but I really lack the
> theoretical background to go any further... From what I've learned and
> toyed with since, I'd think of a CLOS-like multimethod system eventually
> with predicate-based dispatch. There's some litterature about the
> so-called "OO/relational impedance mismatch" (while I don't see what
> "impedance", which I know of in electronic, has to do here), but MHO is
> that the real mismatch is between SQL/SQL DBMS and general purpose
> programming languages.

A fair point. I remain sceptical about multimethods in particular, but I agree in general. (I wonder: if a language lacks subtyping, and has overloading, is there anything left for multimethods to do? Hmmm.)

> BTW, is there actually any other implementation of RM/RA than SQL DBMS ?

I suppose Rel and Alphora, although I have little experience with either.

Marshal Received on Thu Jun 29 2006 - 18:48:59 CEST