Funny. You know, contrary to the apparent beliefs of some people
   in this thread, there are imaginative programmers in other parts
   of the world than the USA, and even companies other than Lucent in
   the telcom switch business.

I think you are beating the wrong horse here.  First of all, many of
the hardcore C++ guys, Bjarne Stroustrup in particular, are NOT at
Lucent.  And then, there are things like SML/NJ, for example, which
started at AT&T Bell Labs and are now continued at Lucent Bell Labs.

Does this need to be cross-posted to all these lists,
or is that just to fully enflame all the religous sects?

Why would you imagine that LISP code is not maintainable?

Forget the C++ results for a moment. Let's assume they are flawed for
whatever reason.

The closeness of the C and Scheme results seems to justify my original
statement: That being that it "had some degree of success showing, was
that many of the people who choose C++ because they think that they
need it for efficiency, are at best not getting their priorities
right, and at worst are just wrong."

"Some degree" doesn't mean that it is proof, but that it is one piece
of evidence that could form the start of something meaningful.

In article <izwwolau9o....@mocha.CS.Princeton.EDU>,

The truth is that most large systems would be better off if they took their
200 grunts and broke them into 10-20 competing teams, each using what they
considered the best approach.  This solves 2 problems: you don't have to
try to figure out in advance who are the best programmers (or the best
programming languages), because that will subsequently become quite clear;
and you don't have to have 5 layers of 'managers' and interminable meetings
to try to coordinate 200 people.

In article <5mfos6$ng...@masala.cc.uh.edu>,

It's not that the Lisp cell is implemented as a pair of pointers.

It's that the lisp cell *is* a pair of pointers.

You can do everything with these pointers that you can do with pointers in
any other language, except perform arithmetic on them. Which was the point
of the message you're responding to in <5ln5nq$bc...@masala.cc.uh.edu>.

Really, the main useful thing one can do with pointers is to
compare them, yielding a notion of object identity. And Lisp
provides the EQ predicate for any pair of objects, not just
half-cons-cells.

Common Lisp provides arrays, hash tables, characters, strings,
I/O streams, conditions, closures, classes, and so on and
on and on.

Even Scheme, which is about as minimal as you'll find these days,
has arrays as well as cons cells; and most Scheme implementations
provide hash tables and things too, I believe.

And I don't remember the last time I used a Lisp implementation
that had OBLIST.

HIBT?

In article <izyb91av0c....@mocha.CS.Princeton.EDU>,

The C++ advocates debating here (and elsewhere) often bring up the fact
that C++ has succeeded in the marketplace where alternatives, such as
Lisp, have failed.  When it is pointed out to them that market acceptance
is not proof of worth, they agree and fall back on some other finer
point that can be gathered from the fact of market acceptance (like proof
that real software can be written in C++ and knocking down other similar
strawmen).  

The advantage to the C++ advocates in bringing up the relative success of
C++ vs. alternatives is to EMBARRASS the advocates of alternatives.  These
discussions generally go something like:

        C++ advocate: C++ is obviously a good thing, look at it's
                      market acceptance.

        Others: Yes, but Lisp is not accepted due to, uhhhh,
                sloppy thinking, uhhhh, cabal of software "experts" and
                their trade press lackeys, uhhhh, Microsoft politics,
                uhhh....

The problem is that Lisp is not accepted better and nobody really knows
why.  Those who attempt to explain it directly sound like paranoid
conspiracy theorists, or they have some unfounded argument about Lisp
syntax or GC or some other technical detail.  I'm sure it's entertaining
to the C++ advocates to watch all the weak-sounding defenses of Lisp
(and alternatives) whenever they bring up the issue of market acceptance.

There has recently been a great deal of discussion about some studies that
some claim were done in their organization at some time in the past that
shows that C++ is, to some appreciable degree, better in most respects to
C.  The subjects of the studies were disciplined, expert C programmers.

In the spirit of asking embarrassing questions, why is it that the MOST
expert C programmers, those fine folks at lucent.com chose C as the
implementation language for both of their most recent visible projects,
Plan 9 and Inferno?  These people have had access to the best C++
technology and expertise in the recent past AND they have not, in the
past, shown a reluctance to use other programming languages such as Pascal.  

