Re: XML: The good, the bad, and the ugly

"Laconic2" <laconic2_at_comcast.net> wrote in message news:yuqdnX9nnbV2ZOncRVn-hA_at_comcast.com...
>
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:WR1dd.418094$Fg5.11784_at_attbi_s53...
>
> > Agreed! The way LISP people respond in newsgroups has
> > been an enormous turn-off for me, and has probably led
> > me to pay less attention to the language than it deserves.
>
> Well, I probably paid less attention to Java than it deserves!

Java is fairly cool. It's maybe not the the most boffo thing even to come down the pike, but it's cool. One thing about Java: we can plot the "uptake curve" of a language as a measure of popular success-- and Java has the steepest, highest uptake curve of any programming language. It rose from nothing to the number two spot for new development in about 5 years, something no other language has ever done. Java deserves attention even if for no other reason than that.

> > > Some variants of Lisp were typed.
> >
> > Really? Like, statically typed? Types were checked at compile time?
>
> I'm not sure just what you mean by "compile time".

It's a fairly standart term; I'm surprised at your unsurety. Let's say "ahead of time." A program is statically typed if you can run it though an analysis phase (which is typically a fast, guaranteed-to-halt process) and *prove* the absense of a certain broad category of errors.

> If you mean the
> conversion of the character based expression of the same language into the
> internal tree representation of the same expressions, that's not generally
> referred to as "compile time".

Uh, it certainly "generally" is. The term is used that way in every textbook I can think of, and in every programming system I've ever used; on every newsgroup and on every discussion board. That may not be universal, but it is certainly "general."

> The LISP people generally called that function the "loader". I'm not sure
> what the formal name was.

Ah, well.

> The loader had to understand types. Literal values in the source code had
> to be converted to objects of the correct type.
> As far as "atoms" goes, the only Lisp variant I knew well enough to comment
> on, didn't do it the way any compiled language would have. The type of an
> atom was "atom". The type of the contents of the atom went with the
> contents, not with the atom.

This is not static analysis. This is a description of an untyped language, or what is popularly called "dynamically typed"-- which is a way of saying type errors are detected at the last possible moment. I consider this a defect in the design, although this issue is by no means settled; there are vocal advocates of dynamic typing, a few of whom I respect.

> Thus an atom could hold a floating point number at one point in time, a
> "relation" at another point in time, and a LISP program at another point in
> time. A process had to be pretty flexible if it was going to cope with
> values of different types.
> They didn't use the term "polymorphic" back in those days, but it certainly
> would have been a useful concept.

Yeah; I dunno. It never seemed to me like the term "polymorphic" could propertly be applied to code that had no static type information, because it couldn't be said to have a "morph" in the first place.

> Did it do type checking at run time? You bet!

This isn't a particularly impressive claim; languages that do not do at least this corrupt data and continue.

> > I'm not sure if XML makes the grade. It's designed for storing data.
>
> I disagree, but I could be wrong.
>
> I guess I'm going to have to read up on what the designers intended.

I'm going to backpedal here a bit, and admit that the original intent of the designers is not ultimately of tremendous importance; the analysis one does in hindsight is generally better.

> Never mind the devotees.
> The devotees usually misconstrue the designers' intent.

Ha ha! How many times has *that* happened!? :-)

> > (Not really for transferring data, as we often say; it's just an inert
> > file format, with nothing transfer-related in its nature.)
>
> Duhhh.... maybe I'm just slow on the uptake here, but what are file
> formats for, if not data transfer???
>
> If the only program that ever reads the file is the same one that wrote it,
> then yeah, sure, it's just storage.
> But as soon as one program writes it and a different program reads it, then
> data transfer is going on, isn't it???

That's a fair point. But still; if one is designing for transfer, one would certainly make *some* attempt at a compact format, no? One wouldn't just blow out tons of lengthy, redundant tags, and use strings to represent everything, would one?

> > XML does actually have one awesome idea in it, which is
> > the idea of the Universal File Format. This one great idea
> > is responsible for 100% of the success of XML, and nothing
> > I say about XML should be construed as saying that that's
> > not Just A Damn Good Idea. But a good idea by itself
> > is not enough; execution matters.
>
> The universal file format is about data communication. It's a damned
> good idea. Literally!
> If you look back in Genesis 11, you'll see that the lack of of a universal
> language was what condemned the execution of what probably was a pretty good
> architectural plan.

Hmmm. This analogy is maybe overbroad. It might be said that a universal file format is what would correspond to a universal grammar, not a universal language. But maybe that's too narrow an analogy.

This is an interesting comparison, and I'll have to think about it some more.

> > Heh heh! Yeah, it bites 'em every time. Only trouble is, they
> > don't know what bit 'em!
>
> The folks back in Genesis 11 never knew what bit them, either!

Fair enough.

Marshall Received on Tue Oct 19 2004 - 17:19:06 CEST