Re: What databases have taught me

From: Marshall <>
Date: 28 Jun 2006 19:29:27 -0700
Message-ID: <>

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.) I'm not sure how much I'd read in to Google's hiring of Guido; 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.

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

> !-)
> (snip jobs listings)
> >
> > 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. 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.

> (not trying to make a point here)
> > 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. :-)

> > I believe a structurally, statically typed language 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?) A set-of-products is a relation, much like SQL tables.

Marshall Received on Thu Jun 29 2006 - 04:29:27 CEST

Original text of this message