From: Tim Bradshaw
Subject: Class/instance confusion as a source of misunderstanding
Date:
Message-ID: <nkjithinf7u.fsf@tfeb.org>
I was thinking about the recent `but lisp does not have x built-in'
thread and I realised that this is yet another case of class/instance
confusion. I think that this is a fairly common problem, so I though
I'd describe it to see if anyone else thinks it is. It's not really
anythig to do with Lisp, except insofar as things like CLOS really
make you think about these issues.
Class/instance confusion is where someone confuses a class of things
with an instance of that class, and therefore becomes confused.
A good example of this which has gone through several stages relates
to HTML. When HTML became popular, people started hearing about SGML,
and you'd often hear SGML described as if it was a kind of souped-up
HTML. But this isn't correct: HTML is a grammar for documents, but
SGML is a system for *writing* grammars for documents. If HTML is an
instance, SGML is a class (and of course, because HTML is a grammar,
particular documents can be instances of that grammar, so the whole
problem is very similar to the MOP: the document is an instance, HTML
is a class and SGML is a metaclass). Now of course, these same people
have forgotten about SGML and are enthusing about XML as a kind of
souped-up HTML. But again this is a class/instance confusion (except
HTML isn't a grammar you can write with XML, but I think that there's
something called XHTML which is).
The same problem happens with Lisp and (say) Perl. Lisp is a class of
languages, Common Lisp is a subclass of that class, and CL
implementations are instances of the CL class. Perl is the only
instance of the class of languages-which-are-perl (which class has no
real definition as they keep changing perl). So saying that perl has
x built-in whereas Lisp (or CL) does not, and therefore is not so good
is a class/instance confusion, and really meaningless. It's like
saying (< 1 (find-class 'integer)): the correct response is to signal
an error.
The habitual lisp-is-slow, lisp-is-bug , lisp-is-x claims are similar
confusions, and similarly meaningless.
I bet there are lots of other examples of this confusion (Unix vs
Windows springs to mind, if I was less of a nerd I could probably
think of some non-computery ones).
I'm not quite sure why I've written this now...
--tim
From: Kent M Pitman
Subject: Re: Class/instance confusion as a source of misunderstanding
Date:
Message-ID: <sfwy9qendb3.fsf@world.std.com>
Tim Bradshaw <···@tfeb.org> writes:
> I'm not quite sure why I've written this now...
Perhaps, for instance, you thought it a classy way to view things.
;-)
I try to be careful to make people say "Lisp language" or "Lisp
implementation" to help avoid this confusion. But you're right that
the generalization of the terms "language" and "implementation" in
this specific context is "class" and "instance". I think it's useful
to observe relations like this since people have cached knowledge of
general terms like "class" and "instance", their power and limitations,
and, if they haven't noticed the relationship already, it allows them
to apply that knowledge to this other domain. Seemed a reasonable
observation to me.
Tim Bradshaw <···@tfeb.org> writes:
> I was thinking about the recent `but lisp does not have x built-in'
> thread and I realised that this is yet another case of class/instance
> confusion. I think that this is a fairly common problem, so I though
> I'd describe it to see if anyone else thinks it is. It's not really
> anythig to do with Lisp, except insofar as things like CLOS really
> make you think about these issues.
>
> Class/instance confusion is where someone confuses a class of things
> with an instance of that class, and therefore becomes confused.
> A good example of this which has gone through several stages relates
> to HTML. When HTML became popular, people started hearing about
> SGML, and you'd often hear SGML described as if it was a kind of
> souped-up HTML. But this isn't correct: HTML is a grammar for
> documents, but SGML is a system for *writing* grammars for
> documents. If HTML is an instance, SGML is a class (and of course,
> because HTML is a grammar, particular documents can be instances of
> that grammar, so the whole problem is very similar to the MOP: the
> document is an instance, HTML is a class and SGML is a metaclass).
> Now of course, these same people have forgotten about SGML and are
> enthusing about XML as a kind of souped-up HTML. But again this is
> a class/instance confusion (except HTML isn't a grammar you can
> write with XML, but I think that there's something called XHTML
> which is).
Most people haven't that clue about the relationship between HTML,
SGML, and XML, and that even applies to people that _are_ intelligent
and [otherwise] quite knowledgeable.
> The same problem happens with Lisp and (say) Perl. Lisp is a class of
> languages, Common Lisp is a subclass of that class, and CL
> implementations are instances of the CL class. Perl is the only
> instance of the class of languages-which-are-perl (which class has no
> real definition as they keep changing perl). So saying that perl has
> x built-in whereas Lisp (or CL) does not, and therefore is not so good
> is a class/instance confusion, and really meaningless. It's like
> saying (< 1 (find-class 'integer)): the correct response is to signal
> an error.
In part, the complaint is about "library" versus "language;" what is
perhaps a bit of a problem with Common Lisp is that it subsumes quite
a lot of stuff that, in other languages, would be considered
"library," but does not call it such, and isn't particularly conscious
of such.
[Yes, I've used the PACKAGE functions...]
In a sense, the problem is that the CL standard has been pretty static
for a number of years now. [Arguably surprising for a dynamic
language!]
Had the ANSI committee continued to meet on the standard, we might
have seen some of the function sets created to cope with things like
databases and internet applications grow into the standard.
What is unfortunate, and _will_ affect peoples' thinking about Lisp,
is that with Perl, or Python they can expect to have some
quasi-standardized socket functions available, whilst with Lisp, the
APIs and semantics differ for each implementation.
The point is that there has been enough time for some quasi-standards
to grow up around extensions like sockets/webbing/dbmsing, but it just
hasn't happened. That doesn't make Lisp _bad_, but it does make it
considerably less attractive to management that may not understand
technical things.
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://vip.hex.net/~cbbrowne/spreadsheets.html
Why are there flotation devices under plane seats instead of
parachutes?
From: Tim Bradshaw
Subject: Re: Class/instance confusion as a source of misunderstanding
Date:
Message-ID: <nkjvglhdeno.fsf@tfeb.org>
········@hex.net writes:
>
> What is unfortunate, and _will_ affect peoples' thinking about Lisp,
> is that with Perl, or Python they can expect to have some
> quasi-standardized socket functions available, whilst with Lisp, the
> APIs and semantics differ for each implementation.
>
But this is *precisely* the confusion I was talking about. If you
want to compare Lisp and (say) Perl, you need to compare an
*implementation* not the Class `Lisp'. Take CLISP for instance:
probably similarly portable, probably has a `standardised' socket
interface in exactly the sense that Perl does.
The point is that it's *really cheap* to standardise something for a
single implementation: you just write the code. But it's *really
expensive* to standardise something for a class: it requires meetings,
thought, iterations of design, careful politicking so no implementors
get screwed and so on. And it's an error to compare a single
implementation `standard' with a standard for a class: they are not
the same thing.
It may be that there are cheap ways to standardise things across
classes, but I am not aware of any. Things like the Posix, C and C++
standards have had millions and millions of dollars sunk into them.
If you want to standardise things for `CL' you need either to find a
cheap way of doing it (I'd like to hear of one), or find a lot of
money (an estimate of how much: if the standards work has 10 active
members, who spend 30 days a year working on standards (this is
probably pretty conservative), and their charge-out rate is $1000/day,
it costs $300,000 / year to support that work).
--tim
Tim Bradshaw <···@tfeb.org> writes:
> The point is that it's *really cheap* to standardise something for a
> single implementation: you just write the code.
Especially when you keep your "standard" a moving target, like perl
does. And that target moves fast! (perl 5.003, 5.004 and 5.005 were
not at all the same languages. Many are still stuck with 5.003 as
their /usr/bin/perl because they have tons of cgi's etc. which would
break when upgrading. So the newer scripts address the version directly.
So you have to keep 4 or 5 versions of perl around...).
--
(espen)
From: Tim Bradshaw
Subject: Re: Class/instance confusion as a source of misunderstanding
Date:
Message-ID: <nkjpubpvw0l.fsf@tfeb.org>
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Especially when you keep your "standard" a moving target, like perl
> does. And that target moves fast! (perl 5.003, 5.004 and 5.005 were
> not at all the same languages. Many are still stuck with 5.003 as
> their /usr/bin/perl because they have tons of cgi's etc. which would
> break when upgrading. So the newer scripts address the version directly.
> So you have to keep 4 or 5 versions of perl around...).
Oh yes. I stopped upgrading a couple of years ago or so when I tried
to install what looked like a really small keep-up-to-date version
(.00<n+1> over .00<n> for some n), only to discover that various huge,
awful, critical scripts we use (not written by us) broke in totally
obscure ways. I'm only glad that our system management policies are
good enough that we could back out in a second or so, and write a huge
message in the log file not to upgrade until those problems were
sorted, which may mean never.
Compare this to what happened when we went from a non-unicode ACL to a
completely unicode one: things just worked with the only lossage being
some bad assumptions I'd made about FILE-LENGTH and `read length'
which would never have been true on Windows I think, anyway. Those
same programs now work on LW too with similarly tiny changes.
This isn't just standards, it's also plain good practice by the
vendors. I'm very glad that the CL vendors (and the free projects as
far as I can see) take this seriously.
--tim
From: Kent M Pitman
Subject: Re: Class/instance confusion as a source of misunderstanding
Date:
Message-ID: <sfwpubpitrk.fsf@world.std.com>
········@hex.net writes:
> Had the ANSI committee continued to meet on the standard, we might
> have seen some of the function sets created to cope with things like
> databases and internet applications grow into the standard.
Standards need to be made out of practice, not out of philosophy.
The first step in making a standard is for a vendor or user base to try
something. If only one tries, there is no need for a standard. If two
try and get incompatible results which cannot be resolved, then the
cost of a standards group starts to make sense. But not before.
On Wed, 27 Jun 2001 15:59:19 GMT, ········@hex.net wrote:
> In a sense, the problem is that the CL standard has been pretty static
> for a number of years now. [Arguably surprising for a dynamic
> language!]
Maybe this is because Common Lisp provides the tools for letting user
extend the language in useful ways without the need for formal
standardization work.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Bulent Murtezaoglu
Subject: Re: Class/instance confusion as a source of misunderstanding
Date:
Message-ID: <87hex0ec0k.fsf@nkapi.internal>
>>>>> "CB" == cbbrowne <········@hex.net> writes:
[...]
CB> Most people haven't that clue about the relationship between
CB> HTML, SGML, and XML, and that even applies to people that
CB> _are_ intelligent and [otherwise] quite knowledgeable.
This is inescapable and IMHO OK, as long as those people are intelligent
and knowledgeable enough to know what they do not know. I find that unless
I really have a need and try to understand something by going to 'primary'
sources I will be utterly confused by marketing hype and people around
me who bought into it. This was not always true, IMHO. AFAIR maybe
10 years or so ago you could get a reasonably accurate idea about a
technology by reading maybe 40-50 pages from an obvious source. The
first piece of language technology that I noticed I could not do this
for was C++. I remember thinking in the late 80's early 90's that
the hype for the 4GL fad was not as opaque as the hype for C++ fad
in that forming a reasonably educated opinion about the former _and
communicating it_ was much easier than it was for C++ and C++ flavor
of OO. Part of this was due to the relative complexities, but I think
today systems/languages/paradigms are not described in a manner that at
least attempts to maintain some intellectual integrity, but are 'marketed'
in a manner that attepts to leverage the brain damage already induced
by other marketing. Knowing what you actually don't know may have become
harder as a result but is probably more important now.
[...]
CB> What is unfortunate, and _will_ affect peoples' thinking about
CB> Lisp, is that with Perl, or Python they can expect to have
CB> some quasi-standardized socket functions available, whilst
CB> with Lisp, the APIs and semantics differ for each
CB> implementation.
I partly agree with this, but as far as sockets go the semantics do
differ anyway due to underlying systems. If you do something serious
that requires you to step beyond listen/accept you will need to figure
out what the OS is doing (and for servers that see load, what the OS can
do efficiently). If you are serious about sockets and read say Stevens'
books, you will already know enough for the details of the sockets
implementation in your CL not to confuse you. If you just need a pipe
to shove data through in a 500 line script, I don't know if you shouldn't
be using perl, python or tcl anyway (the chances are someone with minimal
knowledge will try to maintain it down the line). To appeal to that market
maybe one could write a with-tcp-pipe-to macro for all CLs out there and
solve that problem in the technical sense -- but that's a technical solution
to a marketing/culture problem and won't solve it.
cheers,
BM
From: Daniel Barlow
Subject: Re: Class/instance confusion as a source of misunderstanding
Date:
Message-ID: <877kxxq3uc.fsf@noetbook.telent.net>
Tim Bradshaw <···@tfeb.org> writes:
> implementations are instances of the CL class. Perl is the only
> instance of the class of languages-which-are-perl (which class has no
> real definition as they keep changing perl).
A prototype-based system, then
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
From: Tim Bradshaw
Subject: Re: Class/instance confusion as a source of misunderstanding
Date:
Message-ID: <nkjae2tbpt5.fsf@tfeb.org>
Daniel Barlow <···@telent.net> writes:
>
> A prototype-based system, then
>
which supports only singleton classes...
--tim