No, I don't think that I've added anything to the ongoing discussions.  I
just couldn't help myself.

In article <izyb91av0c....@mocha.CS.Princeton.EDU>, bl...@mocha.cs.princeton.edu (Matthias Blume) writes:

Sean

o...@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

(The original version of the STL, before it was incorporated into the
C++ standard, did have algorithms with both two-way and three-way
comparisons.  When it was made part of the standard, though, features
were removed.  This wasn't the only useful feature tobe taken out.)

In article <5mhk60$...@starbase.neosoft.com>,

Side issue: let's not lump everyone into Lisp Advocate Versus C++ Advocate.

Some of us are devout agnostics.

Heck, I like Tcl. But then Tcl is a lisp variant.

* Peter da Silva
| There's really not much more to lisp than that.  Toss in COND, SET, LAMBDA,
| and EVAL and I think you've got it.  (Don't beat me up too hard if I missed
| something, it's been a while since I did a lot of lisp).  And I'll bet you
| could implement SET by CARing and CDRing around in OBLIST.

"a while"?  looks like it was 25 years since you last saw Lisp.  *sigh*

in Common Lisp (since 1984), you could use hash tables for sets.

as for your theory of dereferencing pointers, a CONS is an object with two
slots.  CAR returns the _contents_ of the first slot, CDR the second.  if
you pass an object not created by CONS to CAR, you get a type error.

        This discussion came from the STL thread.  What eventually seemed to
come from
that thread was that C++ was used for STL was because it would be faster
than other
languages available.  At least, I never heard anyone claim that C++ was
used
for any other reason, and I asked many times.

        Mr okeffe's test shows that, a least for a naive program, such as
_many_
programmers might write, that STL in C++ will not necessarily be faster
than
the alternatives.

        Now, I don't care what Mr Stepanov wrote his STL in.  If he likes C++,
fine, wonderful.  I'd like to find out why he likes it, though I never
did figure
it out.  And now he's gone away.

        Incedentally, common lisp has hashtables, and I'd be interested to see
how common lisp code from a good compiler competes with the C++ STL
hashset version.
But I don't expect this would prove anything to anyone.  If the LISP
code were
slower, or the C++ code were slower, people would still remain in their
respective camps.  I personally think they'd be pretty close in speed if
both
were 'tweaked'.

        Interestingly, it seems that generics in SML ought to be as fast as the
'best possible' C++ generics, though ML compilers seem to have lagged.
However,
some LISP compilers seem to emit pretty good generic code!  

In article <86wwojd3jg....@g.pet.cam.ac.uk>,
Gareth McCaughan  <gj...@dpmms.cam.ac.uk> wrote:

Look, let's put this in a wee bit of context.

The message that spawned this side-thread said something like "the only
problem with C pointers is that they support arithmetic, what if all you
could do was allocate and dereference them?". And, presumably, assign
them... otherwise there's nothing to dereference.

So this guy at UH said he didn't even want pointers that did that much, and
pointed to scheme as a pointerless language.

The point I'm trying to make is, that if you take out the arithmetic, but
still call what's left a "pointer", then scheme does have pointers. Now you
can argue that what's left isn't really a pointer any more. That's quite
legitimate, but then it's sort of hard to understand the original objection,
because they're not pointers when they're embedded in C either.

* Peter da Silva
| But those things don't define what Lisp is.  They're elaborations.  Lisp,
| at the bottom level, is the list.  The ability to express programs and
| data in the same format, and manipulate it using list operations, is what
| really defines a language as being part of the lisp family.

it's a persistent myth that Lisp has only one data type, the list.
(obviously, there must be a list of _something_, but hey, myths don't
generally respect logic any day of the week.)  I don't think it's wise to
keep that myth alive.

another persistent myth is that Lisp programs are lists.  they aren't.
Lisp _source_ code uses lists.  _compiled_, it is another data type, like a
code vector, which includes native machine code or perhaps byte code.

what defines the Lisp family to me, after I have had the opportunity to
refine my definition over time, is READ/WRITE CONSISTENCY.  all languages
in the extended Lisp family have this in common, and no languages outside
the Lisp family can sport anything like it.  that is, the ability to print
(write) some object out in text form and read it back in again (or the
other way around, depending on where the object is originating).

In article <3073830464727...@naggum.no>, Erik Naggum  <e...@naggum.no> wrote:

If I say "var a: int" and then later "a^" it'll give me a type error. Should
the pointers in Pascal be called "slots" instead?

Let's say I defined a C-like language with "slots" instead of "pointers". If
the operations on the "slots" are restricted to exclude arithmetic (which means
excluding casting, because that allows you to perform arithmetic), then are
they somehow no longer pointers? If not, how do they differ from the "slots"
you're talking about above?

In article <3073836438931...@naggum.no>, Erik Naggum  <e...@naggum.no> wrote:

(this is an extension of the aphorism that "all programming is an excersize
 in caching)

But semantically compilation has no effect on understanding a Lisp program.

pe...@nmti.com (Peter da Silva) writes:

<URL:http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/
html/cltl/clm/node1.html>

Peter da Silva (pe...@nmti.com) wrote:
: In article <5mfos6$ng...@masala.cc.uh.edu>,

[Snip]

: > However car, cdr, etc... implement their operations is a non-issue,

: You're right, but I'm not talking about the implementation.

: It's not that the Lisp cell is implemented as a pair of pointers.

: It's that the lisp cell *is* a pair of pointers.

If this detail is something that we need not be aware of then it is
an implementation issue as far as I am concerned.  My point in
all of this -- and one that I made before, is what we as the
programmers are seeing.  

: You can do everything with these pointers that you can do with pointers in
: any other language, except perform arithmetic on them. Which was the point
: of the message you're responding to in <5ln5nq$bc...@masala.cc.uh.edu>.

It's nice to know that you've kept enough of a handle on this thread
to supply a specific reference, yet it's depressing to know that you
haven't kept enough of a handle on this thread to know what I've
been talking about all along.

I was comparing a generalized pointer ala C with Lisp's generalized
list mechanism.  My entire point was that these were two entirely
different beasts.  The newcomer to Lisp can be told that there
are no pointers in the language and will never be the wiser
(particularly if s/he utilizes a functional style as I do
in Scheme).  This is all that matters and that is my point.

: > This entire genre of operations is abstracted away from us, we are
: > given a view of lists.

: Nonsense. You can build arbitrary structures with these pointers using
: the five basic operations (CONS, CAR, CDR, RPLACA, RPLACD). You obtain
: a pair of pointers with CONS, assign them with RPLACA and RPLACD, and
: dereference them with CAR and CDR.

Arbitrary structures of these _LISTS_ are nothing more than _LISTS_ of
_LISTS_.  Again there is no resemblence to the traditional pointer --
we don't allocate to it, we don't use any stupid dereferencing
symbols, etc...

Lisp is about Lists.  As far as I'm concerned there are no pointers
and until I encounter a situation that breaks the abstraction of
the high level object (lists), then I will not budge.

When you can show me an example of Lisp code that dereferences
pointers ala C or Pascal then I'll believe you, until then,
you have proven nothing.

: There's really not much more to lisp than that. Toss in COND, SET, LAMBDA,
: and EVAL and I think you've got it. (Don't beat me up too hard if I missed
: something, it's been a while since I did a lot of lisp). And I'll bet you
: could implement SET by CARing and CDRing around in OBLIST.

*Sigh*.  Read back a few more articles.

: --
: The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
: Har du kramat din varg, idag? `-_-'                                Kulanu Kibo.
: Hail Eris! All Hail Discordia!                                 Vi er alle Kibo.
: HEIL KIBO! HEIL KIBO! HEIL KIBO!                            Wir sind alle Kibo.

--
Cya,
Ahmed

Peter da Silva (pe...@nmti.com) wrote:
: In article <86wwojd3jg....@g.pet.cam.ac.uk>,

[Snip]

: Depending on the definition of "pointer", sure.

This has been covered several articles back -- do your homework.

: Look, let's put this in a wee bit of context.

It's been put in context already -- check the above.

: The message that spawned this side-thread said something like "the only
: problem with C pointers is that they support arithmetic, what if all you
: could do was allocate and dereference them?". And, presumably, assign
: them... otherwise there's nothing to dereference.

: So this guy at UH said he didn't even want pointers that did that much, and
: pointed to scheme as a pointerless language.

Again, if you read the threads thoroughly, you would know by now
that this was discussed with an emphasis on interface.  GC, no
annoying "pointer vs. value" syntax, etc...

: The point I'm trying to make is, that if you take out the arithmetic, but
: still call what's left a "pointer", then scheme does have pointers. Now you
: can argue that what's left isn't really a pointer any more. That's quite
: legitimate, but then it's sort of hard to understand the original objection,
: because they're not pointers when they're embedded in C either.

But in C they do have arithmetic properties so your statement is
quite pointless.

: > Er. It seems like "a while" means "since the days of Lisp 1.5, or
: > earlier"; or is this a troll?

: Is Lisp 1.5 still lisp?

It depends on your definition of "Lisp".  Maybe we could squabble
over this a while to make you realize just how pointless your
quibbles are.

: > Common Lisp provides arrays, hash tables, characters, strings,
: > I/O streams, conditions, closures, classes, and so on and
: > on and on.

: But those things don't define what Lisp is. They're elaborations. Lisp, at
: the bottom level, is the list. The ability to express programs and data in
: the same format, and manipulate it using list operations, is what really
: defines a language as being part of the lisp family.

Interface vs. Implementation.  See pointers.  Re-read passage.

: > HIBT?

: No. I'm simply ignoring a lot of irrelevant issues that, while they make the
: language more efficient and convenient, don't change its essential nature.

That would depend on what you consider "its essential nature" to be now
wouldn't it?

: --
: The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
: Har du kramat din varg, idag? `-_-'                                Kulanu Kibo.
: Hail Eris! All Hail Discordia!                                 Vi er alle Kibo.
: HEIL KIBO! HEIL KIBO! HEIL KIBO!                            Wir sind alle Kibo.

--
Cya,
Ahmed

Peter da Silva (pe...@nmti.com) wrote:
: In article <3073830464727...@naggum.no>, Erik Naggum  <e...@naggum.no> wrote:
: > in Common Lisp (since 1984), you could use hash tables for sets.

<Irritable Mode On>

: But a language without hash tables is still a lisp. A language without
: lists isn't a lisp.

<Sarcasm On>

A language without hash tables isn't necessarily a lisp.  C doesn't
have hash tables, yet by your logic it is a lisp.

<Sarcasm Off>

: > as for your theory of dereferencing pointers, a CONS is an object with two
: > slots.

: What's the difference between a slot and a pointer, semantically?
                                                      ^^^^^^^^^^^^^

Semantics has nothing to do with it.  My arguments were not with
respect to semantics, and if you had bothered to pay attention
you would know this.

: > CAR returns the _contents_ of the first slot, CDR the second.

: "Returning the contents of" is "dereferencing". That's what the word
: means, taking a reference to an object and returning the object itself.
: Whether the words you use are "a slot containing an object" or "a pointer
: to an object", semantically the operation is the same one.
                 ^^^^^^^^^^^^

Again since I'm not talking about semantics, your passage is irrelevant.

[Snip]

: (remember, I'm just responding to an assertion that pointers, as defined above,
:  don't exist in scheme)

Pointers as defined in a previous thread which you obviously didn't
read.  

Suggestion: Read that thread.

<Irritable Mode Off>

: --
: The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
: Har du kramat din varg, idag? `-_-'                                Kulanu Kibo.
: Hail Eris! All Hail Discordia!                                 Vi er alle Kibo.
: HEIL KIBO! HEIL KIBO! HEIL KIBO!                            Wir sind alle Kibo.

--
Cya,
Ahmed

From the Franz, Inc. web site:

 Lucent Technologies, formerly AT&T Network Systems
 and Bell Labs Research, has licensed Allegro CL products
 for the past 10 years. Lucent's various projects involving
 Allegro CL development have included a distributed
 service workbench for video on demand applications over
 ATM, ATM switching, and interfaces to various database
 systems.

 A switching application known as the Globeview-2000
 Broadband System was developed to accommodate new or
 custom services such as routing by call origin, call
 forwarding, universal telephone numbers, voice mail and
 other services. These services could be updated on-the-fly
 to a running switch because of Allegro CL's Dynamic
 Objects technology.

First of all, *YOU* have provided no evidence whatsoever that this
is a 'performance bug'.  It would appear that any discrepancy between
the "C++ is fast" religion and practice will be dismissed as 'a
performance bug'.  Is there any conceivable measurement, involving
any C++ program and any *actual* compiler, that would lead someone
to decide against C++, which you could not similarly dismiss as
'just silly' because it's only due to 'a performance bug'?

Don't forget, I tried *TWO* independent implementations of C++.
One couldn't compile the program *AT ALL*.
The other one did, and it ran slow.

Now, it appears that a large part of the problem is due to the use of
the <string> header and the 'string' data type therein.  This is not
part of the compiler.  I suppose you could call it a 'performance bug'
in the library, and

*if* you could provide me with a version of <string> that came as close
to standard conformance as the one in libg++, and
*if* the program then ran faster, you would hvae *evidence* of a
'performance bug' in the library.  I'm quite willing to believe it.

*Some* C++ advocates in this thread have provided more than excuses.
I've forgotten who it was that tried the thing out using char* instead
of <string>.  THAT WAS WELL DONE!  That was USEFUL!  It did establish
that <string> is part of the problem in this test.

But where is the evidence that an efficient implementation of <string>
is actually *possible*?  There's a known performance design bug in
Scheme strings (strings are mutable, which forces (substring) to copy
instead of sharing).  C++ <string> has the same performance design bug.
That's not the only one.

Don't forget, it's not really a matter of 'one implementation, one bug,
one test" amongst many.  For *me* the actual experience was "the *BEST*
compiler I had access to, the *FIRST* serious test I did."  Do you call
someone 'just silly' who fears the flame after his fingers are burnt the
first time?  I have actually done several other tests since the first one,
and while they are not all as extreme, they all consistently show C++
to be more than a factor of 2 slower than C *IF* I use the features of
C++ that are not also in C.  If I use the C-like aspects of C++, then I
get C-like performance, which makes it rather hard to believe in
'performance bugs'.

Frankly, for me the really damning thing is CC, not g++.
I don't know when the feaures I have been trying were first put in
the C++ draft standard, but they were there in April 1995, and they
were still there looking just the same in December 1996, and yet the
latest C++ compiler from a major vendor, which we installed in
February 1997, WAS NOT ABLE TO COMPILE A PROGRAM USING <string> AT ALL.

Being unimpressed by a language on the basis of one bad benchmark might
be silly (though nowhere near as silly as trying to pretend that it has
no significance at all), but surely no-one in these closing years of the
20th century would want to deny that _dramatic_ differences in what
compilers for the 'same' langauge actually accept is cause for concern?
(After all, it _was_ the most commonly given excuse for not using Prolog.)

I have also posted numbers for a more efficient solution to the problem,
and while the C++ code using <set> AND <list> was less inefficient than
the C++ code using <list> alone, it was STILL no less than FOUR TIMES
SLOWER than the corresponding C code.

Now, I *do* accept as a valid criticism that there *is* an STL-
compatible <slist>, and I know where to find it.  A pity it isn't
in the standard.  Perhaps it will be.

I consider it beyond any possible dispute that >>> C++ <<< can solve this
problem (or indeed most others) as efficiently as C.

The question is whether *using the STL* helps.  The aim was to build the
simplest clearest solution using the STL in a fair way, and to compare
that with reusing existing Scheme and C library code.