On Mon, 18 Aug 2003 11:34:05 -0700 (PDT), ········@ziplip.com"
<·······@ziplip.com> wrote:
>ML predates C++, so why didn't it replace C when the limitations
>of C became apparent? There were no good ML compilers?
Lisp predates ML, why didn't it replace C instead of C++?
There could be a lot of reasons for it, but probably the simplest is
that C++ is really just an extension to C. Quite a few of the (quote
C++) programs are really just C programs, because they don't make use
of the C++ features. It's a lot easier both politically and mentally
to switch to version 2 of a language instead of switching to an
entirely new language, let alone an entirely different paradigm.
I've seen a few posts on this board alluding to the feeling that
Lispers are baffled why Lisp hasn't had wider adoption. In so many
ways Lisp has always been superior to C++, really only lagging behind
in speed, but making up for it in programmer performance.
As an aside, did you mean to post this on comp.lang.ml?
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Doug Tolton wrote in article <··································@4ax.com> on
Monday 18 August 2003 21:32 in comp.lang.lisp:
> Quite a few of the (quote
> C++) programs are really just C programs, because they don't make use
> of the C++ features. It's a lot easier both politically and mentally
> to switch to version 2 of a language instead of switching to an
> entirely new language, let alone an entirely different paradigm.
>
C++ is not C version 2. People coding with that definition in mind are likely
to be bad C++ coders. C++ is a totally different language in its philosophy
and design; IMO, it's as difficult to go from C to C++ and code well, than
from C to Lisp. The former might even be more difficult, because you have to
not fall in the trap of "C++ is C v. 2". And being aware of that trap doesn't
mean you don't fall in it sometimes.
Now, if by "switching", you mean being able to write a program that runs,
well, yes, the first solution may be easier. That's not enough for me,
though.
Which is why I think the original post asks the wrong question. The real
question would be "Why isn't [ML/Lisp/whatever language that predates C++ and
does a good job at OOP] used instead of C++". C++ is not a replacement for C.
Sam
--
"[...] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new
work."
- J.R.R. Tolkien, Ainulindale (Silmarillion)
On Mon, 18 Aug 2003 22:56:15 +0200, Sam Zoghaib wrote:
> C++ is not C version 2. People coding with that definition in mind are likely
> to be bad C++ coders. C++ is a totally different language in its philosophy
> and design; IMO, it's as difficult to go from C to C++ and code well, than
> from C to Lisp.
Which makes me wonder why, oh why, Mr. Stroustrup decided to use C as a
starting. In my opinion, and for what it is worth, C++ is quite probably
the worst idea in the computer science field since its inception.
> Which makes me wonder why, oh why, Mr. Stroustrup decided to use C as a
> starting. In my opinion, and for what it is worth, C++ is quite probably
> the worst idea in the computer science field since its inception.
That's not an entirely fair characterization. What about C++ disgusts
you so much, and most importantly, what sort of applications have you
used it for? In my experience, there are a few illegitimate reasons
that people hate C++:
1) They're using it wrong. Of the "popular" languages (C, C++, Java,
C#, etc), C++ is by far the most powerful. With modern methods,
(properly using RAII, using smart pointers, taking full advantage of
the STL algorithms and containers), it is also efficient in terms of
programmer time. People sometimes mention stuff like, "C++ is weakly
typed because of casts," or "pointer arithmatic is dangerous." These
are features that exist in C++ because they are needed by an important
segment of C++ programmers. They take concious effort to use. If you
don't want their danger, don't use them.
2) They're using it for the wrong sorts of problems. Most of the time
I hear criticisms of C++, they come from users doing very high-level
programs, like server applications, scientific apps, mathematical
apps, etc. They never wander near hardware or kernel space. On the
other hand, I spend most of my time living down by the interrupts, or
slightly higher formatting memory buffers directly for specific
protocols. Yes, this is the traditional, "you can't write a kernel in
Lisp" argument. But heck, somebody has to write all those kernels, and
drivers, and network stacks, high-performance rendering engines, and
all the other infrastructure that VHLL (very-high-level-languages) can
just take for granted. They need a language that gives them precise
control of bit patterns, direct access to memory, and precise control
of memory allocation and deallocation. As somebody who is writing a
kernel in C++, I have to say C++ is a much better language for this
sort of work. Now, much of this infrastructure has been written, and I
would agree that most new programs these days should use higher-level
languages. But this was definately not the case when C++ was invented.
Also, remember that many of the technologies that make languages like
Lisp decent general purpose languages (powerful, type-inferencing
compilers, fast JITs) didn't exist when C++ was invented.
3) They're using it in situations where the primary irritant is
something other than C++. If you're stuck in a job programming MFC,
you have a reason to be bitter, but not necessarily to hate C++ :)
More generally, people who have to use C++ for work, and use another
language for their personal hacking are going to have a biased view of
the language.
Now, there are a lot of legitimate reasons to dislike C++. See my post
on comp.lang.dylan where I elaborate on these. But none of these
reasons are enough to warrent calling C++ the worst invention in
computer science. That honor has to go to MFC :)
PS> I would not normally want to post this on c.l.l, but don't flame
me for doing so. It would be unfair to deride a language (without any
specifics I might add!) without giving people a chance to defend it.
·······@mindspring.com (Rayiner Hashem) writes:
> In my experience, there are a few illegitimate reasons
> that people hate C++:
[...]
> These are features that exist in C++ because they are needed by an important
> segment of C++ programmers. They take concious effort to use. If you don't
> want their danger, don't use them.
This is good advice, and C++ wouldn't be nearly so bad if people followed it.
The problem is they don't. C++ programmers tend to instinctively use raw
pointers and low-level arrays, take addresses of local vars, etc.
The result: chaos.
C++ can be quite good if you use it in a careful disciplined way. It all too
easily becomes disastrous though.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Blaak wrote:
> The problem is they don't. C++ programmers tend to instinctively use raw
> pointers and low-level arrays, take addresses of local vars, etc.
You are overgeneralizing. C++ is a tool for expert programmers who know not
to do that. But yes, if you want (or have to) to fiddle with bits and
pointers: C++ allows you to do so. And yes, learning C++ is difficult and
takes time. C++ is a sharp knife and you can cut yourself easily when
you're not careful. In the hand of a master it's a powerful tool.
Richard P. Gabriel reports in "Patterns of Software" that his programmers
experienced an estimated 30% drop in productivity after one year when
switching from CL to C++. I think this is a realistic number. When speed
or low-level hardware access or bindings to certain libraries are important
some people will decide that loosing 30% producitvity is acceptable to
them.
Matthias <····@yourself.pl> wrote in message news:<············@trumpet.uni-mannheim.de>...
> Ray Blaak wrote:
>
> > The problem is they don't. C++ programmers tend to instinctively use raw
> > pointers and low-level arrays, take addresses of local vars, etc.
>
> You are overgeneralizing. C++ is a tool for expert programmers who know not
> to do that.
Fair enough. I too love C++'s power when I need it.
The problem, then, is that too many non-expert programmers are using
it.
The overwhelming majority other's C++ projects that I have had to
maintain are, in a word, shit.
Why oh why don't people use it better?
Ray
In article <····························@posting.google.com>,
·····@telus.net (Ray Blaak) wrote:
> The overwhelming majority other's C++ projects that I have had to
> maintain are, in a word, shit.
>
> Why oh why don't people use it better?
Because there's no percentage in it.
If you're a developer you are typically judged by how many projects you
"completed" (and whether they were "on time" or "late") not by the quality
of the code (because that's too hard to measure). And a project is often
judged to have been "completed" if it compiles and runs on a bare handful
of test cases. After that the developer can check it off, add it to his
resume, and it becomes the QA department's problem. There is no reward
for taking extra time to make the code bug-free and comprehensible.
If you're a business you have the same problem, except that the situation
is even more perverse. The market actually rewards bad code (up to a
point) because if your code is bad you can make additional money by
selling "support contracts". If your code "just works" then people won't
buy your support contracts because they won't need them.
(Actually, there's an equivalent situation for the individual coder.
Incomprehensible code provides job security for its author because only
that person can maintain it. The author effectively gets a monopoly on
"support contracts" for that code.)
If you're a professional coder you'd have to be a fool to write good code
on purpose in today's economic climate.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> If you're a professional coder you'd have to be a fool to write good
> code on purpose in today's economic climate.
I have spent so much effort learning how to write good code, to
develop a sense of "taste," that I cannot bring myself to write the
bad or careless code you suggest. Given the quandary above, with
competence and skill warranting punishment rather than reward, I no
longer know what it means to be a "good" developer. Is worse better?
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
In article <···············@raytheon.com>, Steven E. Harris
<········@raytheon.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > If you're a professional coder you'd have to be a fool to write good
> > code on purpose in today's economic climate.
>
> I have spent so much effort learning how to write good code, to
> develop a sense of "taste," that I cannot bring myself to write the
> bad or careless code you suggest. Given the quandary above, with
> competence and skill warranting punishment rather than reward, I no
> longer know what it means to be a "good" developer. Is worse better?
I was perhaps a bit hasty. Whether or not you're a "fool" depends on your
quality metric. There is more to life than money.
I think we can get some indication of how this will go by looking at the
history of other industries, e.g. the automobile industry. In the early
1970's the American car industry was fat, dumb, and happy, and producing
crappy cars. Then Japan came along. Today the American software industry
(a.k.a. Microsoft) is fat, dumb, and happy and producing crappy software.
Something like Japan will eventually come along and give the U.S. a kick
in the pants, but exactly what that will be is not clear yet. It might be
Linux. It might be something that China will pull out of their hat. (It
will almost certainly not come from Japan this time because they seem to
have completely lost the initiative that led them to dominate the car
industry.)
But if your goal is to make money then at the moment (and for the last
twenty years) worse is clearly better. Alas.
E.
Erann Gat <···@jpl.nasa.gov> wrote:
> But if your goal is to make money then at the moment (and for the last
> twenty years) worse is clearly better. Alas.
No. If your goal is to make money *selling software*, then worse is
better.
If you work for someone who's main business is not selling the software,
but using it to make money some other way, then good code, and good
developers become exponentially more valuable than bad code and poor
developers.
Of course, I'm not talking about the famous "right thing" v. "worse is
better" tradeoff, where often getting something useful out the door now,
vs. a year from now is worth major quality tradeoffs, even very long
term ones. it's clear that situations where in theory "the right thing"
is clearly a superior model, "worse is better" gets rewarded by the
marketplace anyway, because the market is so very short-sighted about
issues it doesn't understand.
But that's the market as a whole. Individual companies may well know
where their bottom line lies and occasionally be in position to do the
"right thing" when it makes long term sense.
Michael
In article <·····························@bcect.com>, ·······@bcect.com
(Michael Sullivan) wrote:
> Erann Gat <···@jpl.nasa.gov> wrote:
>
> > But if your goal is to make money then at the moment (and for the last
> > twenty years) worse is clearly better. Alas.
>
> No. If your goal is to make money *selling software*, then worse is
> better.
Right.
> If you work for someone who's main business is not selling the software,
> but using it to make money some other way, then good code, and good
> developers become exponentially more valuable than bad code and poor
> developers.
Good point.
E.
·······@bcect.com (Michael Sullivan) writes:
> Erann Gat <···@jpl.nasa.gov> wrote:
>
>> But if your goal is to make money then at the moment (and for the last
>> twenty years) worse is clearly better. Alas.
>
> No. If your goal is to make money *selling software*, then worse is
> better.
I write software because I can't imagine *not* writing software.
It happens to be very convenient that people will pay a fair amount of
money for software, so I can sell some of my work. But my love of the
engineering and the art of software is the driving factor, so I'd rather
make less (but sufficient) money producing `the right thing' than
`worse is better'.
"Ray Blaak" <·····@telus.net> wrote in message
·································@posting.google.com...
> Matthias <····@yourself.pl> wrote in message
news:<············@trumpet.uni-mannheim.de>...
> > Ray Blaak wrote:
> The problem, then, is that too many non-expert programmers are using
> it.
>
> The overwhelming majority other's C++ projects that I have had to
> maintain are, in a word, shit.
>
> Why oh why don't people use it better?
Part of C++'s problem is similar to Lisps.
People decry "writing C in C++" and "C++ isn't C, it's
betterstrongerfaster".
But, that's what it is TODAY, it's what the language has evolved into.
It started as "C with Objects". A pre-processor hack. So, much of its C
legacy is deeply ingrained into modern C++ lore. Ancient code, ancient
books, ancient tips and tricks.
Yes, all of those features (pointers, casts, etc) are for advanced
programmers, yet they're all "Chapter 2" in the C++ books. They're the first
things folks seem to learn, and the last thing they should be using.
"Chapter 2" is pointers and "How to mangle your stack frame" while "Chapter
83" is templates and how not to do all the damage "Chapter 2" taught you.
I have yet (not that I've looked real hard) found a good book on C++ that
teaches modern C++, assumes templates from the get go, teaching about smart
pointers, etc. Where "Chapter 27 -- What are these other pointer things?" is
common.
There have been some efforts to teach "modern" Common Lisp, where CONS and
CAR and CDR are "advanced concepts", etc. Where time is better spent
focusing on things like structures and CLOS. Talking about compilers, modern
environments, making all of the cases that folks have been making for years
to try and educate the masses that Lisp has actually changed a wee bit since
1960.
One reason Java is successful is because there quickly became a "right way"
to write the code. A good middle ground template that new users who didn't
necessarily understand it, could at least emulate and let the structure grow
on them. These users were more quickly successful with their code. Was the
Right Way perfect? Nope. But it was more than adequate, it was functional,
and pretty good first shot. As users got more experienced, they could break
free of the model and make their own path.
C++ can be taught in a similar way, a solid base of common code structure,
memory management, etc., leveraging C++ circa 2003 vs C++ circa 1990. While
not the 10/10ths of perfection, a heck of a lot better than what users hack
out of the forest on their own. "Better Practice" from the "Make it right,
then make it fast" point of view. But, it isn't. So, more hacking. More
slash and burn agriculture.
That's why folks don't use C++ better, because rather than standing on the
shoulders of Giants to learn their craft, they have to dig their way up out
of the burned out rubble of Bad Ideas and Bad Idioms of C++ history, but
they don't realize that until they're on top of the pile.
Most folks don't make the trip.
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> I have yet (not that I've looked real hard) found a good book on C++
> that teaches modern C++, assumes templates from the get go, teaching
> about smart pointers, etc. Where "Chapter 27 -- What are these other
> pointer things?" is common.
The closest I've seen is "Accelerated C++"� by Andrew Koenig and
Barbara E. Moo.
Footnotes:
� http://www.acceleratedcpp.com
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Will Hartung <·····@msoft.com> wrote:
> I have yet (not that I've looked real hard) found a good book on C++ that
> teaches modern C++, assumes templates from the get go, teaching about smart
> pointers, etc. Where "Chapter 27 -- What are these other pointer things?" is
> common.
_Accelerated C++_ by Koenig and Moo is pretty much what you're looking
for, and you'd find that out if you read the C++ version of this place
for a while (as I did). It's one of very few books on C++ that is both
aimed at novice programmers, and teaches the language in a way that
experienced coders don't laugh at.
·······@mindspring.com (Rayiner Hashem) writes:
>> Which makes me wonder why, oh why, Mr. Stroustrup decided to use C as a
>> starting. In my opinion, and for what it is worth, C++ is quite probably
>> the worst idea in the computer science field since its inception.
>
> That's not an entirely fair characterization. What about C++ disgusts
> you so much, and most importantly, what sort of applications have you
> used it for? In my experience, there are a few illegitimate reasons
> that people hate C++:
>
> 1) They're using it wrong.
This presupposes that there is a `right' way to use C++.
> 2) They're using it for the wrong sorts of problems.
They're probably making the mistake of using it for programming.
> Yes, this is the traditional, "you can't write a kernel in Lisp"
> argument.
Sure you can.
In fact, it's an awful lot easier than one might think.
> 3) They're using it in situations where the primary irritant is
> something other than C++. If you're stuck in a job programming MFC,
> you have a reason to be bitter, but not necessarily to hate C++ :)
I'm not a connaisseur of irritants. I'm afraid that the fine
distinctions between these irritations is lost on me.
From: Christopher C. Stacy
Subject: Re: ML predates C++ ...
Date:
Message-ID: <uu18dcw7i.fsf@dtpq.com>
>>>>> On 18 Aug 2003 18:31:00 -0700, Rayiner Hashem ("Rayiner") writes:
Rayiner> Yes, this is the traditional, "you can't write a kernel in
Rayiner> Lisp" argument. But heck, somebody has to write all those kernels, and
Rayiner> drivers, and network stacks, high-performance rendering engines, and
Rayiner> all the other infrastructure that VHLL (very-high-level-languages) can
Rayiner> just take for granted. They need a language that gives them precise
Rayiner> control of bit patterns, direct access to memory, and precise control
Rayiner> of memory allocation and deallocation. As somebody who is writing a
Rayiner> kernel in C++, I have to say C++ is a much better language for this
Rayiner> sort of work.
Apparently you are not aware that those things have
been done very well in Lisp, about 29 years ago.
(Unadorned ANSI Common Lisp is not quite up to it, though.)
From: Christopher C. Stacy
Subject: Re: ML predates C++ ...
Date:
Message-ID: <ufzjx400u.fsf@dtpq.com>
>>>>> On Tue, 19 Aug 2003 18:56:48 GMT, Christopher C Stacy ("Christopher") writes:
>>>>> On 18 Aug 2003 18:31:00 -0700, Rayiner Hashem ("Rayiner") writes:
Rayiner> Yes, this is the traditional, "you can't write a kernel in
Rayiner> Lisp" argument. But heck, somebody has to write all those kernels, and
Rayiner> drivers, and network stacks, high-performance rendering engines, and
Rayiner> all the other infrastructure that VHLL (very-high-level-languages) can
Rayiner> just take for granted. They need a language that gives them precise
Rayiner> control of bit patterns, direct access to memory, and precise control
Rayiner> of memory allocation and deallocation. As somebody who is writing a
Rayiner> kernel in C++, I have to say C++ is a much better language for this
Rayiner> sort of work.
Christopher> Apparently you are not aware that those things have
Christopher> been done very well in Lisp, about 29 years ago.
Christopher> (Unadorned ANSI Common Lisp is not quite up to it, though.)
(On the other hand, unadorned C/C++ is not quite up to compiling Linux.
Linux relies on non-standard language extensions to the GCC compiler,
and on knowing the particulars of how that compiler will implement
the program...)
> Christopher> Apparently you are not aware that those things have
> Christopher> been done very well in Lisp, about 29 years ago.
>
> Christopher> (Unadorned ANSI Common Lisp is not quite up to it, though.)
>
> (On the other hand, unadorned C/C++ is not quite up to compiling Linux.
> Linux relies on non-standard language extensions to the GCC compiler,
> and on knowing the particulars of how that compiler will implement
> the program...)
I'm aware that kernels have been written in Lisp, but I was speaking
of Lisps still in common use. IIRC, the Lisp kernels that existed were
written in a statically typed Lisp varient especially designed for the
task. On the other hand, unadorned C++ is quite up to writing kernels
in general. The Linux kernel's use of GCC extensions is historical
baggage more than anything else. Many kernels (such as Fiasco) have
been written in good ol' ISO '98 C++.
On Wed, Aug 20, 2003 at 11:47:12AM -0700, Rayiner Hashem wrote:
> I'm aware that kernels have been written in Lisp, but I was speaking
> of Lisps still in common use. IIRC, the Lisp kernels that existed were
> written in a statically typed Lisp varient especially designed for the
> task.
While it's true that the OSes on the Lisp machines predated Common Lisp,
and that they used Lisp dialects which are no longer in widespread use
today, I wouldn't say that they were so different from normal practice
at the time. Certainly not a ``statically typed Lisp variant especially
designed for the task.'' The Lisp machines had run-time type checking
support in hardware, remember. ZetaLisp was a MAC Lisp derivative,
after all.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
> While it's true that the OSes on the Lisp machines predated Common Lisp,
> and that they used Lisp dialects which are no longer in widespread use
> today, I wouldn't say that they were so different from normal practice
> at the time. Certainly not a ``statically typed Lisp variant especially
> designed for the task.'' The Lisp machines had run-time type checking
> support in hardware, remember. ZetaLisp was a MAC Lisp derivative,
> after all.
Check out this thread for some useful information on kernel Lisps:
http://lists.tunes.org/archives/lispos/1997-May/001412.html
These Lisps were very different from the usual Lisps used to program
applications. They were not just Lisp dialects which are no longer in
widespread use. Writing C style code in these Lisps is akin to using
something like FC++ or Lisp++ to do Lisp-style programming in C++.
From: Christopher C. Stacy
Subject: Re: ML predates C++ ...
Date:
Message-ID: <u7k574qia.fsf@dtpq.com>
>>>>> On 20 Aug 2003 18:15:12 -0700, Rayiner Hashem ("Rayiner") writes:
>> While it's true that the OSes on the Lisp machines predated Common Lisp,
>> and that they used Lisp dialects which are no longer in widespread use
>> today, I wouldn't say that they were so different from normal practice
>> at the time. Certainly not a ``statically typed Lisp variant especially
>> designed for the task.'' The Lisp machines had run-time type checking
>> support in hardware, remember. ZetaLisp was a MAC Lisp derivative,
>> after all.
Rayiner> Check out this thread for some useful information on kernel Lisps:
Rayiner> http://lists.tunes.org/archives/lispos/1997-May/001412.html
Rayiner> These Lisps were very different from the usual Lisps used to program
Rayiner> applications. They were not just Lisp dialects which are no longer in
Rayiner> widespread use. Writing C style code in these Lisps is akin to using
Rayiner> something like FC++ or Lisp++ to do Lisp-style programming in C++.
Being one of the people who helped write the operating systems in
question, I can assure you that you are very confused.
·······@mindspring.com (Rayiner Hashem) writes:
> Check out this thread for some useful information on kernel Lisps:
> http://lists.tunes.org/archives/lispos/1997-May/001412.html
For information about early Lisp Machines:
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-444.pdf
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-528.pdf
--
Lars Brinkhoff, Services for Unix, Linux, GCC, PDP-10, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
·······@mindspring.com (Rayiner Hashem) writes:
> Check out this thread for some useful information on kernel Lisps:
> http://lists.tunes.org/archives/lispos/1997-May/001412.html
> These Lisps were very different from the usual Lisps used to program
> applications. They were not just Lisp dialects which are no longer in
> widespread use.
If you are referring to the language called LIL in
http://lists.tunes.org/archives/lispos/1997-May/001415.html
note that it was just for programming embedded processors, not for the
kernel of the Lisp Machine.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, PDP-10, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
·······@mindspring.com (Rayiner Hashem) writes:
> Check out this thread for some useful information on kernel Lisps:
> http://lists.tunes.org/archives/lispos/1997-May/001412.html
> These Lisps were very different from the usual Lisps used to program
> applications. They were not just Lisp dialects which are no longer in
> widespread use. Writing C style code in these Lisps is akin to using
> something like FC++ or Lisp++ to do Lisp-style programming in C++.
Huh? I just browsed the thread and I didn't see an awful lot code.
The one snippet I did see was this:
(define %%unchecked-vector-ref
(%%low-level-lambda (v n)
(%%vector:read-barrier v)
(%%peek (%%fixnum:+ v n))))
The biggest difference I see between this and Common Lisp is that it's
using a Scheme-like definition syntax. If it were this:
(defun (%%unchecked-vector-ref vector offset)
(declare (compiler:subprimitive))
(%%check-pointer-read
(%%mem-ref-offset
(%%object->machine-address vector)
offset)))
Then it is pretty much indistinguishable from Common Lisp. In fact, I
can take that above snippet I just wrote, and either the Allegro
Common Lisp compiler, the Xanalys LispWorks Compiler, or the Corman
Common Lisp compiler (and probably the CMUCL compiler, though I
haven't played with it sufficiently to know offhand), and with the
appropriate support macros, generate a real runnable function that
contains the one or two machine instructions that one would expect.
Take a look at the instruction set of a processor. In general, an
instruction is parameterized by a set of inputs and a target. On a
RISC machine, these are usually a set of registers, and on a CISC
machine they are often more complicated. A Lisp value is an
abstraction over a bit pattern. It's the usual practice to ensure
that a lisp value fits in a register (in most compiled
implementations. You can do it differently.) A Lisp *variable*
therefore is an abstraction over where you can store the contents of a
register. One of those places being an actual register, the other
being somewhere in memory or on the stack.
So you can model each individual machine instruction as a primitive
lisp function that takes arguments. The compiler can come up with a
mapping between the arguments and registers; that's what compilers are
good at. So you take your instruction set and map it onto a set of
lisp primitives. Then you simply call the functions.
There are, of course, some restrictions. This would be nonsensical
(or at least quite likely to crash the machine):
(map 'list #'%%object->machine-address vector)
> task. On the other hand, unadorned C++ is quite up to writing kernels
> in general. The Linux kernel's use of GCC extensions is historical
> baggage more than anything else. Many kernels (such as Fiasco) have
> been written in good ol' ISO '98 C++.
Clue: "unadorned".
According to the FAQ for Fiasco, it claims to run only on x86 machines
from the 486 onwards. I've not paid much attention to C++ lately, but
I'd still be surprised to learn that the cr0 register is now part of
the standard language.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
> Clue: "unadorned".
>
> According to the FAQ for Fiasco, it claims to run only on x86 machines
> from the 486 onwards. I've not paid much attention to C++ lately, but
> I'd still be surprised to learn that the cr0 register is now part of
> the standard language.
>
The 'asm' keyword is part of standard C++. You can write the assembly
instructions you need inline. And even if asm wasn't a keyword, you
could build the exact byte patterns to write the registers (not that
hard of a task, actually) and jump to that data block. Its a bit of a
hack, yes, and nobody would do it in practice, but then again, you are
being facetious with your comment...
·······@mindspring.com (Rayiner Hashem) writes:
> The 'asm' keyword is part of standard C++. You can write the assembly
> instructions you need inline. And even if asm wasn't a keyword, you
And this helps how exactly? You still need to make assumptions about
the host environment above and beyond the guarantees you have from the
C++ standard. What a valid assembly instruction looks like, for one.
"Unadorned." Please try to understand.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Christopher C. Stacy
Subject: Re: ML predates C++ ...
Date:
Message-ID: <ubruj4qk0.fsf@dtpq.com>
>>>>> On 20 Aug 2003 11:47:12 -0700, Rayiner Hashem ("Rayiner") writes:
Christopher> Apparently you are not aware that those things have
Christopher> been done very well in Lisp, about 29 years ago.
>>
Christopher> (Unadorned ANSI Common Lisp is not quite up to it, though.)
>>
>> (On the other hand, unadorned C/C++ is not quite up to compiling Linux.
>> Linux relies on non-standard language extensions to the GCC compiler,
>> and on knowing the particulars of how that compiler will implement
>> the program...)
Rayiner> I'm aware that kernels have been written in Lisp, but I was
Rayiner> speaking of Lisps still in common use. IIRC, the Lisp
Rayiner> kernels that existed were written in a statically typed Lisp
Rayiner> varient especially designed for the task
I don't know what you think you are remembering, but the
operating systems were written in a superset of what became
known as "Common Lisp".
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 20 Aug 2003 11:47:12 -0700, Rayiner Hashem ("Rayiner") writes:
>
> Christopher> Apparently you are not aware that those things have
> Christopher> been done very well in Lisp, about 29 years ago.
> >>
> Christopher> (Unadorned ANSI Common Lisp is not quite up to it, though.)
> >>
> >> (On the other hand, unadorned C/C++ is not quite up to compiling Linux.
> >> Linux relies on non-standard language extensions to the GCC compiler,
> >> and on knowing the particulars of how that compiler will implement
> >> the program...)
>
> Rayiner> I'm aware that kernels have been written in Lisp, but I was
> Rayiner> speaking of Lisps still in common use. IIRC, the Lisp
> Rayiner> kernels that existed were written in a statically typed Lisp
> Rayiner> varient especially designed for the task
>
> I don't know what you think you are remembering, but the
> operating systems were written in a superset of what became
> known as "Common Lisp".
I'm not reading this whole thread but just glanced in and saw this
post and wanted to some credential/weight to what Chris (CStacy) says
here. He and I shared an office at the MIT AI Lab at the time, just
downstairs from where the operating systems he's talking about were
designed. Because his name doesn't appear in the literature, I often
see him making statements that get assumed by some to be just another
voice in the wilderness rather than someone who "was personally
there". It's discouraging to watch him make very helpful statements
from a first-person point of view about what happened only to be
improperly contradicted by someone else who I, at least, never heard
of and who is spouting stuff that is in seeming contradiction of
history.
(And, incidentally, it's most commonly the case that such historical
revisionism seems to contain the hint of a mistaken idea that C/Unix
is the start of the universe and that there was nothing in the world
before that, as if the entire history of the present-day computational
Universe arrived fully formed in the late 70's and early 80's ... and
as if everything about those things you see today are monotonic
intellectual improvements over previous tools rather than just a bunch
of happy-go-lucky tools that happened to have the good fortune to ride
on the coat-tails of an operating system that was mostly just in the
right place at the right time... There's a lot more "sheer luck" in
survival of many things than people are prone to admit. The winners
like to believe they survived for a principled reason and that the
losers lost for an equally principled reason. Sometimes, maybe, but
not nearly as often as some would have us believe...)
Chris and I were not designers of the Lisp Machines in the early days;
we were a second-generation group that came in as users toward the
time of the initial roll-out, and we each worked for Lisp Machine
companies in various roles later. Chris has devoted considerable time
and attention to the ongoing use, study, and history preservation
related to Lisp Machines (and other early operating systems and
technology the memory of which is at the sad risk today of being
lost), and I personally give strong credence to what he says about
their nature. He and I routinely cross-check memories of details
and/or actual historical document references through each other's
personal libraries.
The implementation dialect, Zetalisp, was indeed dynamically typed,
not statically typed, and is extremely similar to Common Lisp. In the
latter days of Symbolics, Zetalisp was transformed into Symbolics
Common Lisp, which indeed was a superset of the original (CLTL) Common
Lisp specification. To the extent that any part of the operating
system was retained in ZL, the distinctions were generally minor and
syntactic in nature, not any major semantic differences such as seem
be alluded to by Rayiner's remark above, referring to any long-dead
"statically typed Lisp". That covers the series of Lisp machines
sometimes called the "Lisp Machine family", which was developed at MIT
and later sold by Lisp Machines Incorporated (LMI) [and later
Gigamos], Texas Instruments, and Symbolics. Sure it's true that the
Lisp Machine implementation dialect was "especially designed for the
task"; but no, it's not true that 'staticness' had anything to do with
that.
> Which makes me wonder why, oh why, Mr. Stroustrup decided to use C as a
> starting. In my opinion, and for what it is worth, C++ is quite probably
> the worst idea in the computer science field since its inception.
Clearly you haven't seen intercal...
>> Which makes me wonder why, oh why, Mr. Stroustrup decided to
>> use C as a starting. In my opinion, and for what it is worth,
>> C++ is quite probably the worst idea in the computer science
>> field since its inception.
Michael> Clearly you haven't seen intercal...
Well, there's "bad", like that stuff growing in the back of the
fridge, and "bad" as in "Plan 9 from Outer Space" bad. I'd rank
Intercal with the latter, because it's intended to be funny.
Tim Lavoie schrieb:
> ... "Plan 9 from Outer Space" ...
hallo Tim Lavoie
Do you mean Plan 9 as the OS? I saw this on
http://palm9.bell-labs.com/plan9dist/
"Plan 9 began in the late 1980's to build a system that was centrally
administered and cost-effective using cheap modern
microcomputers as its computing elements. The idea was to build a
time-sharing system out of workstations, but in a novel way.
Different computers would handle different tasks: small, cheap
machines in people's offices would serve as terminals providing
access to large, central, shared resources such as computing
servers and file servers."
When yes, can you tell something about? Is it a good idea to download
and install the Plan9 or is it bugy and not ready for use? (I have some
old 486CPUs here and plan to cluster it)
stefan
lin8080 <·······@freenet.de> writes:
> Tim Lavoie schrieb:
>
> > ... "Plan 9 from Outer Space" ...
>
> hallo Tim Lavoie
>
> Do you mean Plan 9 as the OS? I saw this on
> http://palm9.bell-labs.com/plan9dist/
No, he referred to the Ed Wood movie _Plan 9 from Outer Space_, which (IIRC)
was voted Worst Movie Of All Time at one point. Its history is explained
in Tim Burton's movie _Ed Wood_, which is hilarious.
--
··········@acm.org phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
As the air to a bird, or the sea to a fish,
so is contempt to the contemptible. [Blake]
Jens Kilian <···········@agilent.com> wrote:
+---------------
| lin8080 <·······@freenet.de> writes:
| > Tim Lavoie schrieb:
| > > ... "Plan 9 from Outer Space" ...
| >
| > hallo Tim Lavoie
| >
| > Do you mean Plan 9 as the OS? I saw this on
| > http://palm9.bell-labs.com/plan9dist/
|
| No, he referred to the Ed Wood movie _Plan 9 from Outer Space_, which (IIRC)
| was voted Worst Movie Of All Time at one point. Its history is explained
| in Tim Burton's movie _Ed Wood_, which is hilarious.
+---------------
Indeed, it's so bad it's almost good!! It's become a cult classic.
It should be noted that "Plan 9 from Bell Labs" (the operating system)
was named as a homage to "Plan 9 from Outer Space" (the movie). There
are a number of other movie references in Plan 9 (the OS), too, such as
"8�", an earlier window system in Plan 9 (the OS) [replaced by "rio"],
which is a reference to the movie of the same same.
-Rob
p.s. Small typo correction: <URL:http://plan9.bell-labs.com/plan9dist/>
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <······················@speakeasy.net>, Rob Warnock
<····@rpw3.org> wrote:
> Jens Kilian <···········@agilent.com> wrote:
> +---------------
> | lin8080 <·······@freenet.de> writes:
> | > Tim Lavoie schrieb:
> | > > ... "Plan 9 from Outer Space" ...
> | >
> | > hallo Tim Lavoie
> | >
> | > Do you mean Plan 9 as the OS? I saw this on
> | > http://palm9.bell-labs.com/plan9dist/
> |
> | No, he referred to the Ed Wood movie _Plan 9 from Outer Space_, which (IIRC)
> | was voted Worst Movie Of All Time at one point. Its history is explained
> | in Tim Burton's movie _Ed Wood_, which is hilarious.
> +---------------
>
> Indeed, it's so bad it's almost good!! It's become a cult classic.
>
> It should be noted that "Plan 9 from Bell Labs" (the operating system)
> was named as a homage to "Plan 9 from Outer Space" (the movie). There
> are a number of other movie references in Plan 9 (the OS), too, such as
> "8�", an earlier window system in Plan 9 (the OS) [replaced by "rio"],
> which is a reference to the movie of the same same.
Personally I found "Ed Wood" to be a more enjoyable way of watching
"Plan 9" than "Plan 9" itself. Some movies are so bad they're good.
"Plan 9" is worse than that.
"HPL" <··············@yahoo.com> writes:
> On Mon, 18 Aug 2003 22:56:15 +0200, Sam Zoghaib wrote:
>
>> C++ is not C version 2. People coding with that definition in mind are likely
>> to be bad C++ coders. C++ is a totally different language in its philosophy
>> and design; IMO, it's as difficult to go from C to C++ and code well, than
>> from C to Lisp.
>
> Which makes me wonder why, oh why, Mr. Stroustrup decided to use C as a
> starting. In my opinion, and for what it is worth, C++ is quite probably
> the worst idea in the computer science field since its inception.
That's quite an honor to bestow on C++, but I'd have to think really
hard if I had to choose between it and Perl. There are so many other
really rotten ideas, too: sendmail, unix, XML + its attendent crap,
nfs, etc.
Joe Marshall <···@ccs.neu.edu> writes:
> "HPL" <··············@yahoo.com> writes:
>> starting. In my opinion, and for what it is worth, C++ is quite probably
>> the worst idea in the computer science field since its inception.
>
> That's quite an honor to bestow on C++, but I'd have to think really
> hard if I had to choose between it and Perl. There are so many other
> really rotten ideas, too: sendmail, unix, XML + its attendent crap,
> nfs, etc.
m4. On its own this is debatable, but when you take into account that
it also
- gives sendmail developers an excuse to continue using sendmail.cf
syntax
- forms the basis of the auto* tools
I think it's hard not to give it at least a top five placing.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Sam Zoghaib <·····@zep.homedns.orgSPAM> writes:
> Doug Tolton wrote in article <··································@4ax.com> on
> Monday 18 August 2003 21:32 in comp.lang.lisp:
>
> > Quite a few of the (quote
> > C++) programs are really just C programs, because they don't make use
> > of the C++ features. It's a lot easier both politically and mentally
> > to switch to version 2 of a language instead of switching to an
> > entirely new language, let alone an entirely different paradigm.
> >
>
> C++ is not C version 2. People coding with that definition in mind are likely
> to be bad C++ coders. C++ is a totally different language in its philosophy
> and design; IMO, it's as difficult to go from C to C++ and code well, than
> from C to Lisp.
Absolutely true. But none of this detracts from the thesis that C++'s
current popularity is largely a direct consequence of it being an
extension of C.
Sam Zoghaib <·····@zep.homedns.orgSPAM> writes:
> Doug Tolton wrote in article <··································@4ax.com> on
> Monday 18 August 2003 21:32 in comp.lang.lisp:
>
> > Quite a few of the (quote
> > C++) programs are really just C programs, because they don't make use
> > of the C++ features. It's a lot easier both politically and mentally
> > to switch to version 2 of a language instead of switching to an
> > entirely new language, let alone an entirely different paradigm.
> >
>
> C++ is not C version 2.
Sure it is. For at least a dozen years C++ was explicitly an
extension to C where you could directly import C code simply by
avoiding a few keywords.
C++ may no longer be *just* an extension to C, but imho it very much
*is* C version 2.
This is just like when talking about the US civil war, the first big
lie is that it wasn't about slavery and the second is that it was all
about slavery.
> People coding with that definition in mind are likely to be bad C++
> coders.
Now you're just quibbling about style.
> C++ is a totally different language in its philosophy and design;
> IMO, it's as difficult to go from C to C++ and code well, than from
> C to Lisp. The former might even be more difficult, because you have
> to not fall in the trap of "C++ is C v. 2". And being aware of that
> trap doesn't mean you don't fall in it sometimes.
> Now, if by "switching", you mean being able to write a program that
> runs, well, yes, the first solution may be easier. That's not enough
> for me, though.
You have a style quibble -- I see I was right.
This should go without saying but since you obviously don't subscribe
to it, i'll state: If the C++ standard accepts it and it does what you
expect it is *by definition* C++.
> Which is why I think the original post asks the wrong question. The
> real question would be "Why isn't [ML/Lisp/whatever language that
> predates C++ and does a good job at OOP] used instead of C++". C++
> is not a replacement for C.
Well, you couldn't transparently port stuff you were doing in the
popular language of the day C into *ML. I think that's enough.
--
Johan KULLSTAM <··········@comcast.net> sysengr
>
> Now you're just quibbling about style.
>
Yes, he's quibbling about style. But saying that "doing C programming
in C++" is a style quibble, is like saying that "(/ 1 0)" in Lisp is a
style quibble. Both are synactically correct, but both are clearly
wrong. And both sound equally ridiculous to experienced programmers in
each language...
·······@mindspring.com (Rayiner Hashem) writes:
> >
> > Now you're just quibbling about style.
> >
>
> Yes, he's quibbling about style. But saying that "doing C programming
> in C++" is a style quibble, is like saying that "(/ 1 0)" in Lisp is a
> style quibble. Both are synactically correct, but both are clearly
> wrong. And both sound equally ridiculous to experienced programmers in
> each language...
(/ 1 0) isn't a style problem. It isn't anything like a style issue.
Please explain why you think that it would be a style issue.
Whether to use LOOP or not is a Lisp style issue. I choose to use it
because I find its usefulness outweighs its ugly looks. This is also
why I have no qualms about writing C like code in C++.
Lisp supports many programming styles. You can use a functional
style, an object oriented style and even an imperative style in Lisp
(this list is not exhaustive). You are free to mix them if you like.
Choosing a style is based on what you feel comfortable with and what
suits the application. Maybe Lisp supports functional and OO better
than imperative, but that's OK. I'll still use an imperative style
once in a while if that is what works for me.
You can do some sort of OO in C++; it was developed specially to give
an OO capability to C. You still don't have to use OO to use C++.
There are plenty of non-OO features in C++ which give some advantage
over C. I maintain that it is totally appropriate to program C++ in
an imperative, non-OO manner depending upon your application.
Forcing OO and a certain C++ style is like those cretinous Lisp
exersizes where you are not allowed use MAPCAR.
Why are C++ people so concerned that you write in some crazy style?
Is it out of fear that the emperor has no clothes?
--
Johan KULLSTAM <··········@comcast.net> sysengr
> (/ 1 0) isn't a style problem. It isn't anything like a style issue.
> Please explain why you think that it would be a style issue.
It's called sarcasm. This sub-thread started when someone said that
many of the perceived problems with C++ stem from people trying to
write C-style code in C++. Someone responded that writing C-style code
in C++ is just a style issue, and that if a language allows it, its
acceptable code. My point was that if you consider using unsafe casts,
pointer arithmatic, raw arrays, raw pointers, etc, to be style issues,
then you should consider something like (/ 1 0) to be a style issue
too. They are clearly *not* style issues, but just bad programming.
> Whether to use LOOP or not is a Lisp style issue. I choose to use it
> because I find its usefulness outweighs its ugly looks. This is also
> why I have no qualms about writing C like code in C++.
If you want to write C-like code, don't bitch when it blows up on you.
All the low-level features of C++ are there for a reason, because you
might *need* to use them. If you don't have an absolute need to use
them, then use safer mechanisms. Now, this isn't really a style thing,
its a safety thing. You can write procedural code in C++ just fine
using shared pointers and STL containers.
The main problem that C++ people have with people complaining about
C++ is that they are not legitimate complaints. There are lots of
legitimate complaints (verbosity, ugly syntax, lack of orthogonality,
lack of type inference, etc) but the standard ones (lack of type
safety, memory leaks, etc) are non-issues. One doesn't write
int* foo = new int; instead of shared_ptr<int> foo(new int); by
accident. You do the former when you really need a direct pointer to a
machine integer, and are willing to put up with the possibility of a
memory leak. You do the latter in all other cases. Writing former vs
the latter (when you don't absolutely need the former) is not a
stylistic issue. Its wrong code vs correct code.
·······@mindspring.com (Rayiner Hashem) writes:
> > (/ 1 0) isn't a style problem. It isn't anything like a style issue.
> > Please explain why you think that it would be a style issue.
> It's called sarcasm. This sub-thread started when someone said that
> many of the perceived problems with C++ stem from people trying to
> write C-style code in C++. Someone responded that writing C-style code
> in C++ is just a style issue, and that if a language allows it, its
> acceptable code. My point was that if you consider using unsafe casts,
> pointer arithmatic, raw arrays, raw pointers, etc, to be style issues,
> then you should consider something like (/ 1 0) to be a style issue
> too. They are clearly *not* style issues, but just bad programming.
Ah, now I understand where you're coming from. You are coming from
the position that coding in C style (as opposed to C++ style) is
equivalent to bad programming. It was hard to see at first, but now
it all fits into place, including the claim that C++ is not an extension
of C (it may no longer be, but it certainly started out that way; I
have Stroustrup's original C++ book which claims in its Historical Notes
section: "C is retained as a subset, and so is C's emphasis on facilities
that are low-lwvel enough to cope with the most demanding systems
programming tasks." ["The C++ Programming Language", Stroustrup, 1986
Addison Wesley]
As a long-time C programmer (long before C++ existed), and currently
residing in a shop where the majority of our base product is written
in lisp, but the other 2% is written in C (not C++), I can say that it
is definitely possible to write good, portable C code, in a C style,
and to stay away from C++ style. Our product has to compile on many
platforms, and the C portion of it compiles portably on platforms
which have only C++ and on platforms which might have C and C++ (for
those platforms we use the C compilers). There are some conditionals,
on platforms where the main() must be compiled with C++ in order to
do the proper class initializations, we compile in some `extern "C" '
statements. But the rest of the C code is fully compatible, coded
in C style, and _not_ bad programming.
> > Whether to use LOOP or not is a Lisp style issue. I choose to use it
> > because I find its usefulness outweighs its ugly looks. This is also
> > why I have no qualms about writing C like code in C++.
> If you want to write C-like code, don't bitch when it blows up on you.
I don't bitch, I debug. Just as I presume you debug your C++ code
when it blows up on you.
> All the low-level features of C++ are there for a reason, because you
> might *need* to use them.
Of course. As seen in the quote above, Stroutrup identified these
features as features of C which C++ retained.
> If you don't have an absolute need to use
> them, then use safer mechanisms. Now, this isn't really a style thing,
> its a safety thing. You can write procedural code in C++ just fine
> using shared pointers and STL containers.
I can write procedural code in C just fine, thankyouverymuch. And
I don't need STL.
> The main problem that C++ people have with people complaining about
> C++ is that they are not legitimate complaints. There are lots of
> legitimate complaints (verbosity, ugly syntax, lack of orthogonality,
> lack of type inference, etc) but the standard ones (lack of type
> safety, memory leaks, etc) are non-issues. One doesn't write
> int* foo = new int; instead of shared_ptr<int> foo(new int); by
> accident. You do the former when you really need a direct pointer to a
> machine integer, and are willing to put up with the possibility of a
> memory leak. You do the latter in all other cases. Writing former vs
> the latter (when you don't absolutely need the former) is not a
> stylistic issue. Its wrong code vs correct code.
I have many complaints about C++ including the brittle-class problem,
but my biggest gripe about it is name mangling. Not only is mangling
opaque, grotesque, and nonportable, making it hard to do any external
interfacing to C++ operators, but as I understand it, the designers
of the spec actually recommended to vendors that they explicitly
use different mangling techniques, so that nobody would be tempted to
use mangled names externally (I don't remember where I heard this -
it could be heresay, but it is well-borne out in actual practice; I
don't know of two C++ mangling techniques which are the same).
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
I'm not saying that C programming is bad programming. I'm saying that
C programming in C++ is a bad thing! Look at it this way:
C is a low-level systems programming language.
Lisp is a high-level application programming language.
C++ has both low and high level elements.
Now, if you program low-level C++, don't compare it to high-level Lisp
and then complain that C++ is complicated/unsafe/whatever.
In article <····························@posting.google.com>,
·······@mindspring.com (Rayiner Hashem) wrote:
> I'm not saying that C programming is bad programming. I'm saying that
> C programming in C++ is a bad thing! Look at it this way:
>
> C is a low-level systems programming language.
> Lisp is a high-level application programming language.
> C++ has both low and high level elements.
No, C++ has a bunch of high-level looking cruft piled on top of a bunch of
low-level cruft.
C++ for all its vaunting of being a high-level object-oriented language
doesn't even have a proper concept of what an object is! If you pass an
objec to a function you don't get the object, you get a (shallow) copy of
that object. This completely undermines the whole concept of
object-oriented programming because objects don't retain their identity
across function calls.
The truly horrible brokenness of C++ is almost beyond comprehension.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> C++ for all its vaunting of being a high-level object-oriented language
> doesn't even have a proper concept of what an object is! If you pass an
> objec to a function you don't get the object, you get a (shallow) copy of
> that object.
What do you mean?
void f(Object& o) {
}
should get you the same object.
void f(Object o) {
}
gets you a copy with either user-defined copy semantics, or a
a good-for-many-purposes, shallow default copy.
--
I'm awfully glad I'm a Beta, because I don't work so hard.
In article <···············@rescomp.Stanford.EDU>, Brian Palmer
<·······@rescomp.Stanford.EDU> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > C++ for all its vaunting of being a high-level object-oriented language
> > doesn't even have a proper concept of what an object is! If you pass an
> > objec to a function you don't get the object, you get a (shallow) copy of
> > that object.
>
> What do you mean?
> void f(Object& o) {
> }
> should get you the same object.
>
> void f(Object o) {
>
> }
> gets you a copy with either user-defined copy semantics, or a
> a good-for-many-purposes, shallow default copy.
No. Passing an object is not the same thing as passing a reference to an
object. (Hint: it has to do with assignment.) It is not actually
possible to pass an object (only a copy of an object or a reference to an
object) as a parameter to a function in C++. (It is possible to emulate
the passing of an object as parameter, but it's very hard. I doubt one
C++ programmer in 1000 could do it properly.)
E.
In article <···············@rescomp.Stanford.EDU>,
Brian Palmer <·······@rescomp.Stanford.EDU> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > C++ for all its vaunting of being a high-level object-oriented language
> > doesn't even have a proper concept of what an object is! If you pass an
> > objec to a function you don't get the object, you get a (shallow) copy of
> > that object.
>
> What do you mean?
> void f(Object& o) {
> }
> should get you the same object.
>
> void f(Object o) {
>
> }
> gets you a copy with either user-defined copy semantics, or a
> a good-for-many-purposes, shallow default copy.
Object identity is mainly used for getting at the properties of an
object and for storing references to it. Both uses are not covered by
the latter option. (And besides, shallow copy is not a good choice for
the default semantics of a copy operation. See http://citeseer.nj.nec.com/grogono00copying.html )
The first option lets you get at the properties of object o. However,
things get problematic when you want to store a reference to it. Who is
going to take care of the memory management? Why do I even need to think
about memory management when I want to do OOP?
To put it like this: The lack of automatic memory managements means that
the language doesn't give you enough guarantees wrt object identity. So
at least it's fair to state that C++ fails to properly support OOP in
this regard.
Pascal
Pascal Costanza <········@web.de> writes:
> The first option lets you get at the properties of object
> o. However, things get problematic when you want to store a
> reference to it. Who is going to take care of the memory management?
I can only answer by way of idiom and convention, but if some caller
offers a reference to a by-definition existant object, then the callee
does not manage that object's lifetime. The caller guarantees that the
referenced object will live long enough for the callee to use it.
Taking an argument by reference means that the callee is not
interested in managing the argument's lifetime. The referenced object
must be preexistent; other than that, no guarantees can be made about
how long the object will live after the function call.
If the callee is to assume responsibility for the object's lifetime,
then the function should demand its argument as a
std::auto_ptr<Object> (or perhaps boost::shared_ptr<Object>). That
communicates and assists proper ownership transfer (or sharing).
> Why do I even need to think about memory management when I want to
> do OOP?
You don't need to think about it in C++ if you create your objects as
automatic variables. Granted, some data structures and object
relationships aren't amenable to this style of programming.
I freely admit that most programs are harder to write in C++ than
Common Lisp, but that's not because of memory management or object
identity problems. Yes, these aspects are different in C++ than Lisp
and warrant some attention, but they do not inhibit an experienced C++
programmer. Part of becoming an experienced C++ programmer is
mastering these aspects so that they disappear. They only look like
big problems from the outside, and, some cruft aside, I don't see how
they inhibit employing OOP ideas.
Criticizing C++ for its manual memory management choices is like
criticizing a race car for having a manual transmission. Beyond
steering control, throttle, and brakes, the manual transmission adds
another form of control, enabling driving that may not be possible
with an automatic transmission. The driver has a little more to
contend with, but the good drivers wouldn't trade that manual
transmission out. They've gotten beyond struggling with it and now
consider it an asset.
I'm not criticizing garbage collection, but I don't think C++ suffers
for lack of it. Just as one can't translate C++-friendly solutions
directly into Lisp without missing something, one shouldn't try to go
the other way. Solutions that demand more than boost::shared_ptr<>
probably belong in a different language.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
In article <···············@raytheon.com>, Steven E. Harris
<········@raytheon.com> wrote:
> I can only answer by way of idiom and convention, but if some caller
> offers a reference
That is non-sensical. It is not the caller that offers a reference, it is
the calle that demands a reference. In fact, f(x) could be passing x by
value today, and by reference tomorrow if someone else is maintaining the
code for f. The caller has no way of knowing.
> You don't need to think about it in C++ if you create your objects as
> automatic variables. Granted, some data structures and object
> relationships aren't amenable to this style of programming.
There are lots of things that you don't need to worry about if all you
ever write is trivial code.
> I freely admit that most programs are harder to write in C++ than
> Common Lisp, but that's not because of memory management or object
> identity problems. Yes, these aspects are different in C++ than Lisp
> and warrant some attention, but they do not inhibit an experienced C++
> programmer. Part of becoming an experienced C++ programmer is
> mastering these aspects so that they disappear. They only look like
> big problems from the outside, and, some cruft aside, I don't see how
> they inhibit employing OOP ideas.
Hello! The WHOLE POINT of using a high level language is so that you
don't have to "master these aspects so they disappear"! But C++ isn't a
high-level language, so naturally a C++ programmer wouldn't understand
this.
These arguments are no different from the ones made by assembly programer
in the 1950's arguing against the use of Fortran. "I freely admit that
most programs are harder to write in assembler than Fortran. But that's
not because of register allocation problems. Yes, these aspects are
different in assembler than Fortran, and warrant some attention, but they
do not inhibit an experienced assembly programmer. Part of becoming an
experienced assembly programmer is mastering these aspects so they
disaappear. They only look like big problems from the outside, and, some
cruft aside, I don't see how they inhibit employing mathematical ideas."
(And besides, humans will always be better at register allocation than any
compiler.)
It was a bogus argument then, and it's still a bogus argument today.
> Criticizing C++ for its manual memory management choices is like
> criticizing a race car for having a manual transmission. Beyond
> steering control, throttle, and brakes, the manual transmission adds
> another form of control, enabling driving that may not be possible
> with an automatic transmission. The driver has a little more to
> contend with, but the good drivers wouldn't trade that manual
> transmission out. They've gotten beyond struggling with it and now
> consider it an asset.
My mom drove a manual transmission most of her life until circumstances
forced her to try an automatic. Now she regrets not having switched
sooner.
The extra control afforded by a manual transmission provides only a
marginal benefit at best in 99% of driving situations (even many racers
prefer automatics noawadys).
Personally, I prefer a tiptronic.
> I'm not criticizing garbage collection, but I don't think C++ suffers
> for lack of it.
True. It is C++ *programmers* who suffer for the lack of it.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <···············@raytheon.com>, Steven E. Harris
> > Criticizing C++ for its manual memory management choices is like
> > criticizing a race car for having a manual transmission. Beyond
> > steering control, throttle, and brakes, the manual transmission adds
> > another form of control, enabling driving that may not be possible
> > with an automatic transmission.
[...]
> The extra control afforded by a manual transmission provides only a
> marginal benefit at best in 99% of driving situations (even many racers
> prefer automatics noawadys).
Bad analogy. Manual shifting is *fun*. Manual memory management is annoyingly
tedious and error prone.
I do admit however, that driving a standard in stop and go rush-hour traffic
can be a pain too.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
"Ray Blaak" <········@STRIPCAPStelus.net> wrote in message
··················@STRIPCAPStelus.net...
> ···@jpl.nasa.gov (Erann Gat) writes:
> Bad analogy. Manual shifting is *fun*. Manual memory management is
annoyingly
> tedious and error prone.
>
> I do admit however, that driving a standard in stop and go rush-hour
traffic
> can be a pain too.
Precisely, it's fun in trivial situtions, but as the cognitive load of the
environment intrudes upon the driver, then shifting becomes a pain in the
ass. In critical situations, it can be even worse. God help the poor parent
rushing their child to the hospital on the verge of panic having to fight a
missed shift.
So, manual memory mangament is an amusing thought exercise, but in
complicated systems, it quickly becomes a burden, and in critical
situations, it can become a PANIC.
Regards,
Will Hartung
(·····@msoft.com)
On Fri, Aug 22, 2003 at 11:56:49AM -0700, Will Hartung wrote:
> "Ray Blaak" <········@STRIPCAPStelus.net> wrote in message
> ··················@STRIPCAPStelus.net...
> > ···@jpl.nasa.gov (Erann Gat) writes:
> > Bad analogy. Manual shifting is *fun*. Manual memory management is
> annoyingly
> > tedious and error prone.
> >
> > I do admit however, that driving a standard in stop and go rush-hour
> traffic
> > can be a pain too.
>
> Precisely, it's fun in trivial situtions, but as the cognitive load of the
> environment intrudes upon the driver, then shifting becomes a pain in the
> ass. In critical situations, it can be even worse. God help the poor parent
> rushing their child to the hospital on the verge of panic having to fight a
> missed shift.
The trouble with this scenario is that changing gears in a manual
transmission is not a task requiring great amounts of precision from the
typical driver. For any given speed between a standstill and maximum
non-inclusive, there are at least 3 or 4 gears which can be used to
drive the car without causing undue stress on the engine. Also, the
great majority of the time spent driving is spent in gear, not in
neutral or changing. Critical situations, such as making a turn across
3 lanes of traffic, can be stressful for a beginner, but an experienced
driver knows how not to stall when it is important. I'm not sure
exactly what you mean by a ``missed shift'' but, as I outlined before,
neglecting to change gears is not a disaster; it just changes the
balance on certain variables which you may not even care about
(acceleration, fuel economy, noise, etc).
> So, manual memory mangament is an amusing thought exercise, but in
> complicated systems, it quickly becomes a burden, and in critical
> situations, it can become a PANIC.
Memory management is a much more complicated conceptually than manual
transmission; where the primary skill is getting a good feel for the
clutch and the sound of the engine. Manual transmission, like other
mechanical engineering systems, has a wide margin of error. Memory
management, like other computer science issues, has no margin of error.
I think that any analogy between the two is fundamentally flawed because
of that difference.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> Memory management is a much more complicated conceptually than manual
> transmission; where the primary skill is getting a good feel for the
> clutch and the sound of the engine. Manual transmission, like other
> mechanical engineering systems, has a wide margin of error. Memory
> management, like other computer science issues, has no margin of error.
Right. Also, the decision as to when to change gear can be made
entirely with only local knowledge: you don't need to know what's
happening thirty miles away, or will happen in half an hour's time.
This is as distinct from memory management decisions, which have
whole-program implications - stalling the car by attempting to drive
away in third may be embarrasing, but it doesn't cause the wheels to
fall off eighty miles down the road.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Matthew Danish <·······@andrew.cmu.edu> writes:
> Memory management is a much more complicated conceptually than manual
> transmission; where the primary skill is getting a good feel for the
> clutch and the sound of the engine. Manual transmission, like other
> mechanical engineering systems, has a wide margin of error. Memory
> management, like other computer science issues, has no margin of error.
> I think that any analogy between the two is fundamentally flawed because
> of that difference.
Furthermore, the primary cause of memory leaks with manual memory management
is one of omission: one forgets to clean things up, initialize properly, etc.
With manual transmission, one cannot "forget": your car quickly reminds you
with the appropriate grinds, whines, lurches, stalls, etc., forcing you to
correct the situation.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
From: Thomas A. Russ
Subject: Re: standard transmission [was Re: ML predates C++ ...]
Date:
Message-ID: <ymir839l0ns.fsf@sevak.isi.edu>
Ray Blaak <········@STRIPCAPStelus.net> writes:
>
> Matthew Danish <·······@andrew.cmu.edu> writes:
> > Memory management is a much more complicated conceptually than manual
> > transmission; where the primary skill is getting a good feel for the
> > clutch and the sound of the engine. Manual transmission, like other
> > mechanical engineering systems, has a wide margin of error. Memory
> > management, like other computer science issues, has no margin of error.
> > I think that any analogy between the two is fundamentally flawed because
> > of that difference.
>
> Furthermore, the primary cause of memory leaks with manual memory management
> is one of omission: one forgets to clean things up, initialize properly, etc.
>
> With manual transmission, one cannot "forget": your car quickly reminds you
> with the appropriate grinds, whines, lurches, stalls, etc., forcing you to
> correct the situation.
Hopefully BEFORE the whole system crashes.
--
Thomas A. Russ, USC/Information Sciences Institute
From: Nils Goesche
Subject: Re: standard transmission [was Re: ML predates C++ ...]
Date:
Message-ID: <87isolb3fd.fsf@darkstar.cartan>
···@sevak.isi.edu (Thomas A. Russ) writes:
> Ray Blaak <········@STRIPCAPStelus.net> writes:
> > Matthew Danish <·······@andrew.cmu.edu> writes:
> > With manual transmission, one cannot "forget": your car
> > quickly reminds you with the appropriate grinds, whines,
> > lurches, stalls, etc., forcing you to correct the situation.
>
> Hopefully BEFORE the whole system crashes.
Depends on whether it's a rental Porsche or your own.
Regards,
--
Nils G�sche
Mercy to the guilty is cruelty to the innocent.
PGP key ID #xD26EF2A0
From: Christopher C. Stacy
Subject: Re: standard transmission [was Re: ML predates C++ ...]
Date:
Message-ID: <uu185csop.fsf@dtpq.com>
>>>>> On Mon, 25 Aug 2003 16:39:50 GMT, Ray Blaak ("Ray") writes:
Ray> Matthew Danish <·······@andrew.cmu.edu> writes:
>> Memory management is a much more complicated conceptually than manual
>> transmission; where the primary skill is getting a good feel for the
>> clutch and the sound of the engine. Manual transmission, like other
>> mechanical engineering systems, has a wide margin of error. Memory
>> management, like other computer science issues, has no margin of error.
>> I think that any analogy between the two is fundamentally flawed because
>> of that difference.
Ray> Furthermore, the primary cause of memory leaks with manual memory management
Ray> is one of omission: one forgets to clean things up, initialize properly, etc.
Ray> With manual transmission, one cannot "forget": your car quickly reminds you
Ray> with the appropriate grinds, whines, lurches, stalls, etc., forcing you to
Ray> correct the situation.
Transmission fluid leak?
···@jpl.nasa.gov (Erann Gat) writes:
> Hello! The WHOLE POINT of using a high level language is so that you
> don't have to "master these aspects so they disappear"! But C++ isn't a
> high-level language, so naturally a C++ programmer wouldn't understand
> this.
>
> These arguments are no different from the ones made by assembly programer
> in the 1950's arguing against the use of Fortran.
Or even:
"At the time [symbolic assembly programming] first appeared, I would
guess about 1% of the older programmers were interested in it -- using
SAP was sissy stuff, and a real programmer would not stoop to wasting
machine capacity to do the assembly."
-- Richard Hamming, The Art of Doing Science and Engineering,
Gordon and Breach publishers, 1997. (p. 42)
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
···@jpl.nasa.gov (Erann Gat) writes:
> That is non-sensical. It is not the caller that offers a reference,
> it is the calle that demands a reference.
Well, yes. I should have said "provides" rather than "offers."
> In fact, f(x) could be passing x by value today, and by reference
> tomorrow if someone else is maintaining the code for f. The caller
> has no way of knowing.
But there is little danger of being fooled here. If some type
shouldn't be copied for identity or resource-ownership details (say,
each instance holds a socket), I make sure that it can't be
copied. Any attempt to "pass it around" by value won't compile.
Most user-defined types I write -- being "entity" types -- cannot be
copied. Whether arguments should be taken by value or reference is
never in question.
> Hello! The WHOLE POINT of using a high level language is so that
> you don't have to "master these aspects so they disappear"!
I agree, but for me and C++, it's too late. I'm already past worrying
about it.
These days I'd rather work at a higher level in Common Lisp, but I
don't get to make the choice whether to use C++ for my work-related
projects. I concede that my focus changes to a different level of
abstraction when working in C++, but I don't agree that one can't use
OOP principles when working at that admittedly lower level.
> But C++ isn't a high-level language, so naturally a C++ programmer
> wouldn't understand this.
Now you're limiting the person to one of his tools. I program in C++
quite comfortably, but that doesn't mean that I can't see beyond
it. And what if we did have to work in assembler for a day to solve a
particular problem? Does that then mean that we can't see beyond
registers and jumps? Consider the newsgroup we're in here. This
argument isn't taking anything away from Lisp by defending C++ against
overly-severe criticism.
> These arguments are no different from the ones made by assembly
> programer in the 1950's arguing against the use of Fortran.
Point taken. But don't accuse those assembly programmers of not being
able to get their work done, and get it done well. They may not yet
have the luxury to use Fortran instead. So it is here with Common Lisp
and C++.
> Personally, I prefer a tiptronic.
I'd like to try one of those.
> It is C++ *programmers* who suffer for the lack of it.
Some apparently more than others. As I said, if it's that important to
the solution, use a different language.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
···@jpl.nasa.gov (Erann Gat) writes:
> That is non-sensical. It is not the caller that offers a reference,
> it is the calle that demands a reference.
Well, yes. I should have said "provides" rather than "offers."
> In fact, f(x) could be passing x by value today, and by reference
> tomorrow if someone else is maintaining the code for f. The caller
> has no way of knowing.
But there is little danger of being fooled here. If some type
shouldn't be copied for identity or resource-ownership details (say,
each instance holds a socket), I make sure that it can't be
copied. Any attempt to "pass it around" by value won't compile.
Most user-defined types I write -- being "entity" types -- cannot be
copied. Whether arguments should be taken by value or reference is
never in question.
> Hello! The WHOLE POINT of using a high level language is so that
> you don't have to "master these aspects so they disappear"!
I agree, but for me and C++, it's too late. I'm already past worrying
about it.
These days I'd rather work at a higher level in Common Lisp, but I
don't get to make the choice whether to use C++ for my work-related
projects. I concede that my focus changes to a different level of
abstraction when working in C++, but I don't agree that one can't use
OOP principles when working at that admittedly lower level.
> But C++ isn't a high-level language, so naturally a C++ programmer
> wouldn't understand this.
Now you're limiting the person to one of his tools. I program in C++
quite comfortably, but that doesn't mean that I can't see beyond
it. And what if we did have to work in assembler for a day to solve a
particular problem? Does that then mean that we can't see beyond
registers and jumps? Consider the newsgroup we're in here. This
argument isn't taking anything away from Lisp by defending C++ against
overly-severe criticism.
> These arguments are no different from the ones made by assembly
> programer in the 1950's arguing against the use of Fortran.
Point taken. But don't accuse those assembly programmers of not being
able to get their work done, and get it done well. They may not yet
have the luxury to use Fortran instead. So it is here with Common Lisp
and C++.
> Personally, I prefer a tiptronic.
I'd like to try one of those.
> It is C++ *programmers* who suffer for the lack of it.
Some apparently more than others. As I said, if it's that important to
the solution, use a different language.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
In article <···············@raytheon.com>, Steven E. Harris
<········@raytheon.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > That is non-sensical. It is not the caller that offers a reference,
> > it is the calle that demands a reference.
>
> Well, yes. I should have said "provides" rather than "offers."
>
> > In fact, f(x) could be passing x by value today, and by reference
> > tomorrow if someone else is maintaining the code for f. The caller
> > has no way of knowing.
>
> But there is little danger of being fooled here. If some type
> shouldn't be copied for identity or resource-ownership details (say,
> each instance holds a socket), I make sure that it can't be
> copied. Any attempt to "pass it around" by value won't compile.
That only works if x is a class, not a primitive type, and if you control
the code for x's type.
That's the fundamental problem with C++. Yes, most (not all) of the
myriad problems with C++ can be worked around with proper discipline, but
most C++ programmers don't have the proper discipline (because it takes
years and years to develop) and so most C++ code is crappy. For nearly
every problem X with C++ there is a response of the form "Yes, but to
avoid X all you have to do is Y." The problem is that the list of X's is
so long that the probability of assembling a team of programmers who know
all the Y's is extremely small.
> > Hello! The WHOLE POINT of using a high level language is so that
> > you don't have to "master these aspects so they disappear"!
>
> I agree, but for me and C++, it's too late.
No. The reason that you are beyond redemption is not that it's too late,
it's that you have decided that you are beyond redemption. All it takes
to redeem yourself is to change your mind.
> > But C++ isn't a high-level language, so naturally a C++ programmer
> > wouldn't understand this.
>
> Now you're limiting the person to one of his tools. I program in C++
> quite comfortably, but that doesn't mean that I can't see beyond
> it.
I never said that you can't see beyond it, but it does appear to me that
you choose not to. I can understand that. For someone who makes their
living programming, facing the truth about how awful C++ is can be very
traumatic (not to mention career-limiting). You may well be happier in
the long run keeping your blinders on. But then you'd better not hang
around here.
> This
> argument isn't taking anything away from Lisp by defending C++ against
> overly-severe criticism.
"Overly severe criticism of C++" is an oxymoron (at least in c.l.l.) :-)
> > These arguments are no different from the ones made by assembly
> > programer in the 1950's arguing against the use of Fortran.
>
> Point taken. But don't accuse those assembly programmers of not being
> able to get their work done, and get it done well.
I certanly will accuse them of not getting the job done. The software
industry is a mess. It's so bad that most of the world thinks that
viruses and system crashes are just part of the Way the World Is instead
of being the result of bad engineering. Bah!
> They may not yet
> have the luxury to use Fortran instead. So it is here with Common Lisp
> and C++.
What on earth are you talking about? Common Lisp has been available far
longer than C++.
> > Personally, I prefer a tiptronic.
>
> I'd like to try one of those.
Why don't you? There are lots of free Lisps available.
> > It is C++ *programmers* who suffer for the lack of it.
>
> Some apparently more than others. As I said, if it's that important to
> the solution, use a different language.
Actually, it's not just the programmers who suffer. Their customers suffer too.
E.
···@jpl.nasa.gov (Erann Gat) writes:
> Yes, most (not all) of the myriad problems with C++ can be worked
> around with proper discipline, but most C++ programmers don't have
> the proper discipline (because it takes years and years to develop)
> and so most C++ code is crappy.
I definitely agree. Perhaps this will help you see that I am on your
side: I have that discipline you describe, but I wish I never needed
to develop it. That's why I'm here now.
> The problem is that the list of X's is so long that the probability
> of assembling a team of programmers who know all the Y's is
> extremely small.
Usually there's only one or two of those people, drowning trying to
keep the others afloat.
> No. The reason that you are beyond redemption is not that it's too
> late, it's that you have decided that you are beyond redemption.
I can't undo the expended effort. But for the lost time, I consider
the knowledge an asset, not something in need of redemption.
> All it takes to redeem yourself is to change your mind.
Well, I'm here, and have been for over a year, with no intention of
leaving, so my mind has already changed to focus on learning about
Lisp. See my "Road to Lisp Survey" response.�
> I never said that you can't see beyond it, but it does appear to me
> that you choose not to.
Not when I'm programming in C++. I'm not going to bolt on a garbage
collector; I'll work within a mode more appropriate to the language at
hand. ("Doctor, it hurts when...") But if I could choose any language
for a given problem, then of course I'll consider the best tool for
the job, which might be Common Lisp.
> You may well be happier in the long run keeping your blinders on.
> But then you'd better not hang around here.
No blinders here. Not being able to use Lisp more often is indeed
painful, but then so is unemployment.
> What on earth are you talking about? Common Lisp has been available
> far longer than C++.
But just as I can't switch my current C++ project over to CL, perhaps
the Fortran programmers I alluded to couldn't either. We -- meaning me
or someone else in a comparable position -- don't always get to make
or influence the decision.
> Why don't you? There are lots of free Lisps available.
I use CLISP almost every day. I meant the "triptronic-style"
semi-manual car transmission system.
> Actually, it's not just the programmers who suffer. Their customers
> suffer too.
And in my case, when the customer is the U.S. Marine Corps, that
suffering has some profound consequences.
Footnotes:
� http://www.cliki.net/Steven%20Harris
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
In article <···············@raytheon.com>, Steven E. Harris
<········@raytheon.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > Yes, most (not all) of the myriad problems with C++ can be worked
> > around with proper discipline, but most C++ programmers don't have
> > the proper discipline (because it takes years and years to develop)
> > and so most C++ code is crappy.
>
> I definitely agree. Perhaps this will help you see that I am on your
> side:
I didn't realize there were "sides" here. You made the following claim:
> I freely admit that most programs are harder to write in C++ than
> Common Lisp, but that's not because of memory management or object
> identity problems.
And I dispute your claim. I believe that programs are harder to write in
C++ in large measure (though certainly not exclusively) because of memory
management and object identity problems.
> I can't undo the expended effort. But for the lost time, I consider
> the knowledge an asset, not something in need of redemption.
Knowledge of C++ is certainly an asset in some contexts (particularly if
you want to make money programming), but let's be clear: knowledge of C++
is by and large nothing more than knowledge of a vast collection of arcane
and arbitrary trivia. It's not unlike knowledge of the law, which is also
an asset in some contexts (like if you want to make money as a lawyer).
But knowledge of the law is not necessarily (and in fact is often in
direct conflict with) knowledge of deeper truths like *justice* or
*fairness*. Likewise, knowledge of C++ often inhibits understanding of
deeper truths, like macros and abstraction and the power of automatic
memory management.
> > I never said that you can't see beyond it, but it does appear to me
> > that you choose not to.
>
> Not when I'm programming in C++. I'm not going to bolt on a garbage
> collector; I'll work within a mode more appropriate to the language at
> hand. ("Doctor, it hurts when...") But if I could choose any language
> for a given problem, then of course I'll consider the best tool for
> the job, which might be Common Lisp.
Not "might be". Is.
I think you're just in denial, which is perfectly understandable. In this
world one has only three choices: 1) deny how horrible C++ is, 2)
acknowledge how horrible it is and face up the fact that you're wasting
your life learning about it or 3) find something other than computer
programming to earn your living at. I can certainly understand people
choosing #1.
(BTW, there are perfectly fine garbage collectors that work with C++.)
> > You may well be happier in the long run keeping your blinders on.
> > But then you'd better not hang around here.
>
> No blinders here. Not being able to use Lisp more often is indeed
> painful, but then so is unemployment.
Yes. :-(
> > What on earth are you talking about? Common Lisp has been available
> > far longer than C++.
>
> But just as I can't switch my current C++ project over to CL, perhaps
> the Fortran programmers I alluded to couldn't either. We -- meaning me
> or someone else in a comparable position -- don't always get to make
> or influence the decision.
I think that's a cop-out, and a self-fulfilling prophecy. If you choose
not to speak up because you believe you will have no influence then sure
enough you have no influence.
> > Why don't you? There are lots of free Lisps available.
>
> I use CLISP almost every day. I meant the "triptronic-style"
> semi-manual car transmission system.
Yes, I know that's what you meant. My answer is the same. (Think about it.)
> > Actually, it's not just the programmers who suffer. Their customers
> > suffer too.
>
> And in my case, when the customer is the U.S. Marine Corps, that
> suffering has some profound consequences.
Yes indeed, and all the more reason why you need to step up to the plate.
E.
Erann Gat writes:
> The extra control afforded by a manual transmission provides only a
> marginal benefit at best in 99% of driving situations (even many
> racers prefer automatics noawadys).
>
> Personally, I prefer a tiptronic.
You want one of these?
http://www.sewingstore.com/tiptroni.htm
That's one heluva non-sequitur. :-)
--
Fred Gilham ······@csl.sri.com
Lisp has jokingly been called "the most intelligent way to misuse a
computer". I think that description is a great compliment because it
transmits the full flavor of liberation: it has assisted a number of
our most gifted fellow humans in thinking previously impossible
thoughts. E. Dijkstra
In article <··············@snapdragon.csl.sri.com>, Fred Gilham
<······@snapdragon.csl.sri.com> wrote:
> Erann Gat writes:
> > The extra control afforded by a manual transmission provides only a
> > marginal benefit at best in 99% of driving situations (even many
> > racers prefer automatics noawadys).
> >
> > Personally, I prefer a tiptronic.
>
> You want one of these?
>
> http://www.sewingstore.com/tiptroni.htm
>
> That's one heluva non-sequitur. :-)
No, I want one of these:
http://www.autoweb.com.au/start_/showall_/id_AUD/doc_aud0302131/cms/news/newsarticle.html
Actually, what I really want is one of these:
http://www.autorevista.com/articles/02m3.htm
Or one of these:
http://www.avweb.com/news/newacft/181605-1.html
Or one of these:
http://www.pilatus-aircraft.com/2_ga_commercial/ga_commercial.htm
Or one of these:
http://www.falconjet.com/
C++ is one these:
http://www.photo.net/photo/pcd0305/citroen-60
or one of these:
http://www.bullworks.net/virtual/artgallery/rube.htm
E.
Minor engineering tangent:
Steven E. Harris wrote:
> Criticizing C++ for its manual memory management choices is like
> criticizing a race car for having a manual transmission. Beyond
> steering control, throttle, and brakes, the manual transmission adds
> another form of control, enabling driving that may not be possible
> with an automatic transmission.
Automatic tranmission is ubiquitous in formula one. A servo operated
clutch will outperform a manual clutch because its pressure can be
controlled with more precision than anyones foot can, so the clutch
system can be made smaller and lighter. Having the hands on the wheel at
all times radically improves the driver's steering ability, which is
usually the critical factor in safely driving at speed.
Controls on the steering wheel allow the driver to indicate to the
transmission system that he wishes a non-automatic gear change, which
will be made when the system senses that the clutch and shaft loads
allow it. Interlocks prevent gear changes that would damage gearbox or
engine, and force changes to prevent overrevving.
Granted, these types of transmissions are not the conventional viscous
clutch with limited manual override fitted to conventional automatics
you seem to be thinking about.
The performance loss is not in the automatic nature of the transmission,
but the implementation technology. The implementation technology of
automatic transimssion in race cars outperforms the equivalent manual
transmission without loss of control.
Pete
pete kirkham <············@cafemosaic.co.uk> wrote in message news:<·························@news.dial.pipex.com>...
> The performance loss is not in the automatic nature of the transmission,
> but the implementation technology. The implementation technology of
> automatic transimssion in race cars outperforms the equivalent manual
> transmission without loss of control.
A manual transmission is just a competing automatic transmission
technology which relies on brain and hand. :)
pete kirkham <············@cafemosaic.co.uk> writes:
> Automatic tranmission is ubiquitous in formula one.
Thanks for the this information. I hesitated while writing, thinking
someone would come along and correct me, and decided that I'd go out
on a limb and encourage correction. So I learned something.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
pete kirkham <············@cafemosaic.co.uk> writes:
> The performance loss is not in the automatic nature of the
> transmission, but the implementation technology. The implementation
> technology of automatic transimssion in race cars outperforms the
> equivalent manual transmission without loss of control.
Which is analogous to the memory management in garbage-collectet and
non-garbage-collected language implementations -- writing a good
memory management system is complicated enough that programmers don't
(and usually can't afford to due to project time/budget constraints)
do a good job of it. All they usually come up with is the reference
counting, which can be compared to the conventional automatic
transmission. Outperforming it using some manual memory management
tricks might not pose a great challenge, but writing memory managemnt
system that competes with a good garbage-collector is quite a great
challenge (think of Greenspun's Tenth Rule).
--
Janis Dzerins
Common Lisp -- you get more than what you see.
On 22 Aug 2003, Janis Dzerins wrote:
> pete kirkham <············@cafemosaic.co.uk> writes:
>
> > The performance loss is not in the automatic nature of the
> > transmission, but the implementation technology. The implementation
> > technology of automatic transimssion in race cars outperforms the
> > equivalent manual transmission without loss of control.
>
> Which is analogous to the memory management in garbage-collectet and
> non-garbage-collected language implementations -- writing a good
> memory management system is complicated enough that programmers don't
> (and usually can't afford to due to project time/budget constraints)
> do a good job of it.
[snip]
This analogy gets even better. A *good* GC gives you (lots of) control
when you need it (via a variety of tunable parameters). Most serious
program in a GCed langauge do better, often *much* better, with some
serious thought an attention to memory management. Most serious programs,
period, do so, too.
I had an encounter with two programmers, one pro- ond anti-GC. The anti-GC
guy was saying how GC necessarily brought programs to a halt, because you
couldn't get any free memory until the whole memory (on the machine) had
been filled, whereas in C, you just "free a node" whenever you need more
memory. (Or something along these lines. It was insane. The performance
issues we were dealing with had to due with the fact that we *needed* all
that memory for the working process...there was nothing to free!) I was
laughing about this with the pro-GC guy and I say, by way of mockery,
"Wow, that's as absurd as thinking that having GC means you can't have
memory leaks!" He looked at me at said: "But I thought that's exactly what
GC means! That's what I was taught in school." (He was a recent CS major
grad.)
Cheers,
Bijan Parsia.
Steven E. Harris <········@raytheon.com> writes:
> Taking an argument by reference means that the callee is not
> interested in managing the argument's lifetime.
*I'm* not interested in the argument's lifetime.
> The referenced object must be preexistent; other than that, no
> guarantees can be made about how long the object will live after the
> function call.
That's no good. I want the guarantee that it will live `as long as
necessary' or longer.
> If the callee is to assume responsibility for the object's lifetime,
> then the function should demand its argument as a
> std::auto_ptr<Object> (or perhaps boost::shared_ptr<Object>). That
> communicates and assists proper ownership transfer (or sharing).
>
>> Why do I even need to think about memory management when I want to
>> do OOP?
>
> You don't need to think about it in C++ if you create your objects as
> automatic variables.
Yeah, you don't need to think about it if you simply don't manage
memory.
> I freely admit that most programs are harder to write in C++ than
> Common Lisp, but that's not because of memory management or object
> identity problems.
I disagree. A huge amount of investment is in deciding who is
`responsible' for managing the lifetime of an object. It's been shown
time and time again that this is a significant part of C and C++
programming.
> Criticizing C++ for its manual memory management choices is like
> criticizing a race car for having a manual transmission. Beyond
> steering control, throttle, and brakes, the manual transmission adds
> another form of control, enabling driving that may not be possible
> with an automatic transmission. The driver has a little more to
> contend with, but the good drivers wouldn't trade that manual
> transmission out. They've gotten beyond struggling with it and now
> consider it an asset.
Lisp has computer controlled continuously variable transmission with
optional manual override. It's a whole different beast from `automatic'.
Joe Marshall <···@ccs.neu.edu> writes:
> Lisp has computer controlled continuously variable transmission with
> optional manual override. It's a whole different beast from `automatic'.
I remember seeing a presentation of a car with CVT, about 20 years
ago. Are there any actually being sold, yet ?
Jacek Generowicz <················@cern.ch> wrote in message news:<··················@lxplus077.cern.ch>...
> Joe Marshall <···@ccs.neu.edu> writes:
>
> > Lisp has computer controlled continuously variable transmission with
> > optional manual override. It's a whole different beast from `automatic'.
>
> I remember seeing a presentation of a car with CVT, about 20 years
> ago. Are there any actually being sold, yet ?
Lots, actually. I think the current count is somewhere shy of one
million cars world-wide. Honda and Audi both sell CVT transmissions
with some of their smaller cars (Civics, A4s), and I think GM has one
available either through Saturn or Cadillac.
·······@mindspring.com (Rayiner Hashem) writes:
> I'm not saying that C programming is bad programming. I'm saying that
> C programming in C++ is a bad thing!
And this is one thing others and I are disagreeing with you about.
> Look at it this way:
>
> C is a low-level systems programming language.
Agreed. A very good one.
> Lisp is a high-level application programming language.
I have to disagree with you here. Lisp is high level and
low level. You continue to believe as you do because you are
ignoring those who have corrected you about Lisp being suitable
for operating system design, drivers, and even embedding.
> C++ has both low and high level elements.
Agreed. The low-level element, for the most part, is C.
> Now, if you program low-level C++, don't compare it to high-level Lisp
> and then complain that C++ is complicated/unsafe/whatever.
Who's doing that? I don't program C++, I program in C. And I don't much
compare C against Lisp.
C++ stands on its own demerits.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
> I have to disagree with you here. Lisp is high level and
> low level. You continue to believe as you do because you are
> ignoring those who have corrected you about Lisp being suitable
> for operating system design, drivers, and even embedding.
This is an interesting statement. I'm not saying that its not possible
to do low-level code in Lisp, but why would you want to?. Consider
this: what do you do when a language does not let you do pointer
arithmatic? A lot of the tricks that make the huge datasets maintained
by operating systems possible is being able to do tricks with integers
and pointers. There are lots of cases where one will use the lower few
bits of a pointer for status information, and use the rest as an
actual pointer. What do you do when you want zero overhead for memory
allocations (this is doable with pool allocators) but the GC wants to
maintain per-object headers? What do you do when you need all 32-bits
of an integer (down in kernel space, integers can never have enough
bits :) but part of the integer is taken up by type tags? Even if you
can work around all of this in Common Lisp, is it really worth all the
trouble? I've never written a kernel in Common Lisp, so I'd welcome
any commentary from someone who has. I have written kernels in C++,
and can definately say that its much better than C for doing that sort
of thing. All of its higher-level semantics map directly to
machine-level semantics, so its entirely possible to use stuff like
objects, templates, exceptions, etc, in low-level code.
PS> Low-level C++ is *not* like low-level C. An example: you can write
a data structure that manipulates page tables as an entirely generic
one using templates with integer parameters. Doing the same is
non-trivial in C.
·······@mindspring.com (Rayiner Hashem) writes:
> > I have to disagree with you here. Lisp is high level and
> > low level. You continue to believe as you do because you are
> > ignoring those who have corrected you about Lisp being suitable
> > for operating system design, drivers, and even embedding.
> This is an interesting statement. I'm not saying that its not possible
> to do low-level code in Lisp, but why would you want to?.
Because I can.
Because it's not at all hard.
Why would you want to do low-level in C++, rather than just C?
> Consider
> this: what do you do when a language does not let you do pointer
> arithmatic? A lot of the tricks that make the huge datasets maintained
> by operating systems possible is being able to do tricks with integers
> and pointers. There are lots of cases where one will use the lower few
> bits of a pointer for status information, and use the rest as an
> actual pointer. What do you do when you want zero overhead for memory
> allocations (this is doable with pool allocators) but the GC wants to
> maintain per-object headers? What do you do when you need all 32-bits
> of an integer (down in kernel space, integers can never have enough
> bits :) but part of the integer is taken up by type tags?
All of these are interesting challenges, especially coming from one who
admits to never having tried it in Lisp. Joe Marshal has already given
you some good specific answers, which I agree are possible solutions to
your questions. However, I have the feeling that you are less interested
in learning about how to program low-level in Lisp than you are in
proving your point, so any further answers would not be necessarily
productive in this discussion.
> Even if you
> can work around all of this in Common Lisp, is it really worth all the
> trouble?
Hang on. This entire thread has been about Lisp, and not necessarily
about Common Lisp. Why do you suddenly switch from talking about Lisp
in general to Common Lisp specifically?
> I've never written a kernel in Common Lisp, so I'd welcome
> any commentary from someone who has. I have written kernels in C++,
> and can definately say that its much better than C for doing that sort
> of thing. All of its higher-level semantics map directly to
> machine-level semantics, so its entirely possible to use stuff like
> objects, templates, exceptions, etc, in low-level code.
I don't write OS kernels, myself, but I do write Lisp kernels for my
product. And Lisp is sometimes considered an operating system in and
of itself. There are times when I write in C to interface with the
actual operating system, whose interfaces are after all based on C (with
accompanying .h files which specify the interfacese). This constitutes
probably about 2% of the code for our base product, Allegro CL. All of
the rest of the product is in fact written in Lisp, and at least 90% of
that is written in Common Lisp (because most of CL can be defined in
terms of itself, including the compiler).
The remaining 5% to 8% of code which constitues the source to our system
is written with low-level in mind; it it Lisp, but it is not Common Lisp
(though it is compiled by our normal compiler, with some extensions).
Instead of compiling down to bits in code vectors, it compiles to asm
source, which then gets linked into the shared-library which becomes the
lisp kernel. And it follows the conventions of whatever os/asm/linker
it is targeting, but the Lisp source is the same for all of the
architectures. It is also compatible between 32 and 64-bit Lisps.
> PS> Low-level C++ is *not* like low-level C. An example: you can write
> a data structure that manipulates page tables as an entirely generic
> one using templates with integer parameters. Doing the same is
> non-trivial in C.
I can agree with this. It is easy enough to say that C++ is an extension
of C, but that there are low-level C++ operations that one can do in C++
which are explicitly not C.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
> Why would you want to do low-level in C++, rather than just C?
Because C++ offers higher level features than C without sacrificing
any control. C++ is about as high-level as you can go while still
retaining semantics that map to simple machine code. You can use the
abstractive features of C++ without losing that absolute control.
> Hang on. This entire thread has been about Lisp, and not necessarily
> about Common Lisp. Why do you suddenly switch from talking about Lisp
> in general to Common Lisp specifically?
Actually, this thread has nothing at all to do with Lisp. The original
post was ML vs C, and this whole thread is about C++ vs everything
else (by virtue of the "worst invention in CS" comment.) The reason
I'm talking about Common Lisp is because it would seem to me to be the
best target for this sort of thing. Advanced CL compilers perform
competitively with C code. Most other Lisp implementations are not
nearly as advanced. But if you can find me another Lisp implementation
that performs as well as CL and can support low-level programming I'd
be happy to s
> However, I have the feeling that you are less interested
> in learning about how to program low-level in Lisp than you are in
> proving your point, so any further answers would not be necessarily
> productive in this discussion.
You'd be wrong. I'd be very happy to find a language that supported
low-level code as well as C++. I'm just not convinced that programming
low-level Lisp buys you anything vs low-level C++. It seems to be that
low level programming in Lisp is quite a bit more cumbersome that
low-level programming in a language designed for it. Specifically,
things like kernels are not a little bit of low-level code with a lot
of high-level code. When you're not writing directly to hardware and
io-ports, you're dealing with low-level data structures. Let me give
you some examples:
1) Per-page structures are used in multiple contexts (for example, as
a free-list marker and as a buffer-header) by reinterpret_cast<>'ing
the same block of memory. This is done because many code paths (for
example, interrupt handlers) cannot afford the overhead of *any*
memory allocation.
2) Structures are often grossly compressed, with the same block of
memory serving many, context-dependent purposes. The problem here is
that a kernel has to keep a huge amount of low-level structure. For
example, most VM's allocate a per-page data structure. This single
data structure can eat tens of megs of memory! A more sane structure
that didn't rely on weird pointer manipulation tricks could easily be
two or three times larger.
3) Code has to be extremely careful to not dirty the caches of
application programs. A single garbage collection can easily replace
large parts of the cache with useless data, and greatly slow down
application programs.
So its not like only small parts of the program are composed of
low-level code. Its *all* low-level code. C++ maps very simply to the
machine model, so its very simple to manipulate these sorts of data
structures throughout the code.
> I can agree with this. It is easy enough to say that C++ is an extension
> of C, but that there are low-level C++ operations that one can do in C++
> which are explicitly not C.
·······@mindspring.com (Rayiner Hashem) writes:
> > Why would you want to do low-level in C++, rather than just C?
> Because C++ offers higher level features than C without sacrificing
> any control. C++ is about as high-level as you can go while still
> retaining semantics that map to simple machine code. You can use the
> abstractive features of C++ without losing that absolute control.
OK. Right. You just go on believing that. I think I can predict how
your involvement with Lisp will go...
> > Hang on. This entire thread has been about Lisp, and not necessarily
> > about Common Lisp. Why do you suddenly switch from talking about Lisp
> > in general to Common Lisp specifically?
> Actually, this thread has nothing at all to do with Lisp.
Well, I truly didn't know that. I guess I'll have to stop contributing
to this thread, then, since it has nothing to do with Lisp.
> The original
> post was ML vs C, and this whole thread is about C++ vs everything
> else (by virtue of the "worst invention in CS" comment.) The reason
> I'm talking about Common Lisp is because it would seem to me to be the
> best target for this sort of thing. Advanced CL compilers perform
> competitively with C code. Most other Lisp implementations are not
> nearly as advanced. But if you can find me another Lisp implementation
> that performs as well as CL and can support low-level programming I'd
> be happy to s
===============^
Um, I think you had some low-level buffer that didn't get flushed, here.
:-)
> > However, I have the feeling that you are less interested
> > in learning about how to program low-level in Lisp than you are in
> > proving your point, so any further answers would not be necessarily
> > productive in this discussion.
> You'd be wrong.
But in fact, I'm exactly correct. The whole rest of your post has no
questions for me. It is full only of your own experiences, and how
well you believe you understand the problems of the operating systems
you work on. Sorry, I've lost interest in this one-sided conversation.
> I'd be very happy to find a language that supported
> low-level code as well as C++. I'm just not convinced that programming
> low-level Lisp buys you anything vs low-level C++. It seems to be that
> low level programming in Lisp is quite a bit more cumbersome that
> low-level programming in a language designed for it. Specifically,
> things like kernels are not a little bit of low-level code with a lot
> of high-level code. When you're not writing directly to hardware and
> io-ports, you're dealing with low-level data structures. Let me give
> you some examples:
>
> 1) Per-page structures are used in multiple contexts (for example, as
> a free-list marker and as a buffer-header) by reinterpret_cast<>'ing
> the same block of memory. This is done because many code paths (for
> example, interrupt handlers) cannot afford the overhead of *any*
> memory allocation.
> 2) Structures are often grossly compressed, with the same block of
> memory serving many, context-dependent purposes. The problem here is
> that a kernel has to keep a huge amount of low-level structure. For
> example, most VM's allocate a per-page data structure. This single
> data structure can eat tens of megs of memory! A more sane structure
> that didn't rely on weird pointer manipulation tricks could easily be
> two or three times larger.
> 3) Code has to be extremely careful to not dirty the caches of
> application programs. A single garbage collection can easily replace
> large parts of the cache with useless data, and greatly slow down
> application programs.
>
> So its not like only small parts of the program are composed of
> low-level code. Its *all* low-level code. C++ maps very simply to the
> machine model, so its very simple to manipulate these sorts of data
> structures throughout the code.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
> OK. Right. You just go on believing that. I think I can predict how
> your involvement with Lisp will go...
Wha? I'm not saying that you *can't* get the same level of control
with Lisp, I'm saying that you can with C++. You asked me why I would
want to do low-level programming in C++ rather than in C. I answered.
Lisp had nothing to do with either the question or the answer.
> Well, I truly didn't know that. I guess I'll have to stop contributing
> to this thread, then, since it has nothing to do with Lisp.
Look. I'm not against Lisp here. If you look at my original posts, I
never said anything about "Lisp vs C++." I was just saying that C++ is
not the worst invention in computer science.
> But in fact, I'm exactly correct. The whole rest of your post has no
> questions for me.
The rest of my post is a response to the percentages you presented. My
point was that, in a kernel, the percentage of low-level style code is
much higher.
It is full only of your own experiences, and how
> well you believe you understand the problems of the operating systems
> you work on. Sorry, I've lost interest in this one-sided conversation.
>
Actually, it has nothing to do with my own experiences. Those examples
are just descriptions of what kernel-level programming is like. I
offered them because I was expecting you to reply with examples of how
low-levle Lisp code could easily solve those problems.
Look, I'm not some zealot out to preach the gospel of C++ to
comp.lang.lisp. The subject is so fraught with tension that no
productive discussion can come of it. Further, I don't even believe
that C++ is all that great of a language outside a certain domain of
tasks. I do think, however, that it is a very good language for a
particular domain of problems, and has its place. Furthermore, I think
that some very wild claims are being made in this thread (among them,
Gat's assertion that Lisp is the soluation to your problem, no matter
what that problem may be) that need to be addressed.
In article <····························@posting.google.com>,
·······@mindspring.com (Rayiner Hashem) wrote:
> Furthermore, I think
> that some very wild claims are being made in this thread (among them,
> Gat's assertion that Lisp is the soluation to your problem, no matter
> what that problem may be) that need to be addressed.
The only article in this thread written by me that contains the words
"lisp", "solution" and "problem" is this one:
····················@k-137-79-50-101.jpl.nasa.gov
In that article, the only sentence that contains the word "Lisp" that I
wrote is this one:
"Common Lisp has been available far longer than C++ ."
(Which is in fact true.)
So I cannot imagine what you could possibly be referring to, particularly
since I believe that any assertion of the form "X is the solution to your
problem, no matter what that problem may be" is absurd.
You ought to take a good look in the mirror before you start accusing
other people of making wild claims.
E.
Text searches are fine and dandy, but they don't give the full story.
In your response to Steven Harris:
>> But if I could choose any language
>> for a given problem, then of course I'll consider the best tool for
>> the job, which might be Common Lisp.
> Not "might be". Is.
No inference is necessary here. Your statement very clearly says that
Common Lisp is the best tool for any given problem.
In article <····························@posting.google.com>,
·······@mindspring.com (Rayiner Hashem) wrote:
> Text searches are fine and dandy, but they don't give the full story.
> In your response to Steven Harris:
>
> >> But if I could choose any language
> >> for a given problem, then of course I'll consider the best tool for
> >> the job, which might be Common Lisp.
>
> > Not "might be". Is.
>
> No inference is necessary here.
Yes it is. You have to infer my meaning from the context.
> Your statement very clearly says that
> Common Lisp is the best tool for any given problem.
No. It says that Common Lisp is the best tool for Steve Harris's problem.
Now, I'm going to try to short-circuit some of this exchange by guessing
that your response to this will be, "But Steve Harris said 'a given
problem', which clearly indicates that the context referred not to any
particular problem Steve Harris was having, but to *any* given problem.
But this is not correct for two reasons. First, you excised an important
sentence that preceded the one you quoted:
> >
> > Not when I'm programming in C++. I'm not going to bolt on a garbage
> > collector; I'll work within a mode more appropriate to the language at
> > hand. ("Doctor, it hurts when...") But if I could choose any language
> > for a given problem, then of course I'll consider the best tool for
> > the job, which might be Common Lisp.
>
> Not "might be". Is.
So in this context what is being said is that Common Lisp is the best tool
for the job IF THE ONLY ALTERNATIVE UNDER CONSIDERATION IS C++. (For the
record, this is also not universally true, but it's pretty damn close.)
Second, and this is really the main point, what was going on in the
broader context of that exchange with Steve Harris was that he said he
wanted to use Lisp but was hesitating because he was reluctant to give up
the significant investment he had made in using C++.
In that context, Common Lisp is clearly the best tool for his job. How do
I know that? Because Steve believes it. If he didn't, if he was secure
in his decision that C++ was the best tool for the job we would not have
been having that conversation in the first place! He was standing at the
edge of the Lisp pool dipping a toe in, and "Not 'might be'. Is." was a
comment directed specifically towards Steve (and others with a similar
mindset) and intended to give him (them) a little shove.
So you infer that "Not 'might be'. Is." means that Common Lisp is the
best tool for any problem. But what it really meant is, "Come on in, the
water's fine."
I could have written instead, "If you are considering Common Lisp and C++,
and the only reason you have to doubt that Common Lisp is the best tool
for your job is that you don't want to lose the investment you've made in
C++, then Common Lisp is (almost certainly) the best tool for your job."
But that seemed a little too long-winded at the time.
E.
<reordered>> In that context, Common Lisp is clearly the best tool for
his job.
But we're not talking about his job. If he meant his current job, he
would have said so. Instead, he referred to "a given job", which
indicates future problems he may encounter.
> No. It says that Common Lisp is the best tool for Steve Harris's problem.
Steve Harris's "problem" is deliberately left-open-ended. The
reference to "a given problem" indicates that he is referring not to
current problems in which he is using C++, but future problems he may
encounter. Your assertion that the mention of C++ early in the
statement indicates that he is talking about problems that he would
use C++ is incorrect. Without putting words in Steve's mouth, I would
say that the second part of the quoted statement is clearly seperate
from the first. This conclusion is supported by the fact that,
usually, when someone makes the "I'll choose the best langauge for the
job" he is referring to an open-ended scenario consisting of any
future problems he encounters.
> So in this context what is being said is that Common Lisp is the best tool
> for the job IF THE ONLY ALTERNATIVE UNDER CONSIDERATION IS C++. (For the
> record, this is also not universally true, but it's pretty damn close.)
If this is what you meant, then great. That statement is perfectly
supportable. We may disagree about precisely where that line lies
(because your view of the problem space is probably very different
from mine), I will agree with you that a higher-level language is more
appropriate for many problems that C++ is applied to. However, I
assert that this is not what you *said*.
·······@mindspring.com (Rayiner Hashem) writes:
> I'd be very happy to find a language that supported
> low-level code as well as C++. I'm just not convinced that
> programming low-level Lisp buys you anything vs low-level C++. It
> seems to be that low level programming in Lisp is quite a bit more
> cumbersome that low-level programming in a language designed for it.
You should try it.
> Specifically, things like kernels are not a little bit of low-level
> code with a lot of high-level code. When you're not writing
> directly to hardware and io-ports, you're dealing with low-level
> data structures.
I have found that kernels *are* mostly fairly high level with a
sprinkling of low level code. The key is to isolate and abstract the
really low level stuff with transitioning wrappers. Usually, the
transitioning wrappers are macros and therefore incur no runtime
overhead.
> Let me give you some examples:
>
> 1) Per-page structures are used in multiple contexts (for example, as
> a free-list marker and as a buffer-header) by reinterpret_cast<>'ing
> the same block of memory. This is done because many code paths (for
> example, interrupt handlers) cannot afford the overhead of *any*
> memory allocation.
What overhead? Allocating memory is as simple as bumping a pointer.
The key here is to decouple the object-level allocation from the
region-level allocation. Then you simply need to ensure that the
kernel allocation region won't run out of room. This can be done
by periodically checking how close the kernel is to the end of
the region and freeing up more storage for it. But this part
can be far less time critical if you have sufficient `slop space'.
There is a small part of the kernel that you generally don't want
allocating from the main heap. It would be bad to have to stall
the page fault handler while it fetched a page just to scribble
some temporary information. But interrupt handlers can often be
written so that they don't need to keep data dynamically beyond
the lifetime of the interrupt. In that case, you allocate from
a fixed region and simply reset the pointer on exit.
You can even allocate memory as part of the garbage collection cycle!
So long as you scavenge more than you cons, you'll eventually finish.
> 2) Structures are often grossly compressed, with the same block of
> memory serving many, context-dependent purposes. The problem here is
> that a kernel has to keep a huge amount of low-level structure. For
> example, most VM's allocate a per-page data structure. This single
> data structure can eat tens of megs of memory! A more sane structure
> that didn't rely on weird pointer manipulation tricks could easily be
> two or three times larger.
That's what LDB and DPB are for. You can manipulate arbitrary bit
fields in lisp.
> 3) Code has to be extremely careful to not dirty the caches of
> application programs. A single garbage collection can easily replace
> large parts of the cache with useless data, and greatly slow down
> application programs.
I don't understand this objection. First of all, taking an interrupt
on a modern processor will kill the first-level cache. Performing the
context switch to kernel space will kill the second level. In either
case, since you have no control at all over where in your address
space the stack pointer is at interrupt time, it is almost impossible
to predict what cache lines will be dirtied.
Second of all, cache-conscious garbage collection techniques have been
around for years.
> So its not like only small parts of the program are composed of
> low-level code. It's *all* low-level code. C++ maps very simply to the
> machine model, so its very simple to manipulate these sorts of data
> structures throughout the code.
I think your view is being distorted by C++. There is simply no need
to have low-level code *everywhere*. There are layers of abstraction
in the kernel as well as in user space. For instance, most code will
be a client to the virtual memory system. It should not need access
to the page maps or physical memory except as brokered through the
virtual memory API.
·······@mindspring.com (Rayiner Hashem) writes:
>> I have to disagree with you here. Lisp is high level and
>> low level. You continue to believe as you do because you are
>> ignoring those who have corrected you about Lisp being suitable
>> for operating system design, drivers, and even embedding.
> This is an interesting statement. I'm not saying that its not possible
> to do low-level code in Lisp, but why would you want to?.
Having done it, I found that it was an awful lot easier than,
say, doing it a low-level language.
> Consider this: what you do when a language does not let you do pointer
> arithmatic?
Depends on the language. But are you implying that Lisp does not let
you do pointer arithmetic? What is AREF but pointer arithmetic
followed by dereferencing?
> What do you do when you want zero overhead for memory allocations
> (this is doable with pool allocators) but the GC wants to maintain
> per-object headers?
Simple. You maintain a pool allocator. An array of '(unsigned-byte
32) is often the right choice.
> What do you do when you need all 32-bits of an integer (down in
> kernel space, integers can never have enough bits :) but part of the
> integer is taken up by type tags?
Establish a mapping, abstract the mapping into a macro.
> Even if you can work around all of this in Common Lisp, is it really
> worth all the trouble?
Compared to what?
> I've never written a kernel in Common Lisp, so I'd welcome
> any commentary from someone who has.
Try it sometime. It's an eye opener.
In article <····························@posting.google.com>,
·······@mindspring.com (Rayiner Hashem) wrote:
> I'm not saying that C programming is bad programming. I'm saying that
> C programming in C++ is a bad thing! Look at it this way:
>
> C is a low-level systems programming language.
> Lisp is a high-level application programming language.
> C++ has both low and high level elements.
Wrong. Common Lisp also has low-level elements. And the high-level
elements of Common Lisp are much more advanced than the supposedly
"high-level" elements of C++.
I mean, what do you exactly mean by high-level wrt C++? You don't even
have a garbage collector by default! Template metaprogramming is a bad
joke!
Pascal
Pascal Costanza <········@web.de> wrote in message news:<······························@news.netcologne.de>...
> In article <····························@posting.google.com>,
> ·······@mindspring.com (Rayiner Hashem) wrote:
>
> > I'm not saying that C programming is bad programming. I'm saying that
> > C programming in C++ is a bad thing! Look at it this way:
> >
> > C is a low-level systems programming language.
> > Lisp is a high-level application programming language.
> > C++ has both low and high level elements.
>
> Wrong. Common Lisp also has low-level elements. And the high-level
> elements of Common Lisp are much more advanced than the supposedly
> "high-level" elements of C++.
>
> I mean, what do you exactly mean by high-level wrt C++? You don't even
> have a garbage collector by default! Template metaprogramming is a bad
> joke!
>
I have no idea why some people find it so hard to follow the entire
thread before making a post. If you go back up the chain, you'll find
out that I'm not defending C++ against Lisp (I freely admit Lisp is a
much better high-level language than C++, and yes, template
metaprogramming is a desperate call for real macros) but I'm defending
C++ against the criticism that its the worst invention in modern
computer science. If you actually rad the beginnings of the thread,
you'll see that I compare C++ to languages like Java and .NET, not
Lisp. The only reason this thread is on c.l.l is because somebody on
this board decided to make a totally exaggerated and baseless claim
about C++.
In article <····························@posting.google.com>,
·······@mindspring.com (Rayiner Hashem) wrote:
> I'm defending
> C++ against the criticism that its the worst invention in modern
> computer science.
What would you consider to be worse?
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <····························@posting.google.com>,
> ·······@mindspring.com (Rayiner Hashem) wrote:
>
> > I'm defending
> > C++ against the criticism that its the worst invention in modern
> > computer science.
>
> What would you consider to be worse?
BrainF***, unlambda, Intercal.
In article <···············@lxplus077.cern.ch>, Jacek Generowicz
<················@cern.ch> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <····························@posting.google.com>,
> > ·······@mindspring.com (Rayiner Hashem) wrote:
> >
> > > I'm defending
> > > C++ against the criticism that its the worst invention in modern
> > > computer science.
> >
> > What would you consider to be worse?
>
> BrainF***, unlambda, Intercal.
Er, I think unlambda was not meant to be taken seriously. Not sure about
Intercal ;-)
E.
Jacek Generowicz wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>> What would you consider to be worse?
>
> BrainF***, unlambda, Intercal.
OK, what "non-joke designed language" would you consider to be worse (since
the examples you mention were explicitly designed for humor, not for real
use, so I don't consider them to be part of computer science. And anyway,
you forgot Befunge, as well.)? Or is the best you can say about C++ is
that it's the worst language not explicitly designed as a joke in the
history of computer science?
faa
"Frank A. Adrian" <·······@ancar.org> writes:
> Jacek Generowicz wrote:
> > BrainF***, unlambda, Intercal.
>
> you forgot Befunge, as well.)?
I _knew_ there was one I was missing.
> Or is the best you can say about C++ is that it's the worst language
> not explicitly designed as a joke in the history of computer
> science?
That's exactly what I'm saying ... with two caveats:
a) C++ is outrageously popular, and therefore widely known. There may
well be an even worse language, not explicitly designed as a joke,
of which I am ignorant.
b) I'm not entirely convinced that C++ was not designed as a joke.
Jacek Generowicz <················@cern.ch> wrote:
+---------------
| b) I'm not entirely convinced that C++ was not designed as a joke.
+---------------
See <URL:http://cypherpunks.venona.com/date/1998/03/msg00423.html>
and similar archives... ;-} ;-}
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rayiner Hashem wrote:
> Pascal Costanza <········@web.de> wrote in message news:<······························@news.netcologne.de>...
>
>>In article <····························@posting.google.com>,
>> ·······@mindspring.com (Rayiner Hashem) wrote:
>>
>>
>>>I'm not saying that C programming is bad programming. I'm saying that
>>>C programming in C++ is a bad thing! Look at it this way:
>>>
>>>C is a low-level systems programming language.
>>>Lisp is a high-level application programming language.
>>>C++ has both low and high level elements.
>>
>>Wrong. Common Lisp also has low-level elements. And the high-level
>>elements of Common Lisp are much more advanced than the supposedly
>>"high-level" elements of C++.
>>
>>I mean, what do you exactly mean by high-level wrt C++? You don't even
>>have a garbage collector by default! Template metaprogramming is a bad
>>joke!
>>
>
> I have no idea why some people find it so hard to follow the entire
> thread before making a post. If you go back up the chain, you'll find
> out that I'm not defending C++ against Lisp (I freely admit Lisp is a
> much better high-level language than C++, and yes, template
> metaprogramming is a desperate call for real macros)
That's not the point I am objecting to. You continue to suggest that C++
is a high-level language. However, a language that doesn't allow me to
disregard low-level considerations is not a high-level language.
A low-level language forces you to think in terms of the computer. A
high-level language supports thinking in terms of the problem domain.
Pascal
Duane Rettig wrote:
> I have many complaints about C++ including the brittle-class problem,
> but my biggest gripe about it is name mangling. Not only is mangling
> opaque, grotesque, and nonportable, making it hard to do any external
> interfacing to C++ operators, but as I understand it, the designers
> of the spec actually recommended to vendors that they explicitly
> use different mangling techniques, so that nobody would be tempted to
> use mangled names externally (I don't remember where I heard this -
> it could be heresay, but it is well-borne out in actual practice; I
> don't know of two C++ mangling techniques which are the same).
>
Ellis and Stroustrup, "The Annotated C++ Reference Manual", section
7.2.1c. The reason given is that two different compilers might have
different calling sequences, or vtbl layouts, or might be otherwise not
link-compatible, so using different mangling schemes insures this
possible error will be caught in the linker.
Granted, it makes every system tool downstream from the compiler need to
know intimate unmangling details for each compiler, but it does allow
you to go on using the standard system linker.
For more C++ fun, borrow a copy of Stroustrup's "Design and Evolution of
C++" (should have been titled "Design Rationalizations and Mutation of
C++") and look up CLOS in the index. Yes, it's really there, more than
once.
- Bob
·······@mindspring.com (Rayiner Hashem) writes:
> > (/ 1 0) isn't a style problem. It isn't anything like a style issue.
> > Please explain why you think that it would be a style issue.
> It's called sarcasm. This sub-thread started when someone said that
> many of the perceived problems with C++ stem from people trying to
> write C-style code in C++. Someone responded that writing C-style code
> in C++ is just a style issue, and that if a language allows it, its
> acceptable code. My point was that if you consider using unsafe casts,
> pointer arithmatic, raw arrays, raw pointers, etc, to be style issues,
> then you should consider something like (/ 1 0) to be a style issue
> too. They are clearly *not* style issues, but just bad programming.
>
> > Whether to use LOOP or not is a Lisp style issue. I choose to use it
> > because I find its usefulness outweighs its ugly looks. This is also
> > why I have no qualms about writing C like code in C++.
> If you want to write C-like code, don't bitch when it blows up on you.
> All the low-level features of C++ are there for a reason, because you
> might *need* to use them.
I think the reason they are there is that C++ would never have been
popular without being a relatively easy step up from C. C++ can't get
rid of them because that would break too many things and C++ (like any
other language) is depending upon a lot of continuity to stay alive.
> If you don't have an absolute need to use
> them, then use safer mechanisms. Now, this isn't really a style thing,
> its a safety thing. You can write procedural code in C++ just fine
> using shared pointers and STL containers.
>
> The main problem that C++ people have with people complaining about
> C++ is that they are not legitimate complaints. There are lots of
> legitimate complaints (verbosity, ugly syntax, lack of orthogonality,
> lack of type inference, etc) but the standard ones (lack of type
> safety, memory leaks, etc) are non-issues.
To be very flip --
Sure it's a standard issue; shared_ptr isn't in the standard yet!
> One doesn't write
> int* foo = new int; instead of shared_ptr<int> foo(new int); by
> accident. You do the former when you really need a direct pointer to a
> machine integer, and are willing to put up with the possibility of a
> memory leak.
Or don't have some add-on library giving you more features than what
are in standard C++ today.
And if i wanted more layers of protection plus better functionality at
the cost of a few machine cycles here and there I am using Lisp.
> You do the latter in all other cases. Writing former vs
> the latter (when you don't absolutely need the former) is not a
> stylistic issue. Its wrong code vs correct code.
shared_ptr doesn't seem to be a part of my C++ setup. I see it in the
perhaps semi-standard or comming standard boost add-on library though.
How common is this boost thing btw?
--
Johan KULLSTAM <··········@comcast.net> sysengr
Johan Kullstam <··········@comcast.net> writes:
> Sure it's a standard issue; shared_ptr isn't in the standard yet!
But without more context to show whether guaranteed cleanup is all
we're after, std::auto_ptr would do the job here. (boost::scoped_ptr�
might also be adequate.)
Footnotes:
� http://www.boost.org/libs/smart_ptr/scoped_ptr.htm
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Steven E. Harris wrote:
> Johan Kullstam <··········@comcast.net> writes:
>
>
>>Sure it's a standard issue; shared_ptr isn't in the standard yet!
>
>
> But without more context to show whether guaranteed cleanup is all
> we're after, std::auto_ptr would do the job here. (boost::scoped_ptr�
> might also be adequate.)
>
>
> Footnotes:
> � http://www.boost.org/libs/smart_ptr/scoped_ptr.htm
>
(with-sarcasm-not-so-much-hidden ()
"What do 'scoped_ptr' and 'smart pointers' buy me over a nice,
invisible, helpful Garbage Collector?")
:)
Cheers
--
marco
>
> (with-sarcasm-not-so-much-hidden ()
> "What do 'scoped_ptr' and 'smart pointers' buy me over a nice,
> invisible, helpful Garbage Collector?")
>
> :)
1) The *_ptr's go very well with C++'s overall memory management
scheme. Modern C++ programmers depend largely on automatic variables
to handle memory allocation/deallocation. This means putting values in
containers vs putting object references in containers, etc. The
*_ptr's exist to allow more traditional OOP style to be used in C++
programs. Writing shared_ptr<foo> becomes as automatic as writing
foo*. Yes, its overly verbose and synactically ugly, but nobody in
their right mind would claim that C++ isn't verbose and synactically
ugly.
2) Reference counted pointers buy you deterministic deallocation. In
languages lesser than Lisp/Scheme/Dylan (where you don't have macros
like with-open-file) having deterministic deallocation and proper
destructors is nicer than having to explicitly put cleanup information
into finalizer clauses. Further, good GCs are hard to come by, and the
GCs that are widely available today (Java versions excepting the
latest, CMUCL's GC, the Bohem GC) are still of the "stop the world"
variety.
Doesn't keeping values in containers mean the objects get copied as the
container handles them? IIRC STL containers require and use copy
operations on object instances. OTOH, there was a c.l.l thread where a
poster said that good C++ style was having almost nothing get copied. I
thought that meant keeping object references in containers. I didn't ask
then but since you bring it up again...
Rayiner Hashem wrote:
...
> Modern C++ programmers depend largely on automatic variables
> to handle memory allocation/deallocation. This means putting values in
> containers vs putting object references in containers, etc.
Jeff Caldwell <·····@yahoo.com> writes:
> Doesn't keeping values in containers mean the objects get copied as
> the container handles them? IIRC STL containers require and use copy
> operations on object instances.
It depends on which type of container, but in general, yes, the
objects stored in containers will be copied around. As you know well
from using Lisp, linked lists like std::list<> can alter the managed
sequence without disturbing the contents of nodes. Alternately with,
say, std::vector, trying to alter the sequence may require "moving"
objects, which will be achieved by copying them.
As the containers are all templates, the value type of the container
need not be "the object itself," but can be a plain pointer to some
type or a smart pointer or handle to some type. With the latter cases,
the objects getting copied are lightweight handles; the referenced
objects themselves -- perhaps too large to be copied, or too
entity-like to be copyable -- do not get copied. The container then
only owns the handles to these objects; it does not own the objects
themselves.
> OTOH, there was a c.l.l thread where a poster said that good C++
> style was having almost nothing get copied.
For some types, this is the case. Usually one avoids copying large
objects, objects involving intensive initialization, or entity-like
objects that either manage difficult-to-copy resources (database
connection) or are meant to be singular in the problem domain (an
"employee").
Anecdotally, most types I create are not well-suited to
copying. The problem domain will likely influence the mix of
value-oriented types and entity types.
> I thought that meant keeping object references in containers.
Not actual C++ references, which are not objects and cannot be copied,
but "references" such as pointers, handles, or any device granting
indirection. The mismatch in intention between these value-oriented
containers and non-copyable entity types creates a thirst slaked
nicely by boost::shared_ptr.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Marco Antoniotti <·······@cs.nyu.edu> writes:
> (with-sarcasm-not-so-much-hidden ()
> "What do 'scoped_ptr' and 'smart pointers' buy me over a nice,
> invisible, helpful Garbage Collector?")
They should work in almost any C++ implementation on any platform.
Advocating their use to the rest of the team isn't met with the same
laughter/derision/incredulity as usually results from saying "hey, why
don't we use a garbage collector!"
Jacek Generowicz wrote:
>
> Advocating their use to the rest of the team isn't met with the same
> laughter/derision/incredulity as usually results from saying "hey, why
> don't we use a garbage collector!"
Then the next question would have to be, "Why do you work with people who
treat a valid engineering suggestion with 'laughter/derision/incredulity'
rather than with analysis or argument deciding whether this idea would be
good or bad?" The "laughter/derision/incredulity" and your understandable
desire to avoid it, is a symptom of a deeper pathology.
faa
In article <··················@news.uswest.net>, ·······@ancar.org wrote:
> Jacek Generowicz wrote:
>
> >
> > Advocating their use to the rest of the team isn't met with the same
> > laughter/derision/incredulity as usually results from saying "hey, why
> > don't we use a garbage collector!"
>
> Then the next question would have to be, "Why do you work with people who
> treat a valid engineering suggestion with 'laughter/derision/incredulity'
> rather than with analysis or argument deciding whether this idea would be
> good or bad?"
Gotta pay the rent somehow. :-(
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <··················@news.uswest.net>, ·······@ancar.org wrote:
>
> > Jacek Generowicz wrote:
> >
> > >
> > > Advocating their use to the rest of the team isn't met with the same
> > > laughter/derision/incredulity as usually results from saying "hey, why
> > > don't we use a garbage collector!"
> >
> > Then the next question would have to be, "Why do you work with people who
> > treat a valid engineering suggestion with 'laughter/derision/incredulity'
> > rather than with analysis or argument deciding whether this idea would be
> > good or bad?"
>
> Gotta pay the rent somehow. :-(
That's certainly one part of the answer.
Another is that working with these people allows me to stay in touch
with a field which is my true love, but from which I would otherwise
have distanced myself (for a plethora of other reasons which are not
interesting here).
They view "computing" as a tool to assist them in the pusuit of their
field, and thus are not drawn by the "truth and beauty" of computer
science itself. Therefore, they tend to accept the "common wisdom"
surrounding information technology ...
Sometimes I wish that the "truth and beauty" of computer science did
not interest me, in itself ... then, I imagine, Greenspunning would be
a lot of fun, rather than the agony it is to me now.
Besides, the derision part is due my dramatizing the situation a
bit. Some think it's a joke; others simply stare blankly. There is
also a minority who sympathize, but realize that in our community such
suggestions are just too far out, and hence best left unsaid.
Jacek Generowicz wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>(with-sarcasm-not-so-much-hidden ()
>> "What do 'scoped_ptr' and 'smart pointers' buy me over a nice,
>> invisible, helpful Garbage Collector?")
>
>
> They should work in almost any C++ implementation on any platform.
>
> Advocating their use to the rest of the team isn't met with the same
> laughter/derision/incredulity as usually results from saying "hey, why
> don't we use a garbage collector!"
You do realize that you are posting on comp.lang.lisp, don't you? :)
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Jacek Generowicz wrote:
>
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> >>(with-sarcasm-not-so-much-hidden ()
> >> "What do 'scoped_ptr' and 'smart pointers' buy me over a nice,
> >> invisible, helpful Garbage Collector?")
> > They should work in almost any C++ implementation on any platform.
>
> > Advocating their use to the rest of the team isn't met with the same
> > laughter/derision/incredulity as usually results from saying "hey, why
> > don't we use a garbage collector!"
>
> You do realize that you are posting on comp.lang.lisp, don't you? :)
Heh ... I have a dream ... I go to our team meeting, someone mentions
some convoluted problem with any of the plethora of Greenspunning
projects we're working on. I say
"Well what do you expect if you decide to implement in a ·@····@%
language like C++!"
to get the reply
"You do realize that we are all programming in Common Lisp, don't you?"
Aaaaaah ... keep dreaming.
> Or don't have some add-on library giving you more features than what
> are in standard C++ today.
That's a really facetious argument. Boost is available for most
platforms, and most setups. Should it be standard? Yes. But in
practical terms, it doesn't make a difference. Besides, shared_ptr is
largely useful for more classical styles of OOP programming in C++.
Modern C++ is very value-oriented --- you rarely use pointers.
Instead, you use the standard containers which automatically manage
their own memory. I have written simulation programs in this style,
and can attest to its effectiveness.
>
> And if i wanted more layers of protection plus better functionality at
> the cost of a few machine cycles here and there I am using Lisp.
We're not talking about Lisp! If you want to use Lisp, then use Lisp.
Right now, I usually use Python when I don't need the speed of C++.
But we're talking about whether C++ (modern, rather than classical)
can be a safe language, and I am asserting that it can.
> shared_ptr doesn't seem to be a part of my C++ setup. I see it in the
> perhaps semi-standard or comming standard boost add-on library though.
> How common is this boost thing btw?
Its part of the upcoming standard. C++ is going through a bit of a
transition at the moment, from a more traditional OOP style to a more
unique "modern C++" style. The '98 standard is a bit behind in
supporting some elements of this style, but libraries like Boost exist
to fill that need. In practice, its not a big deal because you only
have to install Boost once, so there is not a huge advantage to
bundling it into the standard. I can't attest to how common it is,
though, as always, the commercial world is quite a bit behind the
academic elements of the community. I've personally used it in one
commercial project and it worked just great.
Rayiner Hashem wrote:
>>Or don't have some add-on library giving you more features than what
>>are in standard C++ today.
>
> That's a really facetious argument. Boost is available for most
> platforms, and most setups. Should it be standard? Yes. But in
> practical terms, it doesn't make a difference. Besides, shared_ptr is
> largely useful for more classical styles of OOP programming in C++.
> Modern C++ is very value-oriented --- you rarely use pointers.
> Instead, you use the standard containers which automatically manage
> their own memory. I have written simulation programs in this style,
> and can attest to its effectiveness.
"value oriented", "containers which automatically manage their own
memory"..... "Greenspun's Tenth Rule of Programming" :)
Cheers
--
Marco
·······@mindspring.com (Rayiner Hashem) writes:
> > How common is this boost thing btw?
>
> Its part of the upcoming standard. C++ is going through a bit of a
> transition at the moment, from a more traditional OOP style to a more
> unique "modern C++" style. The '98 standard is a bit behind in
> supporting some elements of this style, but libraries like Boost exist
> to fill that need. In practice, its not a big deal because you only
> have to install Boost once, so there is not a huge advantage to
> bundling it into the standard. I can't attest to how common it is,
> though, as always, the commercial world is quite a bit behind the
> academic elements of the community. I've personally used it in one
> commercial project and it worked just great.
Actually, there is point which, I think, is very relevant to Lisp,
here. The upcoming new C++ standard is one whose motto might be:
"We do not innovate. We standardise existing practice."
And Boost is a major effort to provide such existing practice.
Over the last year, we've seen a number of discussions about Lisp
layered standards and the like. Go to www.boost.org and read about
their philosophy. Perhaps Lisp layered standard efforts could learn
valuable lessons from Boost. Perhaps a Boost-like effort in Lisp could
even provide sufficient existing practice to, eventually, kick off a
new CL standard.
> (/ 1 0) isn't a style problem. It isn't anything like a style issue.
> Please explain why you think that it would be a style issue.
It's called sarcasm. This sub-thread started when someone said that
many of the perceived problems with C++ stem from people trying to
write C-style code in C++. Someone responded that writing C-style code
in C++ is just a style issue, and that if a language allows it, its
acceptable code. My point was that if you consider using unsafe casts,
pointer arithmatic, raw arrays, raw pointers, etc, to be style issues,
then you should consider something like (/ 1 0) to be a style issue
too. They are clearly *not* style issues, but just bad programming.
> Whether to use LOOP or not is a Lisp style issue. I choose to use it
> because I find its usefulness outweighs its ugly looks. This is also
> why I have no qualms about writing C like code in C++.
If you want to write C-like code, don't bitch when it blows up on you.
All the low-level features of C++ are there for a reason, because you
might *need* to use them. If you don't have an absolute need to use
them, then use safer mechanisms. Now, this isn't really a style thing,
its a safety thing. You can write procedural code in C++ just fine
using shared pointers and STL containers.
The main problem that C++ people have with people complaining about
C++ is that they are not legitimate complaints. There are lots of
legitimate complaints (verbosity, ugly syntax, lack of orthogonality,
lack of type inference, etc) but the standard ones (lack of type
safety, memory leaks, etc) are non-issues. One doesn't write
int* foo = new int; instead of shared_ptr<int> foo(new int); by
accident. You do the former when you really need a direct pointer to a
machine integer, and are willing to put up with the possibility of a
memory leak. You do the latter in all other cases. Writing former vs
the latter (when you don't absolutely need the former) is not a
stylistic issue. Its wrong code vs correct code.
Johan Kullstam wrote in article <··············@sysengr.res.ray.com> on
Wednesday 20 August 2003 20:19 in comp.lang.lisp:
> Sure it is. For at least a dozen years C++ was explicitly an
> extension to C where you could directly import C code simply by
> avoiding a few keywords.
Not anymore. I'm talking about the present. There are things that are legal in
C++ and are not in C.
Anyway, that is not the point. The point is, C++ is not C in its spirit.
Stroustroup's "The C++ Programming Language" gives lots of information about
what he has in mind when using C++. That's not what Ritchie had in mind when
designing C. Thus C and C++ are different languages. Much of the spirit of a
language is determined by its design.
>> People coding with that definition in mind are likely to be bad C++
>> coders.
>
> Now you're just quibbling about style.
You may call that quibbling about style. To some extent it is. Which does not
mean it's not capital. People avoid gotos because it leads to unreadable and
unmaintable code. You may also call that advice "quiblling with style".
People use local variables and encapsulate their data. That can also be
called "quibbling about style". But I'd never work with someone who always
make all his variables global, and uses gotos and labels instead of functions
and loops
> This should go without saying but since you obviously don't subscribe
> to it, i'll state: If the C++ standard accepts it and it does what you
> expect it is *by definition* C++.
How is that relevant to the conversation? You are failing to see that I am not
talking about legal ISO C++. I am talking about efficient, well written, C++
programs.
Sam
--
"[...] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new
work."
- J.R.R. Tolkien, Ainulindale (Silmarillion)
Sam Zoghaib <·····@zep.homedns.orgSPAM> writes:
> Johan Kullstam wrote in article <··············@sysengr.res.ray.com> on
> Wednesday 20 August 2003 20:19 in comp.lang.lisp:
>
>> Sure it is. For at least a dozen years C++ was explicitly an
>> extension to C where you could directly import C code simply by
>> avoiding a few keywords.
>
> Not anymore. I'm talking about the present. There are things that are legal in
> C++ and are not in C.
> Anyway, that is not the point. The point is, C++ is not C in its spirit.
Ah, so the spirit of `the hell with the semantics, if it's not easy for
the compiler to do, punt, and let the programmer clean up the mess'
is a complete co-incidence?
Sam Zoghaib <·····@zep.homedns.orgSPAM> writes:
> How is that relevant to the conversation? You are failing to see
> that I am not talking about legal ISO C++. I am talking about
> efficient, well written, C++ programs.
What I fail to see is why you are leading this conversation in
comp.lang.lisp. Go stick yourself your idiotic C++ compilers where the
sun won't shine.
Mario S. Mommer <········@yahoo.com> wrote in message news:<··············@cupid.igpm.rwth-aachen.de>...
> Sam Zoghaib <·····@zep.homedns.orgSPAM> writes:
>
> > How is that relevant to the conversation? You are failing to see
> > that I am not talking about legal ISO C++. I am talking about
> > efficient, well written, C++ programs.
>
> What I fail to see is why you are leading this conversation in
> comp.lang.lisp. Go stick yourself your idiotic C++ compilers where the
> sun won't shine.
This stupid thread was started by someone on comp.lang.lisp! If you
don't want to hear about C++, then don't bring it up in c.l.l! If you
bring it up, be prepared to hear the other side of the argument...
Mario S. Mommer wrote in article <··············@cupid.igpm.rwth-aachen.de> on
Wednesday 20 August 2003 22:00 in comp.lang.lisp:
> What I fail to see is why you are leading this conversation in
> comp.lang.lisp. Go stick yourself your idiotic C++ compilers where the
> sun won't shine.
I am not the one "leading" the conversation. There was an assumption made that
C++ replaced C, which I corrected.
Sam
--
"So if you meet me, have some courtesy, have some sympathy, and some taste
Use all your well-learned politesse, or I'll lay your soul to waste"
- The Rolling Stones, "Sympathy for the Devil"
In article <········································@ziplip.com>,
········@ziplip.com" <·······@ziplip.com> wrote:
> ML predates C++, so why didn't it replace C when the limitations
> of C became apparent? There were no good ML compilers?
Apples also predate oranges.
Pascal
P.S.: This is a hint. ;)
········@ziplip.com" <·······@ziplip.com> wrote in message news:<········································@ziplip.com>...
> ML predates C++, so why didn't it replace C when the limitations
> of C became apparent? There were no good ML compilers?
Goddamned idiot, stop trolling already.