Foreword: Appolonius' car is a beautiful car. Over the years it has been repaired so many times that there is not a single piece of the original materials remaining. The question is, therefore, is it really still Appolonius' car?
----

Proponents of CarIdentity typically address cars based on a physical characteristic of the world in which they live.  For example, you may refer to a car based on the physical address at which it resides.

Another approach that is often taken is to assign a unique identifier to each instance of a car.  They are typically affixed to the front and rear bumber of the car.  This allows you to uniquely identify the car without depending on its physical address, which may change over time.

Counterargument: Consider a tuple of information that makes up a car (Make,Model,Year).  If there are two cars with the same Make,Model, and Year, then they are clearly the same car.  Why would you need to differentiate between two copies of (Pontiac,Firebird,2001)?  They are the same car.  The implementation may duplicate the car as necessary for performance reasons, but that doesn't change the fact that they all are the same.  If you need a (Pontiac,Firebird,2001), it doesn't matter which one instance you get - any instance is indistinguishable from the rest.

''Except your schema's incorrect--some Pontiac Firebirds are black and have leather seats; others are not.  Of course, some ObjectWeenie will probably insist on stuffing the VIN (an AutoGeneratedKey provided by the manufacturer) and then claim that two like Pontiacs with identical options are somehow distinct.''

Now this is getting silly.  The definition of a "car" will depend upon the intended operation.  For the purpose of determining car value; make, model, and year is usually sufficient (other evaluations may or may not also be applied).  For the purpose of requesting and verifying ownership of a car, the VIN may be the sole determining feature.  There is simply no need to drag object versus relational sparring into this subject.

''This page, and others like it having to do with cars, are largely intended as a satire of the OoVsRelational HolyWar that has been longstanding on Wiki... don't take any of this stuff seriously.  DeleteWhenCooked.''

Actually, although this page parodies the relational/OO debates, it grew out of some pages that ridiculed a LispSkeptic's repeated demands for "objective proof" of Lisp's superiority (interspersed with diatribes against exagerrated descriptions of LispWeenies' claims, and a persistent ability to avoid reading any material offered to him on Lisp topics). See ObjectiveAdvantagesOfCars, ObjectiveAdvantagesOfWoodenPencils, ObjectiveAdvantageOfHorses, and the starting point, ObjectiveAdvantagesOfLisp. Since you didn't acknowledge this important fact about the provenance of this page, you're obviously clueless about wiki satire, and readers would be foolish to trust your opinion on anything related to it. Go ReadTheWholeWiki before spouting your misleading and wrong-headed opinions.

''Actually, the pages are all making fun of TopMind, but I didn't want to say that out loud... at any rate, I created this page so I know quite well why it exists.  :)  ''[Huh?  I distinctly remember that '''I''' created it.]''  At any rate, your response suggests continuation of the parody.  With that in mind...your response is a clear example of the SocialProblemsOfLisp.  Typical SmugLispWeenie.  Are you sure you're not ErikNaggum in disguise?''

'':)''

Fool, I'm ErikNaggum in ''drag''.  ''Ewww.  Thanks for ruining my lunch.'' {You're just jelious because he has sexier thighs than you.}

AFAIK, it started on AreLispersTakingOverThisWiki, where the gadfly created a new link to the ridiculously-named HowCanSomethingBeSuperGreatWithoutProducingExternalEvidence, and kept going from there. I don't think that TopMind was either the original irritant, nor the creator of the ObjectiveAdvantagesOfBlah pages. If the person that started the satire pages targeted TopMind, they missed a far more worthy target.

* I don't know who started the page, but TopMind certainly piled on with a whole bunch of anti-Lisp rants.  Which is amusing, because if any existing general purpose language could be adopted to implement TableOrientedProgramming, it's CommonLisp.  The MetaObjectProtocol is capable of supporting more complicated dispatch forms (i.e. MultipleDispatch) than most of the industrial OO languages, which are limited to single-dispatch--I'm sure a good Lisp hacker could modify/extend CommonLisp generics to use a RelationalTable as a way of controlling dispatch.  Couple that with lambdas being an ideal means for specifying the code to be executed in each case (a lambda could easily be a table attribute--though top seems to dislike closures/lambdas and proposes instead that we store program code as text and run it through eval, which Lisp could easily do as well--perhaps he thinks that the dispatch table(s) acutally have to live on a RDBMS somewhere and be compatible with the SqlFlaws), it seems Lisp would be an ideal vehicle for such an exercise.  Maybe Top's anti-Lisp bias stems from PaulGraham's "we don't need no steenkin' database" commentary in his description of the yahoo stores project--but there's no reason that a Lisp program couldn't make good use of a RDBMS.
** Re: "and proposes instead that we store program code as text and run it through eval, which Lisp could easily do as well..." ''Why have two ways to do the same thing? If dynamic strings can do it (DynamicStringsVsFunctional), then the other stuff just adds confusion and complexity to the language, turning it into a CareerLanguage that everybody will avoid, like they usually do with Lisp. I am not going to try to bundle TOP with a language that has consistently been a hard sell. It is like banking your career on Ralph Nader winning the presidency. He keeps running but never comes close. -- top''
** Why two ways to do "the same thing"? Because one is far easier to work with than the other. Same justification as for the simultaneous existence of assembly language and C. I've worked with both modes -- have you? -- DanMuller
** ''Then one language does not fit all. I can buy that, but some GoldenHammer proponents may not.''
** Eh? Conclusion unwarranted. Some languages are far easier to work with for ''any'' task. The others just continue to exist through sheer inertia. :) Seriously, to clarify what someone said above, Lisp doesn't contain explicit functionality to execute data-as-strings -- but it can be built from things that ''are'' part of the language, namely read-string-as-data, then evaluate-data-as-code. I guess a good way to sum the approach up is that Lisp separates and exposes lexical analysis and parsing/compiling/evaluating, and lets programmers play in the region between them. You could paste the two pieces back together to get eval-string functionality, but there's rarly a desire to, for all the reasons that people are trying to explain to you on this and other pages.
Yer preachin' to the choir, sir. :) AFAICT, TopMind is open-minded compared to fellow that (ultimately) motivated these pages. Someone referred to him several times as a HostileStudent, which seemed an apt label. -- DanMuller