Re: What databases have taught me

From: Bruno Desthuilliers <onurb_at_xiludom.gro>
Date: Thu, 29 Jun 2006 11:36:26 +0200
Message-ID: <44a39f1c$0$13526$>

Marshall wrote:
> Bruno Desthuilliers wrote:

>>Marshall wrote:
>>>erk wrote:
>>>>On the other side of the coin, I'm learning Ocaml and Haskell. I think
>>>>the attention on the dynamically-typed languages is due primarily to
>>>>the problems with the major statically-typed languages; that doesn't
>>>>mean there aren't better statically-typed languages with good type
>>>>inferencing, and I think many strides are still being made on the
>>>>strongly-typed front.
>>>I would like to add a few point to yours.
>>>First of all, while a lot of ink is being consumed discussing ruby and
>>>python, please note that virtually all commercial software activity
>>>is happening with C++ and Java.
>>OTHO, and FWIW, the fact that Guido Van Rossum now works at Google, and
>>that MS is  working on a .NET version of Python are a sure sign that
>>this is not just another cryptic language. We also see more and more
>>Java and C++ programmers on

> 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 !-)

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.

> 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.

> 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:


>>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 ?

> 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.


>>>I believe a structurally, statically typed language

If I may ask, is the "statically typed" part here for correctness or for performance ?

>>> 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'),

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.

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

bruno desthuilliers
python -c "print '_at_'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb_at_xiludom.gro'.split('@')])"
Received on Thu Jun 29 2006 - 11:36:26 CEST

Original text of this message