"Choose the Right Language" in "Tutorial" by Norvig and Pitman
Stefan Schmiedl
I recently read "Tutorial on Good Lisp Programming Style"
by Peter Norvig and Kent Pitman, dated August 10, 1993.
On page 20, there are some areas, which "Lisp is good for".
I have a question concerning the fourth item in this list:
- Single-programmer (or single-digit team) projects
I guess most programming languages are "good for" small teams;
is there something special about Common Lisp which makes it
especially good for small teams?
On page 21, there is a list of things "Current Lisp implementations
are not so good for". As this list is by now almost ten years old,
I would like to get a more recent view from the community. The items
in questions are:
- Persistent storage (data base)
- Maximizing resource use on small machines
- Projects with hundreds of programmers
- Close communication with foreign code
- Delivering small-image applications
- Real-time control (but Gensym did it)
- Projects with inexperienced Lisp programmers
- Some kind of numerical or character computation
(Works fine with careful declarations, but the Lisp
efficiency model is hard to learn.)
I think that the notion of "small machines" has changed a little
bit in the past 10 years, OTOH portable gear might have narrowed
the gap again.
Does anyone know a programming language that is "good for" large
teams working on the same project?
I had some experience with Macintosh Common Lisp (on my
SE/30 in '90) and interfacing to foreign code (on the Mac)
was actually quite easy then.
How important is delivering "small image applications" when you
have native compilers producing stand-alone applications? Do I
have a terminology problem here?
For the next item I can reuse my question from above:
I guess most programming languages are "not so good" for
projects with inexperienced programmers; is there something
special about Common Lisp with makes it especially unsuited for
projects with inexperienced Lisp programmers?
To put things into a nutshell: How much has changed in Common Lisp
and it's surrounding libraries and packages in the last ten years?
Thanks in advance for your responses.
Stefan
Friedrich Dominicus
>
> On page 21, there is a list of things "Current Lisp implementations
> are not so good for". As this list is by now almost ten years old,
> I would like to get a more recent view from the community. The items
> in questions are:
Some work have been done in different areas
>
> - Persistent storage (data base)
Well there exist a couple of libraries for that task.
> - Maximizing resource use on small machines
what was a small machine in 1993? What is a small machine today?
> - Projects with hundreds of programmers
I'm curious myself on answers to that question ;-)
> - Close communication with foreign code
Well as long as the foreign code is C I can't see anything much worse
in Common Lisp or other langauges.
> - Delivering small-image applications
Time has overrolled this. Just see how many space modern development
environments need today.
> - Real-time control (but Gensym did it)
The GC technology has make advances and machines are much faster. I do
not see a fundamental problem with it at the moment.
> - Projects with inexperienced Lisp programmers
This is a bit ridicolous IMHO. Why should it be easier having
inexperiences Lisp programmers than C++ programmer on a C++ project. I
>
> Does anyone know a programming language that is "good for" large
> teams working on the same project?
People have done this in any language. It was said about Eiffel that
it's better suited for medium sized to large programs. But I have used
it for one liners and small programs too.
I do think too that Lisp is quite capable of getting such things
done. In fact if I take into account the Lisp Machines, I would argue
that even large programs have been written in some Lisp.
>
> For the next item I can reuse my question from above:
> I guess most programming languages are "not so good" for
> projects with inexperienced programmers; is there something
> special about Common Lisp with makes it especially unsuited for
> projects with inexperienced Lisp programmers?
I can't see that.
Regards
Friedrich
Christopher C. Stacy
Stefan> - Persistent storage (data base)
Pretty much all Lisp implementations have SQL support,
and there are a number of object-databases as well.
However, there is no real standard for the SQL support.
In JAVA, for example, there is a standard one way to do it.
Stefan> - Maximizing resource use on small machines
I don't know what "resource" or "small machines" mean,
but they may or may not mean the same thing as 10 years ago.
Lisp probably isn't the best language when you are on a tiny embedded
computer, such as a 1 Mhz 8-bit processor with 8 KB of memory,
running your microwave oven or keyboard controller logic.
But if you're on any computer than can run Windows XP or a
modern version of Linux, you'll be just fine.
Stefan> - Projects with hundreds of programmers
I have no idea what this is supposed to mean.
Stefan> - Close communication with foreign code
Isn't it about as easy (or easier) to link Lisp with C, as it is to
link JAVA with C? (Unless you're talking about linking C to C,
which might happen a lot in the world, but which isn't an interesting
question. Or a question at all.)
I don't know whether "FFI" (foreign function interfaces) has improved
a lot in the last 10 years or not, though, so I'm not sure what the
original point was.
Maybe the concern is that in many Lisp systems, Lisp has to be the
master software component, in charge of all memory and interrupts.
This could be considered a problem with the language.
On the other hand, you can call Lisp as a DLL, and there are Lisp
implementations designed for embedding in programs written in other
languages.
Stefan> - Delivering small-image applications
This is no longer really a factor in mainstream computing.
Typical applications in other languages now generate even
larger images than Lisp, and Lisp implementations include
support for generating dynamic link libraries, etc.
Stefan> - Real-time control (but Gensym did it)
The Lisp runtime system is more complicated than for C, and so
whether it will have good real-time performance characteristics
depends on the particular implementation that you're using.
It wouldn't be any worse than JAVA, though, for example.
Also, there have been a number of Lisp implementations
designed specifically for serious real-time uses.
But in C you can generally feel safer about the performance of the runtime.
There is no automatic memory management going on, and if you don't explicitly
call any libraries, chances are that you probably won't be calling any library
or runtime support that would surprise you in some real-time environment.
Stefan> - Projects with inexperienced Lisp programmers
I don't know what this means, either: is it the case that JAVA
and C are better for inexperienced JAVA and C programmers?
Maybe it is just an observation that there is a longer learning
curve for becoming an expert Lisp programmer. But I'm not sure
that this is about the language, per se. It seems more likely
to have to do with libraries and documentation and education.
The main theme that I can detect in most of the above issues,
which may have been what was at issue 10 years ago, is that Lisp
doesn't have as many standardized interfaces for interoperating
with the rest of the world. Nowadays, that also includes things
like the Web and XML, and maybe Message Queue systems, as well as
the previously mentioned areas like network sockets and SQL.
While libraries exist for most of that, they are not a standard
part of the language.
The main competition is now JAVA, which includes a comprehensive set
of interfaces and libraries for everything you might want to do.
JAVA itself is far less powerful than Lisp, harder to write,
probably less efficient, and by most measures a poorer language.
But it serves the mainstream world of problems better than Lisp
because it includes standard ways of doing all the standard things
that one might want to do. JAVA has raised the bar on the features
that a general-purpose real-world language must include, as most of
today's problems are about how to connect standard things together.
JAVA also has direct language support multiprocessing, and library
support for distributed processing (RMI and EJB on top of that).
To the extent that people expect all those things -- standard --
in their programming language, Lisp has fallen behind.
There's a question of strategy and direction to be considered
in trying to guess what will turn out to be important for the
future of Lisp.
Software Scavenger
...
> - Projects with hundreds of programmers
...
The best programming language for a project that size might be an ad
hoc programming language designed for that one project and tightly
focused on it. Common Lisp might be the best foundation for
implementing such an ad hoc programming language.
see.signature
<cubic...@mailandnews.com> wrote:
>...
>> - Projects with hundreds of programmers
>...
Languages like Modula-2 and Ada come to mind, but if they really work??
Todd Gillespie
:>>>>> On 9 Apr 2002 22:34:58 GMT, Stefan Schmiedl ("Stefan") writes:
: Stefan> - Persistent storage (data base)
: Pretty much all Lisp implementations have SQL support,
: and there are a number of object-databases as well.
: However, there is no real standard for the SQL support.
: In JAVA, for example, there is a standard one way to do it.
Poorly, you mean? My life would be much better if the Java parser could
handle string literals longer than one line, or if there was a backquote
operator for easy string interpolation. Of course that would be in
fantasy land, where the Java hordes of the world don't gather torches and
pitchforks when someone says "relational"..
: Stefan> - Projects with hundreds of programmers
: I have no idea what this is supposed to mean.
Exactly what it says: projects doomed to failure.
: Stefan> - Projects with inexperienced Lisp programmers
: I don't know what this means, either: is it the case that JAVA
: and C are better for inexperienced JAVA and C programmers?
: Maybe it is just an observation that there is a longer learning
: curve for becoming an expert Lisp programmer. But I'm not sure
: that this is about the language, per se. It seems more likely
: to have to do with libraries and documentation and education.
Answer 1 is that there is a lot more you can do under the hood of LISP
than under the hood of Java. Java was designed for big teams of people
who don't leave their encapsulation; so the inexperienced can't hurt
themselves as badly.
Answer 2 is given by Richard Gabriel:
"With C, programming is always difficult because the compiler requires so
much description and there are so few data types. In Lisp it is very easy
to write programs that perform very poorly; in C it is almost impossible
to do that."
Answer 3 is still in theory, but I think that LISP programming trains one
away from thinking in the von Neumann style of programming, to thinking
about parse trees and s-exprs. In a sense, LISP programming turns
everyone into linguists. And maybe that's not really welcome by many new
programmers.
Daniel Barlow
> Christopher C. Stacy <cst...@theworld.com> wrote:
> : However, there is no real standard for the SQL support.
> : In JAVA, for example, there is a standard one way to do it.
>
> Poorly, you mean? My life would be much better if the Java parser could
> handle string literals longer than one line, or if there was a backquote
> operator for easy string interpolation. Of course that would be in
Not to mention some subclassing of SQLException so that you could
portably tell the difference between an intermittent network problem
(should be retried) and a SQL syntax error. Yes.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Christopher C. Stacy
Daniel> Todd Gillespie <to...@math.utexas.edu> writes:
>> Christopher C. Stacy <cst...@theworld.com> wrote:
>> : However, there is no real standard for the SQL support.
>> : In JAVA, for example, there is a standard one way to do it.
>>
>> Poorly, you mean? My life would be much better if the Java parser could
>> handle string literals longer than one line, or if there was a backquote
>> operator for easy string interpolation. Of course that would be in
Daniel> Not to mention some subclassing of SQLException so that you could
Daniel> portably tell the difference between an intermittent network problem
Daniel> (should be retried) and a SQL syntax error. Yes.
Sometimes what is more important than the right thing is that there
is a standard way to do something. The answer to the question, "How
do I do databases in JAVA" is simple, while the answer to the same
question for Lisp is very complicated because there is no one answer.
If Lisp included a _standard_ SQL interface that did roughly what JAVA
does (and there's no reason it couldn't be at least a little better
than that), as a least common denominator, in many ways that would be
better than the of different libraries from the Lisp vendors and all
the plethora of random libraries that one could go out shopping for.
Worst of all is the "roll your own" frame of mind, because that only
appeals to a small group of people, and is especially bad when writing
the world's best SQL interface is not supposed to be a subgoal of
solving your problem.
Whether the standard thing is nicely modularized to provide efficient
support for alternative or higher-level interfaces that might be programmed
by the user or purchased as a layered product from somewhere is another
matter. I think that such characteristics would serve the Lisp world
better than saying, "Well, there's nothing really standard, but you could
make one up, or you could use the one that locks you into a Lisp vendor,
or you could go shopping for something even though you don't know how to
evaluate such a thing in the context of Lisp..."
In his century, SQL support is supposed to be standard and included
as part and parcel of the programming language, and not a point of
great discussion or an invitation to do research on the subject.
(Now I'm expecting to hear a response that people who are "too stupid"
to figure out how to write their own or evaluate a package or go do
research on Google or whatever are too dumb to use Lisp...)
Christophe Rhodes
> In his century, SQL support is supposed to be standard and included
> as part and parcel of the programming language, and not a point of
> great discussion or an invitation to do research on the subject.
I don't think that's true. I think this is again an instance/class
confusion; arguably, SQL support should be in a programming language
environment, if there's demand for it -- that's not the same as it
being in the language itself.
If you like, let's change the language a bit, and say "SQL support is
supposed to be standard and included as part and parcel of the
operating system". I hope that people realize that this is not a
sustainable point of view compared with "SQL support is
supposed to be standard and included as part and parcel of the
operating environment"; one is plausible, at least, and one is not.
> (Now I'm expecting to hear a response that people who are "too stupid"
> to figure out how to write their own or evaluate a package or go do
> research on Google or whatever are too dumb to use Lisp...)
I trust that this response prompts a little more thought.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Rahul Jain
> In his century, SQL support is supposed to be standard and included
> as part and parcel of the programming language, and not a point of
> great discussion or an invitation to do research on the subject.
That's an irrelevant point when it comes to CL. There is unlikely to
be any further official standardization done on the language, so CL
will never live up to such a standard (pun intended).
So would you consider all languages besides J2EE to be "backwards"? I
don't know of any other language (besides SQL ;) to have standardized
SQL support. Perl wouldn't count since it has multiple SQL
interfaces. Python might for all I know... Oh wait, PHP! Now that's a
modern language! :)
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Dr. Edmund Weitz
> So would you consider all languages besides J2EE to be "backwards"?
> I don't know of any other language (besides SQL ;) to have
> standardized SQL support. Perl wouldn't count since it has multiple
> SQL interfaces. Python might for all I know...
I think most Perl users would agree that Perl has pretty much
standardized on DBI as its SQL interface. But as Christophe Rhodes
pointed out correctly we're not really talking about a language but
about an implementation here. (The same goes for Python.) Also, DBI is
not part of the core language but it's an additional module available
from CPAN. Judging from what's currently happening with UncommonSQL,
UFFI and USQL we might have something pretty similar in the near
future (with the added value that it would work with a lot of
different implementations).
> Oh wait, PHP! Now that's a modern language! :)
I see your Smiley but let me just add for those not familiar with PHP
that last time I looked PHP's "SQL Interface" was just an incoherent
collection of thin wrappers around the C interfaces of various
database vendors. Far away from something like DBI or JDBC where you
can write code that's pretty much agnostic of the SQL database that'll
be used as its backend (as long as you're not using vendor-specific
enhancements).
[On a personal note: I don't consider this immature hodgepodge called
PHP worth to be called a programming language at all. As far as
consistency and elegance are concerned, it is the worst I've ever
seen. Not to mention a lot of pesky little bugs and the fact that they
introduce significant changes to the "language" with almost every new
minor version. You might deduce from my rant that I'm currently forced
to use PHP as part of a big project from a customer of mine...]
Cheers,
Edi.
--
Dr. Edmund Weitz
Hamburg
Germany
The Common Lisp Cookbook
<http://cl-cookbook.sourceforge.net/>
Julian Stecklina
> Christopher C. Stacy <cst...@theworld.com> wrote:
> :>>>>> On 9 Apr 2002 22:34:58 GMT, Stefan Schmiedl ("Stefan") writes:
>
> : Stefan> - Persistent storage (data base)
>
> : Pretty much all Lisp implementations have SQL support,
> : and there are a number of object-databases as well.
>
> : However, there is no real standard for the SQL support.
> : In JAVA, for example, there is a standard one way to do it.
>
> Poorly, you mean? My life would be much better if the Java parser could
> handle string literals longer than one line, or if there was a backquote
> operator for easy string interpolation. Of course that would be in
> fantasy land, where the Java hordes of the world don't gather torches and
> pitchforks when someone says "relational"..
I don't get that...
> : Stefan> - Projects with hundreds of programmers
>
> : I have no idea what this is supposed to mean.
>
> Exactly what it says: projects doomed to failure.
I'm just reading "The Mythical Man-Month" and some sentences might
suggest that projects with many programmers are somehow doomed in
advance, not to total failure of course.
Regards,
Julian
--
Meine Hompage: http://julian.re6.de
Ich suche eine PCMCIA v1.x type I/II/III Netzwerkkarte.
Ich biete als Tauschobjekt eine v2 100MBit Karte in OVP.
Chris Beggy
> In his century, SQL support is supposed to be standard and included
> as part and parcel of the programming language, and not a point of
> great discussion or an invitation to do research on the subject.
>
> (Now I'm expecting to hear a response that people who are "too stupid"
> to figure out how to write their own or evaluate a package or go do
> research on Google or whatever are too dumb to use Lisp...)
Not from me. Thanks for saying what needs to be said. It looks
like uffi and clsql (descended from uncommonSql) will fill this
need. Kawa using java classes may be another approach.
Chris
Paolo Amoroso
wrote:
> In his century, SQL support is supposed to be standard and included
> as part and parcel of the programming language, and not a point of
> great discussion or an invitation to do research on the subject.
Well, there are users who still discuss even core language features such as
conditionals and array access...
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Todd Gillespie
: Todd Gillespie <to...@math.utexas.edu> writes:
:> Christopher C. Stacy <cst...@theworld.com> wrote:
:> : and there are a number of object-databases as well.
:>
:> : However, there is no real standard for the SQL support.
:> : In JAVA, for example, there is a standard one way to do it.
:>
:> Poorly, you mean? My life would be much better if the Java parser could
:> handle string literals longer than one line, or if there was a backquote
:> operator for easy string interpolation. Of course that would be in
:> fantasy land, where the Java hordes of the world don't gather torches and
:> pitchforks when someone says "relational"..
: I don't get that...
The last bit? It's a whine about how Java's poor interoperation with SQL
databases has driven an explosion in the "object database" market, which
are being sold primarily on grounds of simple interfacing with Java. My
problem with OODBs is that they are a giant step backwards from
relational, or even SQL, databases -- in theoretic underpinnings, OODBs
are restricted network model databases, and in some cases hierachical
DBs. It's CODASYS all over again!
I dread what may happen in the industry if that trend grows. It'll be
1960's techniques once again -- designing your datastore in lockstep with
your application, having to rewrite both when needs change. I'm not too
fond of repeating technical mistakes made before I was even alive.
Chris Beggy
> The last bit? It's a whine about how Java's poor interoperation with SQL
> databases has driven an explosion in the "object database" market, which
> are being sold primarily on grounds of simple interfacing with Java. My
> problem with OODBs is that they are a giant step backwards from
> relational, or even SQL, databases -- in theoretic underpinnings, OODBs
> are restricted network model databases, and in some cases hierachical
> DBs. It's CODASYS all over again!
Who's selling the OODBs? All I know are
Oracle8,db2,sybase, etc....relational AFAIK.
Chris
Fernando Rodríguez
objectivity, matisse, and the defunct (?) itasca, for example.
-----------------------
Fernando Rodriguez
Christopher C. Stacy
Fernando> On Thu, 11 Apr 2002 14:47:05 -0400, Chris Beggy <chr...@kippona.com> wrote:
>> Todd Gillespie <to...@linux128.ma.utexas.edu> writes:
>>
>>> The last bit? It's a whine about how Java's poor interoperation with SQL
>>> databases has driven an explosion in the "object database" market, which
>>> are being sold primarily on grounds of simple interfacing with Java. My
>>> problem with OODBs is that they are a giant step backwards from
>>> relational, or even SQL, databases -- in theoretic underpinnings, OODBs
>>> are restricted network model databases, and in some cases hierachical
>>> DBs. It's CODASYS all over again!
>>
>> Who's selling the OODBs? All I know are
>> Oracle8,db2,sybase, etc....relational AFAIK.
Fernando> objectivity, matisse, and the defunct (?) itasca, for example.
What percentage of servers in the world use these technologies?
I like object databases, but except for the tiny little market
penetration of ODI (last time I looked was 4 years ago),
basically nobody was using object databases.
Fernando Rodríguez
wrote:
> >> Who's selling the OODBs? All I know are
> >> Oracle8,db2,sybase, etc....relational AFAIK.
>
> Fernando> objectivity, matisse, and the defunct (?) itasca, for example.
>
>What percentage of servers in the world use these technologies?
>
>I like object databases, but except for the tiny little market
>penetration of ODI (last time I looked was 4 years ago),
>basically nobody was using object databases.
If you consider Caché a oodb, then they do have a decent market share,
especially in hospitals.
-----------------------
Fernando Rodriguez
Kenny Tilton
Todd Gillespie wrote:
>
> ...Java's poor interoperation with SQL
> databases has driven an explosion in the "object database" market, which
> are being sold primarily on grounds of simple interfacing with Java.
"Interfacing"? That is an odd way to say the relational model is too
primitive to express OO, while ODB is simply OO made persistent. No
"interface" is going to cure RDB's incompatibility with OO, it's just
going to knock performance to its knees.
> My problem with OODBs is that they are a giant step backwards from
> relational
Nah, ODB is a superset of RDB.
> designing your datastore in lockstep with
> your application,
to a degree, yes. but if one likes OO, ODB only makes sense. And RDB
looks like a dinosaur.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Harvey has overcome not only time and space but any objections."
Elwood P. Dowd
Erik Naggum
| That is an odd way to say the relational model is too primitive to
| express OO
Huh? Are you sure you understand the relational model, and not just the
various implementations of it, such as SQL?
| No "interface" is going to cure RDB's incompatibility with OO, it's just
| going to knock performance to its knees.
This makes zero sense.
| [...] if one likes OO, ODB only makes sense. And RDB looks like a
| dinosaur.
Actually understanding the relational model seems to require really long
time and serious effort from some people, since it is both exceedingly
elegant and considerably counter-intuitive. Relational algebra and
calculus are somehow hard. The theory underlying object-orientation is
also elegant and counter-intuitive, despite what some people who have not
quite grasped it think. Obbject-orientation is mostly hype and very
little understanding and the way people think syntax like object.method
is both necessary and sufficient is downright depressing.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
Rahul Jain
> * Kenny Tilton
> | That is an odd way to say the relational model is too primitive to
> | express OO
> Huh? Are you sure you understand the relational model, and not just the
> various implementations of it, such as SQL?
In any relational model I've seen, identity is deep (which is the same
as shallow) structural identity.
> | No "interface" is going to cure RDB's incompatibility with OO, it's just
> | going to knock performance to its knees.
> This makes zero sense.
Then what else is the "serial" type in SQL for? And then remember that
there's no GC, so you can't "clean up" unreferenced tuples. Such a
thing doesn't make sense in the relational model.
> | [...] if one likes OO, ODB only makes sense. And RDB looks like a
> | dinosaur.
> Actually understanding the relational model seems to require really long
> time and serious effort from some people, since it is both exceedingly
> elegant and considerably counter-intuitive. Relational algebra and
> calculus are somehow hard. The theory underlying object-orientation is
> also elegant and counter-intuitive, despite what some people who have not
> quite grasped it think. Obbject-orientation is mostly hype and very
> little understanding and the way people think syntax like object.method
> is both necessary and sufficient is downright depressing.
What does that have to do with the fact that the relational model
cares nothing for object identity?
Note that Kenny's point here is that object-orientation is not a
subset of the relational model, as was asserted. In fact, a relational
system shouldn't be hard to implement in a good object-oriented
system. For performance, it might be helpful to have a scheme whereby
arrays can be allocated to have memory-page size for implementing the
B+-trees, but other than that, there's no significant implementation
problems that I can think of.
Kenny Tilton
Oh, gosh, no, theory is way out of my league. But after a two week class
in <ta-dummm> The Relational Model I successfully designed an RDB schema
for a tricky for-ex system, a schema which never needed revision during
the subsequent fourteen months of development before successfully going
into production.
Gee, imagine how much better I could have done if I had Understood the
Relational Model!!!!!!!
>
> > Actually understanding the relational model seems to require really long
> > time and serious effort ...Relational algebra and
> > calculus are somehow hard.
I am so glad I did not know that before successfully building an
RDB-based system!! I might not have been able to do it if I had known
how unqualified I was!!!!! All I ever really had down cold was third
abnormal form.
Overall, I agree we should mysticize good system design as much as
possible with FUD about abstract models and calculus so as to maximize
our God-like positioning and discourage mere mortals from thinking they
can get by with clear thinking. If they ever find out clear thinking
suffices to produce solid design, us mumbo-jumbos will be on the beach.
Erik Naggum
> Huh? Are you sure you understand the relational model...
* Kenny Tilton
| Gee, imagine how much better I could have done if I had Understood the
| Relational Model!!!!!!!
Sounds like you are not at all sure and have very little clue, too.
| I am so glad I did not know that before successfully building an
| RDB-based system!! I might not have been able to do it if I had known
| how unqualified I was!!!!! All I ever really had down cold was third
| abnormal form.
Dude, what are you smoking? There is not a _single_ field in computer
science that is less understood by its practitioners than databases.
When you imply that being able to use a tool is equivalent to grasping
the theory, you position yourself with the drooling idiots who design
broken databases or things that work by accident. And telling me a story
about something you have done in some sort of retarded self-defense only
tells me that you have no clue what the question is, either. Who cares
what you _say_ you have done when you provide contraindications to having
clues elsewhere?
| Overall, I agree we should mysticize good system design as much as
| possible with FUD about abstract models and calculus so as to maximize
| our God-like positioning and discourage mere mortals from thinking they
| can get by with clear thinking. If they ever find out clear thinking
| suffices to produce solid design, us mumbo-jumbos will be on the beach.
So you have no understanding of the theory at all. Glad to know.
Stop defending yourself by attempting to ridicule someone who has good
reason to think you are clueless. Just provide evidence that you have
clues. This should not be hard if you have any. In fact, if you had any
clues, you would have found it much more productive to provide evidence
thereof than to post the bullshit you just did. Thanks for playing.
cr88192
> The last bit? It's a whine about how Java's poor interoperation with SQL
> databases has driven an explosion in the "object database" market, which
> are being sold primarily on grounds of simple interfacing with Java. My
> problem with OODBs is that they are a giant step backwards from
> relational, or even SQL, databases -- in theoretic underpinnings, OODBs
> are restricted network model databases, and in some cases hierachical
> DBs. It's CODASYS all over again!
>
> I dread what may happen in the industry if that trend grows. It'll be
> 1960's techniques once again -- designing your datastore in lockstep with
> your application, having to rewrite both when needs change. I'm not too
> fond of repeating technical mistakes made before I was even alive.
>
really whether they are "lockstep" depends on how the odb is implemented.
personally I don't like either model (I was once a supporter of the
relational model, but since not as much...).
what I don't really like about odbs I have looked at anyways is that they
seem to use "hard" references to data (ie: the oid), whereas I think a
strong point of the relational model is "soft" references.
I would not like to change something any then go and change everything that
references it, or make a minor change and have to make more major changes
elsewhere to compensate.
if anyone cares I came up with an idea that I consider a hybrid (but not
like the nutorious o-rdbs).
main highlights: it still refers to things with relations (actually more
with "predicates"), it supports variable structures (a weak I consider of
the relational model). it uses a prototyping object system (actually my
version of a prototyping object system). other more misc stuff.
ok, this description sucks.
I had wrote down elsewhere how I thought it would work, but unless someone
cares I wont bother to go get it. it probably sucks anyways, not like I am
certified to answer on any cs related topics anyways.
Kenny Tilton
As if! I wrote and meant:
KT> Oh, gosh, no, theory is way out of my league.
Theory is a crutch for too-smart folks who cannot hear the problem
describing its own solution. The noise of their own intellects deafens
them.
Just kidding, I wish I was smart enough to follow the deeper comp sci
stuff, but I am not. The point of what I wrote is that I think it says
something pretty deep about theory that I am too dumb to understand it
but do great without it.
My theory is that theory is cool, but better answers come from listening
to the problem.
Kenny Tilton
"Christopher C. Stacy" wrote:
> I like object databases, but except for the tiny little market
> penetration of ODI (last time I looked was 4 years ago),
> basically nobody was using object databases.
Well, the penetration of pure ODB is not much changed, but XML could be
the killer app for ODB. Native XML systems like XIS from Excelon (ne
ODI) kicks RDB's theoretical butt. Oracle is dusting off their ODB
project (started when ODB gave them a brief scare, tabled when ODB fell
by the wayside) to support native XML
re pure ODB: We are using AStore atop ObjectStore, having a ball with
it.
Versant is another ODB vendor offering stuff for Java.
Erik Naggum
| My theory is that theory is cool, but better answers come from listening
| to the problem.
The theory is the result of listening to the problem. When the theory
acquires a life of its own because some people like it more than the real
world, all kinds of uninspiring, uninteresting things happen, so the key
is _both_ to listen to the problem and to study the theory. But always
remember that just as much theory is bunk as there are buggy solutions.
There is nothing more wrong with "theory" than "solutions" -- both their
quality and their applicability are orthogonal to their existence.
Christopher Browne
>> The last bit? It's a whine about how Java's poor interoperation
>> with SQL databases has driven an explosion in the "object database"
>> market, which are being sold primarily on grounds of simple
>> interfacing with Java. My problem with OODBs is that they are a
>> giant step backwards from relational, or even SQL, databases -- in
>> theoretic underpinnings, OODBs are restricted network model
>> databases, and in some cases hierachical DBs. It's CODASYS all
>> over again!
>>
>> I dread what may happen in the industry if that trend grows. It'll
>> be 1960's techniques once again -- designing your datastore in
>> lockstep with your application, having to rewrite both when needs
>> change. I'm not too fond of repeating technical mistakes made
>> before I was even alive.
> I can see your point. really whether they are "lockstep" depends on
> how the odb is implemented.
Most typically, "OODB" systems provide a not-at-all-veiled scheme for
allowing C++ or Java objects to be treated as "persistent."
Immediately upon choosing "OODB," that means that you have chosen to
use a particular language, and have to _start_ the process by defining
the base data-storing C++/Java classes.
If that's not a "lockstep" process, I don't know what is.
SQL/RDBMS at least has the merit of being separate enough from any
specific programming language that code and data don't merge
_completely_ invisibly.
It's ugly in different ways.
CORBA is another useful thing to look at, despite not being a data
_storage_ system; it's a characteristic scheme for _communications_
that immediately points to the same sorts of issues.
Another endpoint there would be to consider that the original
implementation of M$ COM was essentially a light serialization of M$
Visual C++ objects; it was somewhat convenient for communicating
between "components," assuming that all code would be written using
Visual C++.
CORBA is pretty ugly because you're always having to do work to push
arguments into the CORBA marshalling scheme; that's ugly more or less
the same way that SQL is. COM was "nicer," assuming that you're happy
with living with One True Language, and in _starting_ by tying down
how data gets moved around to however VC++ "marshalls" it given its
druthers.
More recent COM releases have moved towards being more like CORBA;
other schemes like SOAP may use XML underneath but are otherwise much
the same, requiring doing a bunch of work to transform "local" data
into some "marshalled" form.
Stepping back to Lisp...
On the one hand, Lisp ought to be a somewhat nicer language to do
CORBA-like stuff with, what with having a bit more reflectivity than
C/C++/Java. That bodes well for "playing well" with SQL RDBMSes.
You're still suffering from the need to do a lot of "marshalling;" no
real way around that problem.
On the other hand, you could build a nice "OODB" system atop Lisp,
too; it would be equally likely suffer from roughly the same problems
as the other OODB systems, unfortunately.
In a sense, there's not a _fundamental_ difference betwixt Lisp and
its competitors here...
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.ntlug.org/~cbbrowne/nonrdbms.html
As of next Wednesday, CLU will be flushed in favor of SNOBOL.
Please update your programs.
cr88192
> The world rejoiced as cr88192 <cr8...@hotmail.com> wrote:
>>> The last bit? It's a whine about how Java's poor interoperation
>>> with SQL databases has driven an explosion in the "object database"
>>> market, which are being sold primarily on grounds of simple
>>> interfacing with Java. My problem with OODBs is that they are a
>>> giant step backwards from relational, or even SQL, databases -- in
>>> theoretic underpinnings, OODBs are restricted network model
>>> databases, and in some cases hierachical DBs. It's CODASYS all
>>> over again!
>>>
>>> I dread what may happen in the industry if that trend grows. It'll
>>> be 1960's techniques once again -- designing your datastore in
>>> lockstep with your application, having to rewrite both when needs
>>> change. I'm not too fond of repeating technical mistakes made
>>> before I was even alive.
>
>> I can see your point. really whether they are "lockstep" depends on
>> how the odb is implemented.
>
> Most typically, "OODB" systems provide a not-at-all-veiled scheme for
> allowing C++ or Java objects to be treated as "persistent."
>
> Immediately upon choosing "OODB," that means that you have chosen to
> use a particular language, and have to _start_ the process by defining
> the base data-storing C++/Java classes.
>
> If that's not a "lockstep" process, I don't know what is.
>
sorry for not knowing about oodbs, I didn't know they were *that* kludgy, I
had figured that they just defined a "general" object format and used that.
> SQL/RDBMS at least has the merit of being separate enough from any
> specific programming language that code and data don't merge
> _completely_ invisibly.
>
> It's ugly in different ways.
>
well, and the fact that data is referenced by queries, and not "hard"
references...
still ugly.
> CORBA is another useful thing to look at, despite not being a data
> _storage_ system; it's a characteristic scheme for _communications_
> that immediately points to the same sorts of issues.
>
> Another endpoint there would be to consider that the original
> implementation of M$ COM was essentially a light serialization of M$
> Visual C++ objects; it was somewhat convenient for communicating
> between "components," assuming that all code would be written using
> Visual C++.
>
> CORBA is pretty ugly because you're always having to do work to push
> arguments into the CORBA marshalling scheme; that's ugly more or less
> the same way that SQL is. COM was "nicer," assuming that you're happy
> with living with One True Language, and in _starting_ by tying down
> how data gets moved around to however VC++ "marshalls" it given its
> druthers.
>
> More recent COM releases have moved towards being more like CORBA;
> other schemes like SOAP may use XML underneath but are otherwise much
> the same, requiring doing a bunch of work to transform "local" data
> into some "marshalled" form.
>
I don't think either is really good myself, I think I before mailed my
oppinion to someone about a "better" distributed system, as in my mind
rpc-ish mechanisms are crappy...
> Stepping back to Lisp...
>
> On the one hand, Lisp ought to be a somewhat nicer language to do
> CORBA-like stuff with, what with having a bit more reflectivity than
> C/C++/Java. That bodes well for "playing well" with SQL RDBMSes.
> You're still suffering from the need to do a lot of "marshalling;" no
> real way around that problem.
>
> On the other hand, you could build a nice "OODB" system atop Lisp,
> too; it would be equally likely suffer from roughly the same problems
> as the other OODB systems, unfortunately.
>
> In a sense, there's not a _fundamental_ difference betwixt Lisp and
> its competitors here...
I could use "my" model, as I think it is reasonably general.
I will not describe it now on account of this keyboard (dvorak is numbing
my head...).
ok fixed, felt penned qwerty letters on top of keys and changed back to
qwerty layout for now. seems my mind is fubarred for now...
Kenny Tilton
Christopher Browne wrote:
> Immediately upon choosing "OODB," that means that you have chosen to
> use a particular language, and have to _start_ the process by defining
> the base data-storing C++/Java classes.
I am puzzled. I start my projects anyway by deciding on a particular
language and designing the DB schema whether I am using RDB, ODB, or
ISAM. Where's the problem?
>
> If that's not a "lockstep" process, I don't know what is.
>
If I choose Lisp and a CLOS ODB, I can change my schema while the app is
running. If that is lockstep, I do not know what is not. If I choose a
native XML database, I can go after the data with any number of
languages.
But one thing is certain: RDB cannot directly store OO-based data,
meaning an OO app has to transform the data to read or write it. That
alone proves RDB is Deeply Wrong. It had its day, but it just does not
scale semantically.
Mark Dalgarno
> But one thing is certain: RDB cannot directly store OO-based data,
> meaning an OO app has to transform the data to read or write it. That
> alone proves RDB is Deeply Wrong. It had its day, but it just does not
> scale semantically.
"Relational Databases considered harmful" at
http://linux.rice.edu/~rahul/hbaker/letters/CACM-RelationalDatabases.html
covered similar ground 11 years ago.
Mark
Todd Gillespie
: Well, the penetration of pure ODB is not much changed, but XML could be
: the killer app for ODB. Native XML systems like XIS from Excelon (ne
: ODI) kicks RDB's theoretical butt. Oracle is dusting off their ODB
: project (started when ODB gave them a brief scare, tabled when ODB fell
: by the wayside) to support native XML
Native XML is of stunningly little use. The 'theory' behind it is back in
1960's hierachical databases, although after a few more years you might
get to the point of '70s network databases, but I doubt it.
Of course, 'XML' is now an umbrella term for a dizzying array of
ever-bifurcating standards and proposals, so saying a database is 'native
XML' doesn't tell me anything except that I'm in trouble. Concurrent to
this, XML is changing fast enough to doom any projects I write with a
'native XML' DB to being rewritten every couple years.
Problem 3 is that 'get next record' in a relational DB means 'add the
offset to this pointer and read from the memmap'ed file'; with 'native
XML' that means 'break out the parser, rip through a few megs of text, and
build a tree to walk through'. Good news for hardware manufacturers, not
so good news for me.
Todd Gillespie
:> My problem with OODBs is that they are a giant step backwards from
:> relational
: Nah, ODB is a superset of RDB.
Prove it. I'm entirely open to the idea.
:> designing your datastore in lockstep with
:> your application,
: to a degree, yes. but if one likes OO, ODB only makes sense. And RDB
: looks like a dinosaur.
If you are designing a single-user backend to a single application, then
yes, OODBs are an excellent solution to persisting data in the same format
your single application will use it in.
If, on the other hand, you are planning on running a large datasource to
several programs written in different languages, with many users using in
simultaneously, then a normalized relational database with a common
language-independent query form like SQL may be more of what you need to
allow interoperation and avoid corruption.
You might want to rely less on how things look, and more how they operate
under strain.
Todd Gillespie
: if anyone cares I came up with an idea that I consider a hybrid (but not
: main highlights: it still refers to things with relations (actually more
: with "predicates"),
: it supports variable structures (a weak I consider of
: the relational model).
That's not a failure of the relational model, it's the failure of SQL
databases as currently implemented. Postgres is working out some of the
issues with 'domains', as objects are called in RDBMS-land; but most
vendors haven't exposed enough functionality to allow users to define new
object types and derive all the comparison functions you need to use them
conditionally in queries.
: it uses a prototyping object system (actually my
: version of a prototyping object system).
What do you mean by that?
: other more misc stuff.
Bijan Parsia
> cr88192 <cr8...@hotmail.com> wrote:
[snip]
> : it uses a prototyping object system (actually my
> : version of a prototyping object system).
>
> What do you mean by that?
[snip]
My guess: the person meant a "prototype" based object system, a la Self,
Newtonscript, or Javascript. To wit, there are no classes (rather, an
object isn't primarily an instance of a class). The primary mechanism for
creating objects is clone rather than new (and instantiation).
There's a lot of neat things you can do with prototype object systems, and
for a lot of tasks they're *very* nice to use.
Cheers,
Bijan Parsia.
Rahul Jain
> Kenny Tilton <kti...@nyc.rr.com> wrote:
> :> My problem with OODBs is that they are a giant step backwards from
> :> relational
>
> : Nah, ODB is a superset of RDB.
>
> Prove it. I'm entirely open to the idea.
You can write a relational engine using an object system. QED.
Really all you need to write is a B+-tree implementation where the
OODBMS guarantees that the nodes are memory page (or disk block)
sized. Actually, some OODBMSes come with indicies already. The hardest
part would probably be writing the language interface for the
relational operators.
Todd Gillespie
: Todd Gillespie <to...@linux128.ma.utexas.edu> writes:
: You can write a relational engine using an object system. QED.
: Really all you need to write is a B+-tree implementation where the
: OODBMS guarantees that the nodes are memory page (or disk block)
: sized. Actually, some OODBMSes come with indicies already. The hardest
: part would probably be writing the language interface for the
: relational operators.
In that case, the proof would lie in actually writing said code.
Rahul Jain
> Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:
> : Todd Gillespie <to...@linux128.ma.utexas.edu> writes:
> :> Prove it. I'm entirely open to the idea.
>
> : You can write a relational engine using an object system. QED.
>
> In that case, the proof would lie in actually writing said code.
Good, that's the trivial part (since someone else already did it).
Look at any RDBMS. Now express the data structures it uses as "true"
objects (feel free to use a custom metaclass :).
cr88192
> On Mon, 15 Apr 2002, Todd Gillespie wrote:
>
>> cr88192 <cr8...@hotmail.com> wrote:
> [snip]
>> : it uses a prototyping object system (actually my
>> : version of a prototyping object system).
>>
>> What do you mean by that?
> [snip]
>
> My guess: the person meant a "prototype" based object system, a la Self,
> Newtonscript, or Javascript. To wit, there are no classes (rather, an
> object isn't primarily an instance of a class). The primary mechanism for
> creating objects is clone rather than new (and instantiation).
>
yep, this is what I meant.
sorry if I messed up the terms (but as far as I know both are correct...).
I would just call it a prototyping object system except that some details I
consider my own (as initially I had thought it up and discovered later that
it allready existed). my design involves "specific"/"inspecific" objects,
which have slightly different behaviors (though it could probably get along
without the difference, but I figure the difference will make things a
little easier to optimize...).
I will describe my general idea for my objects as applied to a db:
inspecific objects can not be modified;
objects (specific) may be placed in sets;
the structure of objects in a set is restriced by compatibility objects
(inspecific) or predicates;
inversly the compatibility objects/predicates are to hold for all objects
in a set;
objects in a set are referred to by their fields or by keys (not written:
or on compatibility with a query predicate);
soft references will consist of a set reference and a query predicate;
sets may be placed in other sets however the parent set may restrict if it
may contain sets (and the structure of the sets);
sets will be considered objects;
hard references may be disallowed for interobject references.
worth noting: objects are considered as residing in sets, but not part of
the sets; inversly, fields in objects are considered parts of the objects.
from what little I have read I think my design will be a little different
than self (I have not looked at newtonscript or javascript).
at some point I will have to write down how I imagine the object system.
if anyone knows more about what I am talking about than I do then tips
might be helpfull...
Kenny Tilton
Todd Gillespie wrote:
> Native XML is of stunningly little use.
Chya. I guess that is why Oracle is in such a panic to declare they do
native XML. (Don't tell me I have to go find the link to ORCL for you.)
> Of course, 'XML' is now an umbrella term for a dizzying array of
> ever-bifurcating standards and proposals
oh shit, don't tell me there is a new technology which might be going
thru some polishing!!! run way! run away!!!...the difference between an
adventure and a disaster is the attitude you take into it
> Concurrent to
> this, XML is changing fast enough to doom any projects I write with a
> 'native XML' DB to being rewritten every couple years.
your projects--if they cannot be ported from RDB or XML to ISAM or GKW
in a week--get thrown out anyway every couple of years.
>
> Problem 3 is that 'get next record' in a relational DB means 'add the
> offset to this pointer and read from the memmap'ed file';
chya. so you have RDB code at great expense creating the /illusion/ of
"add the offset". This is a terribly intellectually dishonest assertion.
apologize to c.l.l. imediately. (doing my best erik imitation.)
> with 'native
> XML' that means 'break out the parser, rip through a few megs of text, and
> build a tree to walk through'.
ok, thx for clarifying that you know nothing about native XML. (DMBEI)
> Good news for hardware manufacturers, not
> so good news for me.
uh, aside from the fact that you are wrong, the hardware folks are
upping their performance so fast that not even Moore's law can keep up.
How /you/ doin'?
based on what I have heard, RDb is an excuse for two ignorances:
(1) I do not know what language to use. (answer: duhhhhhhh, lisp!!!)
(2) I do not know what index I will want tomorrow at 3PM (answer: don't
quit your day job.)
Frode Vatvedt Fjeld
> You can write a relational engine using an object system. QED.
By the same argument, for example Basic is a superset of Common
Lisp. I don't know if that means anything.
--
Frode Vatvedt Fjeld
Bijan Parsia
> Bijan Parsia wrote:
>
[snip]
> > My guess: the person meant a "prototype" based object system, a la Self,
> > Newtonscript, or Javascript. To wit, there are no classes (rather, an
> > object isn't primarily an instance of a class). The primary mechanism for
> > creating objects is clone rather than new (and instantiation).
> >
> yep, this is what I meant.
> sorry if I messed up the terms (but as far as I know both are correct...).
[snip]
FWIW, I don't recall *ever* seeing "prototyping object system" before, and
I've read the Self papers, programming Newtons, and studied Javascript (to
my dismay). So, even if "correct", "prototyping" is nonstandard, or,
at least, likely to provoke some confusion.
Plus, you lose symatry with "class based object system". And there's a
problem that a class based object system can be a "prototyping" object
system for a fairly natural reading of the phrase (i.e., Smalltalk may be
a prototyping object system (ick) because it supports, like Lisp, rapid,
flexible prototyping of applications).
Cheers,
Bijan Parsia.
Kenny Tilton
as well try to settle multiple vs single inheritance.
Todd Gillespie wrote:
>
> Kenny Tilton <kti...@nyc.rr.com> wrote:
> :> My problem with OODBs is that they are a giant step backwards from
> :> relational
>
> : Nah, ODB is a superset of RDB.
>
> Prove it. I'm entirely open to the idea.
I can do rows 'n columns in ODB, I cannot do inheritance in RDB.
> If, on the other hand, you are planning on running a large datasource to
> several programs written in different languages, with many users using in
> simultaneously,
true, true, but I do not think that gets to ODB vs RDB, that is an
accident of where the technologies happen to stand today.
I like ODB precisely for its tight linking to the language; it takes the
whole DB thang and says, look, we're just making instances persistent.
To a degree the DB is transparent. That makes development easier, and
nothing is more important. Hardware is cheap, performance can be dealt
with later (as a rule--not agreeing ODBs are slower).
Todd Gillespie
: Todd Gillespie wrote:
:> Native XML is of stunningly little use.
: Chya. I guess that is why Oracle is in such a panic to declare they do
: native XML. (Don't tell me I have to go find the link to ORCL for you.)
You can find all the links you want. I guess that would really impress
me, since I've been using Oracle's XML Java stored procs to pull XML out
of Oracle since 1999.
It's also fairly absurd to try to use "this big company is doing
something" as a definitive data point in favor of 'something'. Big
Companies have lots and lots of engineers; they can run lots and lots of
projects concurrently. This lets them use projects for marketing
purposes, but you are a fool if you think that everything else they are
doing just got shelved in favor of the one thing they sold you on.
XML is a structed application interchange format. It is not an
intra-application storage format -- apps will always specialize their
backends.
:> Of course, 'XML' is now an umbrella term for a dizzying array of
:> ever-bifurcating standards and proposals
: oh shit, don't tell me there is a new technology which might be going
: thru some polishing!!! run way! run away!!!...the difference between an
: adventure and a disaster is the attitude you take into it
And yet, that isn't a unmitigated win. So it's hard to argue with fervor
in favor of a tool used where it is inappropriate just on the grounds of
"maybe it will get better in another decade".
: your projects--if they cannot be ported from RDB or XML to ISAM or GKW
: in a week--get thrown out anyway every couple of years.
I can't figure out if this is a silly ad hominum or just poor grammar.
Maybe it's the viewpoint of someone used to very small projects.
:> Problem 3 is that 'get next record' in a relational DB means 'add the
:> offset to this pointer and read from the memmap'ed file';
: chya. so you have RDB code at great expense creating the /illusion/ of
: "add the offset". This is a terribly intellectually dishonest assertion.
If you leave fantasyland and learn to think in disk blocks, operations,
and memory allocation, you'll change your mind.
:> with 'native
:> XML' that means 'break out the parser, rip through a few megs of text, and
:> build a tree to walk through'.
: ok, thx for clarifying that you know nothing about native XML. (DMBEI)
Once again, you brush aside a valid point with an ad hominum attack. Will
you ever bring content to the table?
:> Good news for hardware manufacturers, not
:> so good news for me.
: uh, aside from the fact that you are wrong, the hardware folks are
: upping their performance so fast that not even Moore's law can keep up.
: How /you/ doin'?
My hardware is fine, thank you. But I still like to support as many users
per processer as I can. If you support bloat, more power to you. By the
way, which platform are you on? I need to buy some stock.
: based on what I have heard, RDb is an excuse for two ignorances:
: (1) I do not know what language to use. (answer: duhhhhhhh, lisp!!!)
: (2) I do not know what index I will want tomorrow at 3PM (answer: don't
: quit your day job.)
You sir, are trolling. Next thread, please, nothing to see here.
Erik Naggum
> Of course, 'XML' is now an umbrella term for a dizzying array of
> ever-bifurcating standards and proposals
* Kenny Tilton
| oh shit, don't tell me there is a new technology which might be going
| thru some polishing!!! run way! run away!!!...the difference between an
| adventure and a disaster is the attitude you take into it
Would you mind trying to act a bit more intelligent?
| chya. so you have RDB code at great expense creating the /illusion/ of
| "add the offset". This is a terribly intellectually dishonest assertion.
| apologize to c.l.l. imediately. (doing my best erik imitation.)
Try imitating something within your reach, first, like a dog.
| uh, aside from the fact that you are wrong, the hardware folks are upping
| their performance so fast that not even Moore's law can keep up.
Are you sure you have figured out what Moore's law says?
| How /you/ doin'?
Less slang, more intelligibility, please.
| based on what I have heard, RDb is an excuse for two ignorances:
|
| (1) I do not know what language to use. (answer: duhhhhhhh, lisp!!!)
|
| (2) I do not know what index I will want tomorrow at 3PM (answer: don't
| quit your day job.)
So you _have_ no clue. I hate it when people confirm my suspicions.
People who think object-orientation is so great, have generally failed to
grasp the value of data-driven designs despite the serious attempt at
making such design easier to model, and think solely in terms of code-
driven designs where their class hierarchies are poor adaptations to
their incompetent coding styles. This is extremely depressing, as the
interminable "software crisis" is a result of code-driven design. SGML
and XML were attempts at promoting data-driven design that would produce
data that was _supposedly_ indepedent of any application. The result is
that people who have so little clue they should have attracted one simply
by the sucking power of vacuum do code-driven designs in XML, which is
_really_ retarded, and then they need to store their moronically designed
data in databases, which is, of course, too hard given their braindamaged
designs, so the relational model does not "work" for them.
Kenny Tilton
What about the new XMLType in 9i? I saw this InfoWorld story:
http://www.infoworld.com/articles/hn/xml/01/11/30/011130hnoraclexdb.xml
<start>
"Oracle to boost XML, Web services support
By Mark Leon and Tom Sullivan
November 30, 2001 6:18 am PT
ORACLE SAYS IT will raise the bar in XML database and Web services
support next week at the Oracle OpenWorld conference in San Francisco.
The buzz surrounds Oracle's XDB project that the company reports will
utilize the object database functions it built in the mid-90s that allow
users to store XML as an object and index the tags, then stored it in a
compressed table.
...
As for the advantages of XDB, Burton explained that XML documents are
stored "natively" but will not require special treatment. "You can use
SQL, and don't need to master the new XML query languages like XQuery,"
Burton said.
"The object technology that makes this possible was a hammer looking for
a nail," Burton said, "and XML is suddenly the biggest nail on the
planet. If XML had not come along, you could argue that a lot of our
object development efforts were wasted effort."
"With XDB," Burton continued, "the overhead of managing XML, parsing for
example, largely disappears."
<end>
Agreed, Oracle is not the oracle on anything, but I think it's a fun
data point. The article actually goes on quite a bit more, mentioning
IBM, Tamino and XML Global (native XML). No mention of Excelon, tho.
> XML is a structed application interchange format. It is not an
> intra-application storage format -- apps will always specialize their
> backends.
I am toying with porting our Franz AllegroStore "intra-app storage" to
XIS (made by Excelon ne ODI). Both AStore and XIS sit on top of
Excelon's ObjectStore.
Did your group look at XIS at all? The 9i XMLType? Of the latter, at
http://oracle.oreilly.com/news/oracleessential_0701.html they say:
"XMLType eliminates the need to parse the documents coming into and out
of the database."
David Golden
The sad thing about XML is that it's a pretty trivial uglification of lisp
sexps. Sure, they approached the problem space from a different direction,
but, as usual, they've reinvented-the-wheel, poorly.
"Oooh no, lisp has too many parentheses, let's represent our
pretty-bog-standard tree structures with incredibly verbose syntax
featuring redundant* close tags and angle brackets everywhere... I think
that's much better than parens, don't you?"
"No."
*XML's nesting rules mean that any well-formed xml fragment does not
overlap tags (no <x>hello <y>there</x>, world</y>). Thus, using XML gains
you essentially nothing over just using sexps for the same data (unless
you're stuck talking to M$'s or other sundry XML-weenies' systems). While
it may sometimes look/feel like you're marking up a stream of text when you
use XML, you're not, really XML is just building humdrum tree structures.
(if XML were a proper markup language, you'd be able to overlap tags and
all sorts of things - markup should notionally be a layer of "highlighter
pen" on top of the text stream - the XMLers started forgetting that, and
thinking their tags were more important than the text, and manage, through
the woeful DOM, to thoroughly mix up their "markup" (ha!) and text...).
So, XML is an annoying way of writing down data structures that lispers
have been dealing with (usually much more sensibly) since time immemorial.
That's why the average lisp programmer, confronted with XML,
tends to think "this seems a bit silly", even if he can't put his finger on
why.
In may 10 or 20 years time, the Java and XML crowd will probably have
reinvented most of Lisp, badly...
broken-record-mode:
See http://ssax.sourceforge.net for a nice XML-to-scheme specification.
--
Don't eat yellow snow.
Dan Andreatta
news:501v8.3767$04.1...@news.iol.ie:
>
> In may 10 or 20 years time, the Java and XML crowd will probably have
> reinvented most of Lisp, badly...
You mean that XML will evolve to
<SETQ> X <LAMBDA> <ARG>A B</ARG> <PLUS>A B</PLUS> </LAMBDA> </SETQ>
Wow, I can't wait :-/
Rahul Jain
That would mean that a CL interpreter written in Basic would operate
similarly (in terms of performance) to a native compiler, and that the
native compiler couldn't have a Basic interpreter that operated
similarly (in terms of performance). So that analogy doesn't make much
sense.
Relational DBMSes do lookup by _search_, not by reference. The engine
inside the RDBMS does lookup by reference to implement the lookup by
search. An object-oriented system does lookup by reference as well.
cr88192
> On Mon, 15 Apr 2002, cr88192 wrote:
>
>> Bijan Parsia wrote:
>>
> [snip]
>> > My guess: the person meant a "prototype" based object system, a la
>> > Self, Newtonscript, or Javascript. To wit, there are no classes
>> > (rather, an object isn't primarily an instance of a class). The primary
>> > mechanism for creating objects is clone rather than new (and
>> > instantiation).
>> >
>> yep, this is what I meant.
>> sorry if I messed up the terms (but as far as I know both are
>> correct...).
> [snip]
>
> FWIW, I don't recall *ever* seeing "prototyping object system" before, and
> I've read the Self papers, programming Newtons, and studied Javascript (to
> my dismay). So, even if "correct", "prototyping" is nonstandard, or,
> at least, likely to provoke some confusion.
>
sorry, I am not really good with terms sometimes... just I had thought I
had seen "prototyping" used but on review I see I was mistaken.
so I guess "prototype object system" or "prototype object model" is correct.
please don't think I don't know what I am talking about. I try not to be
ignorant...
Marc Battyani
"Dan Andreatta" <andr...@mail.chem.sc.edu.REMOVEME> wrote
> David Golden <qnivq....@bprnaserr.arg> wrote
>
> > In may 10 or 20 years time, the Java and XML crowd will probably have
> > reinvented most of Lisp, badly...
>
> You mean that XML will evolve to
>
> <SETQ> X <LAMBDA> <ARG>A B</ARG> <PLUS>A B</PLUS> </LAMBDA> </SETQ>
>
> Wow, I can't wait :-/
So be happy. They already have done it! It's called XEXPR
Look at http://www.w3.org/TR/xexpr/
Here is a nice extract from it.
Recursion
An XEXPR interpreter is not guaranteed to be safely tail recursive, even
though recursion is allowed. As such, it is generally better to use an
iterative form rather than a tail recursive form.
The following defines the linear recursive form of factorial. This is simple
to code, and easy to understand, but for large numbers, it may cause a stack
overflow.
<define name="factorial" args="x">
<if>
<lt><x/>2</lt>
<x/>
<multiply>
<x/>
<factorial><subtract><x/>1</subtract></factorial>
</multiply>
</if>
</define>
Brilliant no ?
Marc
Frode Vatvedt Fjeld
> Relational DBMSes do lookup by _search_, not by reference. The
> engine inside the RDBMS does lookup by reference to implement the
> lookup by search. An object-oriented system does lookup by reference
> as well.
I don't think this means very much either. Whether a relational query
for a tuple, identified by its primary key, is looked up by "search"
or "reference" is purely a matter of how you chose to look at
things. The SQL syntax very much invites you to look at it as a
search, but that's a feature of the SQL syntax and should not be
confused with the relational model per se.
--
Frode Vatvedt Fjeld
Joe Marshall
"Marc Battyani" <Marc.B...@fractalconcept.com> wrote in message
news:69ED16CD1B28F430.13E870C4...@lp.airnews.net...
>
> [Excerpted from http://www.w3.org/TR/xexpr/]
>
> <define name="factorial" args="x">
> <if>
> <lt><x/>2</lt>
> <x/>
> <multiply>
> <x/>
> <factorial><subtract><x/>1</subtract></factorial>
> </multiply>
> </if>
> </define>
>
> Brilliant no ?
No.
Dan Andreatta
> </multiply>
> </if>
> </define>
>
> Brilliant no ?
>
Yep. Great example of mental masturbation.
Dan
Gareth McCaughan
[Marc Battanyi quoted a sample of "XEXPR" code:]
> > </multiply>
> > </if>
> > </define>
> >
> > Brilliant no ?
> >
> Yep. Great example of mental masturbation.
Correct me if I'm wrong here, but isn't masturbation
supposed to be *pleasant*? On the other hand, I can
see how reading too much XEXPR code might make you go
blind.
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Michael Livshin
> Dan Andreatta wrote:
>
> [Marc Battanyi quoted a sample of "XEXPR" code:]
> > > </multiply>
> > > </if>
> > > </define>
> > >
> > > Brilliant no ?
> > >
> > Yep. Great example of mental masturbation.
>
> Correct me if I'm wrong here, but isn't masturbation supposed to be
> *pleasant*?
don't masochists masturbate?
> On the other hand, I can see how reading too much XEXPR code might
> make you go blind.
:)))
seriously, I do wonder about something here. I seem to recall the
claim that XML was not supposed to be read or written by humans at
all. in light of this, XEXPR seems to be simply a joke.
--
The whole idea of modules is so separatist, anyway. Can't we all just
get along? -- Jim Blandy
Steven H. Rogers, Ph.D.
>
> seriously, I do wonder about something here. I seem to recall the
> claim that XML was not supposed to be read or written by humans at
> all. in light of this, XEXPR seems to be simply a joke.
>
XML is supposed to be human readable, but mostly as a debugging aid.
Under normal circumstances XML should be generated and processed by
machines.
Steve
--
"A language that doesn't affect the way you think about programming is
not worth knowing." - Alan Perlis
Johan Kullstam
> Christopher Browne wrote:
> > Immediately upon choosing "OODB," that means that you have chosen to
> > use a particular language, and have to _start_ the process by defining
> > the base data-storing C++/Java classes.
>
> I am puzzled. I start my projects anyway by deciding on a particular
> language and designing the DB schema whether I am using RDB, ODB, or
> ISAM. Where's the problem?
>
> >
> > If that's not a "lockstep" process, I don't know what is.
> >
>
> If I choose Lisp and a CLOS ODB, I can change my schema while the app is
> running. If that is lockstep, I do not know what is not. If I choose a
> native XML database, I can go after the data with any number of
> languages.
>
> But one thing is certain: RDB cannot directly store OO-based data,
> meaning an OO app has to transform the data to read or write it. That
> alone proves RDB is Deeply Wrong. It had its day, but it just does not
> scale semantically.
i don't know. it could equally well be used to show that OO is a
deeply wrong thing. the problem of reading and writing objects is not
limited to databases alone.
--
Johan KULLSTAM
Rahul Jain
> I don't think this means very much either. Whether a relational query
> for a tuple, identified by its primary key, is looked up by "search"
> or "reference" is purely a matter of how you chose to look at
> things.
That would imply that RDBMSes had a 'virtual memory' of all the
possible primary keys and looked up values directly in that array. I
don't see how that's at all practical given the relational model.
Joe Marshall
"Gareth McCaughan" <Gareth.M...@pobox.com> wrote in message
news:slrnabs0kp.1kfm....@g.local...
> Dan Andreatta wrote:
>
> [Marc Battanyi quoted a sample of "XEXPR" code:]
> > > </multiply>
> > > </if>
> > > </define>
> > >
> > > Brilliant no ?
> > >
> > Yep. Great example of mental masturbation.
>
> Correct me if I'm wrong here, but isn't masturbation
> supposed to be *pleasant*?
It's also called `self-abuse', which I think is much
more applicable here.
Erik Naggum
| Here is a nice extract from it.
|
| Recursion
| An XEXPR interpreter is not guaranteed to be safely tail recursive, even
| though recursion is allowed. As such, it is generally better to use an
| iterative form rather than a tail recursive form.
| The following defines the linear recursive form of factorial. This is simple
| to code, and easy to understand, but for large numbers, it may cause a stack
| overflow.
| <define name="factorial" args="x">
| <if>
| <lt><x/>2</lt>
| <x/>
| <multiply>
| <x/>
| <factorial><subtract><x/>1</subtract></factorial>
| </multiply>
| </if>
| </define>
|
| Brilliant no ?
Let me recast this into my syntax, which also considers whitespace no
evil:
<define <name factorial> <args x>
<if <lt x 2>
<x>
<multiply <x> <factorial <subtract <x> 1>>>>>
Now, let me remove the tremendously stupid reference to X via an element
and call simple arithmetic functions by reasonable names:
<define <name factorial> <args x>
<if <lt x 2>
x
<* x <factorial <- x 1>>>>>
Not so bad, I think. But the massive stupidity of XML's redundant
end-tags should be ever more evident. Sigh. Like, I receive this
HTML-ified newsletter every Friday, and each message is from 24K to 32K
large. I rewrote it into my syntax, preserving all the HTML crap, but
removing all the redundant whitespace. The results were from 6K to 9K
large. Then I sanitized the table crap and made it into macro forms and
removed the redundant font elements, and the results were from 3K to 5K.
It is quite fascinating that people are willing to work with data formats
that are 8 times more verbose than they trivially need to be, requiring 8
times more network bandwidth or time to send out newsletters by mail. Of
course, these are the same people who think XML is better than shipping
Word documents around. I just wait to see a Word-in-XML document that
takes a minute to ship over megabit-lines and which says "Hello, world!".
Frode Vatvedt Fjeld
>
>> I don't think this means very much either. Whether a relational query
>> for a tuple, identified by its primary key, is looked up by "search"
>> or "reference" is purely a matter of how you chose to look at
>> things.
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
> That would imply that RDBMSes had a 'virtual memory' of all the
> possible primary keys and looked up values directly in that array. I
> don't see how that's at all practical given the relational model.
It seems to me you must have a pretty particular definition of "by
reference", but even so I believe a standard RDBMS primary index comes
quite close to this description.
--
Frode Vatvedt Fjeld
Marc Battyani
"Erik Naggum" <er...@naggum.net> wrote
> <define <name factorial> <args x>
> <if <lt x 2>
> x
> <* x <factorial <- x 1>>>>>
>
> Not so bad, I think. But the massive stupidity of XML's redundant
> end-tags should be ever more evident.
What internal representation do you use with this ?
> Sigh. Like, I receive this
> HTML-ified newsletter every Friday, and each message is from 24K to 32K
> large. I rewrote it into my syntax, preserving all the HTML crap, but
> removing all the redundant whitespace. The results were from 6K to 9K
> large. Then I sanitized the table crap and made it into macro forms and
> removed the redundant font elements, and the results were from 3K to 5K.
> It is quite fascinating that people are willing to work with data
formats
> that are 8 times more verbose than they trivially need to be, requiring
8
> times more network bandwidth or time to send out newsletters by mail.
Of
> course, these are the same people who think XML is better than shipping
> Word documents around. I just wait to see a Word-in-XML document that
> takes a minute to ship over megabit-lines and which says "Hello,
world!".
FYI an "hello world!" in HTML from Word is 1798 bytes...
Marc
Erik Naggum
| What internal representation do you use with this?
Whatever the application needs. This is much easier to parse into the
braindamaged excuses for internal representation that XML needs than XML.
If the application is sufficiently ill-designed, I stuff a filter between
the sensible syntax and the application which produces the XML it likes.
As for processing with Common Lisp, I simply uses trees built from cons
cells, but contained in an XML object that causes a different printer to
be used than the regular Common Lisp printer, and which may convert the
internal form to something more suitable when needed. I try to avoid the
_immensely_ braindamaged DOM crap.
* Erik Naggum
> I just wait to see a Word-in-XML document that takes a minute to ship
> over megabit-lines and which says "Hello, world!".
* Marc Battyani
| FYI an "hello world!" in HTML from Word is 1798 bytes...
I hope someone else got the point that "Hello, world!" programs are used
to compare programming languages for size, including their binaries, and
that it is sort of the smallest idiotic program anyone writes in order to
acquire completely useless metrics. In other words: a joke.
Rahul Jain
Would you expect an RDBMS index to be a dense vector? I'd hope no
implementation is crazy enough to do that. People already think Oracle
is bloated. :)
Gareth McCaughan
> Gareth.M...@pobox.com (Gareth McCaughan) writes:
>
> > Dan Andreatta wrote:
> >
> > [Marc Battanyi quoted a sample of "XEXPR" code:]
> > > > </multiply>
> > > > </if>
> > > > </define>
> > > >
> > > > Brilliant no ?
> > > >
> > > Yep. Great example of mental masturbation.
> >
> > Correct me if I'm wrong here, but isn't masturbation supposed to be
> > *pleasant*?
>
> don't masochists masturbate?
Good point: I suppose people who get a kick out of pain
might enjoy this sort of thing. Which reminds me of something
I saw ages ago on the WikiWikiWeb:
All [programming] languages tie you up and beat you.
However, if an environment suits your particular kink
then it feels good to you. You may not even notice that
there's anything kinky going on. It's only somoene else's
kinky language that makes you say "do *what*?".
-- Wayne Conrad
> seriously, I do wonder about something here. I seem to recall the
> claim that XML was not supposed to be read or written by humans at
> all. in light of this, XEXPR seems to be simply a joke.
I'm fairly sure it isn't, unfortunately.
Thomas Stegen
> Dan Andreatta wrote:
>
> [Marc Battanyi quoted a sample of "XEXPR" code:]
>
>>> </multiply>
>>> </if>
>>></define>
>>>
>>>Brilliant no ?
>>>
>>>
>>Yep. Great example of mental masturbation.
>>
>
> Correct me if I'm wrong here, but isn't masturbation
> supposed to be *pleasant*? On the other hand, I can
> see how reading too much XEXPR code might make you go
> blind.
>
Everytime you masturbate God kills a kitten.
I think this is a case of you killing a kitten...
--
Thomas
Rob Warnock
+---------------...
| <define name="factorial" args="x">
| <if>
| <lt><x/>2</lt>
| <x/>
| <multiply>
| <x/>
| <factorial><subtract><x/>1</subtract></factorial>
| </multiply>
| </if>
| </define>
|
| Brilliant no ?
No. They were so intent on showing how clever they were with the syntax
that they got the definition of this simple function *wrong*!! ;-} ;-}
[Hint: The consequent should be a certain numeric constant, not "<x/>".]
-Rob
-----
Rob Warnock, 30-3-510 <rp...@sgi.com>
SGI Network Engineering <http://reality.sgiweb.org/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]
Bruce Hoult
rp...@rigden.engr.sgi.com (Rob Warnock) wrote:
> Marc Battyani <Marc.B...@fractalconcept.com> wrote:
> +---------------
> | So be happy. They already have done it! It's called XEXPR
> | Look at http://www.w3.org/TR/xexpr/
> ...
> | <define name="factorial" args="x">
> | <if>
> | <lt><x/>2</lt>
> | <x/>
> | <multiply>
> | <x/>
> | <factorial><subtract><x/>1</subtract></factorial>
> | </multiply>
> | </if>
> | </define>
> |
> | Brilliant no ?
> +---------------
>
> No. They were so intent on showing how clever they were with the syntax
> that they got the definition of this simple function *wrong*!! ;-} ;-}
>
> [Hint: The consequent should be a certain numeric constant, not "<x/>".]
No, it's fine. In fact, they could have increased the 2 to 3 (or
changed the lt to le).
-- Bruce
Rob Warnock
+---------------
Uh... I don't *think* so! Isn't "0!" *defined* to be "1"?!?
The above code incorrectly calculates 0! --> 0.
Note that the interative version (using an internal define) given
further down the referenced page gets it right, using "1" as the
base case for the value of "<product/>".
Erik Naggum
| No, it's fine. In fact, they could have increased the 2 to 3 (or
| changed the lt to le).
Would you do me the favor of looking up the defined value of 0! and
perhaps reconsidering your position?
Good catch, Rob! And you actually read the code. +1 in stamina.
Bruce Hoult
rp...@rigden.engr.sgi.com (Rob Warnock) wrote:
> Uh... I don't *think* so! Isn't "0!" *defined* to be "1"?!?
> The above code incorrectly calculates 0! --> 0.
oops .. you're right. Forgot zero. Or confused with fib, where you can
return x for x < 2.
-- Bruce
Bruce Hoult
wrote:
> * Bruce Hoult
> | No, it's fine. In fact, they could have increased the 2 to 3 (or
> | changed the lt to le).
>
> Would you do me the favor of looking up the defined value of 0! and
> perhaps reconsidering your position?
Sure. Consider it done. Returning x works for 1 and 2, but does indeed
fall down on zero.
-- Bruce
Paolo Amoroso
> In article <aaksca$vb2sm$1...@fido.engr.sgi.com>,
> rp...@rigden.engr.sgi.com (Rob Warnock) wrote:
>
> > Marc Battyani <Marc.B...@fractalconcept.com> wrote:
> > +---------------
> > | So be happy. They already have done it! It's called XEXPR
> > | Look at http://www.w3.org/TR/xexpr/
> > ...
> > | <define name="factorial" args="x">
[...]
> > No. They were so intent on showing how clever they were with the syntax
> > that they got the definition of this simple function *wrong*!! ;-} ;-}
> >
> > [Hint: The consequent should be a certain numeric constant, not "<x/>".]
>
> No, it's fine. In fact, they could have increased the 2 to 3 (or
Hmmm... With this syntax, it takes a couple of experienced programmers to
figure whether a function as simple as a factorial is correct or not. What
were people saying about parentheses?... :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]