Re: What databases have taught me
Date: Thu, 29 Jun 2006 11:36:26 +0200
Message-ID: <44a39f1c$0$13526$626a54ce_at_news.free.fr>
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 c.l.py.
>
>
> 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 !-)
> 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: http://panela.blog-city.com/python_at_google_greg_stein__sdforum.htm http://groups.google.com/group/comp.lang.python/browse_thread/thread/d7ed5b2061c5cc0d/
>
>>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.
>>> 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.
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