Re: What databases have taught me

From: Bruno Desthuilliers <onurb_at_xiludom.gro>
Date: Thu, 29 Jun 2006 20:17:16 +0200
Message-ID: <44a4192d$0$19173$>

Marshall wrote:
> 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)

You're not. FWIW, I don't think there's anything in Python that doesn't come from another languages, and yet it still manages to feel mostly like an honestly designed language - I mean, not a patchwork.

> actually have better counterparts in the relational algebra.

"better" for which definition ? (NB: please take into account that, apart from a few homework on the subject, most of my experience with application of RM/RA comes from SQL DBMS). FWIW, given my lack of academic education (left school at 16, mostly self-taught in whatever I did in my life), relational and functional both feel very similar to me, mostly because of their strong mathematical formalism. So I obviously miss differences that are certainly obvious for someone more familiar with mathematics.

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

> Hmmm. Well, there were some factual inaccuracies in those references

Care to point them ?

> (although the authors are both probably better Python programmers than
> I.)

Well, Alex Martelli certainly knows what he's talking about, and for what I can say judging on it's contributions to and it's writings, I would not suspect him of dishonesty.


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

chez les papous, il y a les papous poux et les papous pas poux. Mais chez les papous, il y a aussi les papous papa et les papous pas papa. Donc chez les papous, il y a les papous papa poux, les papous papa pas poux, les papous pas papa poux et les papoux pas papa pas poux. Mais chez les poux, il y a aussi les poux papous et les poux pas papous. Donc chez les papoux (etc...)

Sorry, couldn't resist. Talk about combinatorial explosion !-)

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

Yes, I've already understood that typing is a quite complex topic - and with probably at least as much openings for flame wars as in computational model discussions !-)


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

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

> Well, I suppose it depends on what you mean by semantic correctness.

Nothing new I'm afraid.

In structurally typed languages, there's the accidental type compatibility your addressing below. FWIW, I've never had problem with this so far in the past seven years, but there's no way to formally prove that it can happens.

Now in nominally typed languages, the mere fact of declaring a class to implement a given interface does'nt imply it actually implements it correctly - and here it's something I've seen (and done FWIW). Eiffel is AFAIK (ie: correct-me-if-I'm-wrong) the only (or at least the first) language trying to address this problem.

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

FWIW, in Python, I've never seen two types compatible "by accident" !-) But I've seen classes and functions coming from totally unrelated packages seamlessly working together. Like for access restriction, Python doesn't pretend the concern is not valid, but that, since no language-inforced rule has yet proven to be foolproof, it may be simple to rely on programmer's intelligence than to cripple the language. Seems to work so far...


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

I assume you mean "formally provable" correctness ? If so, I think you'd need a way to ensure what I called 'semantic correctness'.

> although of course static typing
> help dramatically with performance.

AFAIC, it's still the main point of static typing. Of course structural static typing makes for lower chances of runtime errors - at least for a given class of possible runtime errors, and AFAICT is better at it than declarative static typing - but it also happens that IME, type errors are not so common in dynamically typed languages - well, at least for those not trying to second guess the developper by silently transtyping anything to anyting else.

> It is also a benefit for
> documentation
> purposes. Nonetheless, dynamically typed (strictly speaking untyped)

Some describe them as having only one type - which could be seen as the same as untyped, granted. Still, with languages like Smalltalk, Python and Ruby, you just can't do whatever with any random object - if an object doesn't understand a message, then you have an error, period. From a practical POV, I still see this as a type system (now wether this really is one or not is a question I'll leave to more knowledgeable persons).

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

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

For which definition of subtyping ? Which implies : for what definition of typing ?-)

> and
> has overloading, is there anything left for multimethods to do? Hmmm.)

Multimethods doesn't necessarily dispatch only on type - there's a multimethods implementation in Python that uses predicate-based dispatch.

Care to elaborate on this ? I wouldn't miss the point.


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

Never heard of these languages. Ok, let's google... and thanks for the pointer.

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 - 20:17:16 CEST

Original text of this message