ML predates C++ ...
mik...@ziplip.com
of C became apparent? There were no good ML compilers?
Pascal Costanza
"mik...@ziplip.com" <mik...@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. ;)
Doug Tolton
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.~a" "dtolton" "ya" "hoo" "com")
Sam Zoghaib
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)
HPL
> 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.
Michael Parker
> 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...
Rayiner Hashem
> 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.
Tim Lavoie
>> 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.
Ray Blaak
> 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,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
Matthias
> 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.
Jacek Generowicz
> Doug Tolton wrote in article <p2a2kv8n2vnhg06pv...@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.
Joe Marshall
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
>> 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.
Kaz Kylheku
> 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.
Daniel Barlow
> "HPL" <Lovecra...@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
Christopher C. Stacy
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.)
Christopher C. Stacy
>>>>> 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...)
Johan Kullstam
> Doug Tolton wrote in article <p2a2kv8n2vnhg06pv...@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 <kulls...@comcast.net> sysengr
Ray Blaak
> 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
Rayiner Hashem
> 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...)
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++.
Sam Zoghaib
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.
Mario S. Mommer
Sam Zoghaib <NO...@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.
Joe Marshall
> Johan Kullstam wrote in article <87d6f0q...@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?
Daniel Barlow
> 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.
Sam Zoghaib
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"
Erann Gat
rb...@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.
Steven E. Harris
> 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 :: seha...@raytheon.com
Raytheon :: http://www.raytheon.com
Matthew Danish
> 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 <mda...@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."
Erann Gat
<seha...@raytheon.com> wrote:
> g...@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.
Rayiner Hashem
>
> 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...
Rayiner Hashem
> 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...
Rayiner Hashem
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...
Rayiner Hashem
> 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.
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++.
Will Hartung
"Ray Blaak" <rb...@telus.net> wrote in message
news:cb430c44.03082...@posting.google.com...
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
(wi...@msoft.com)
Christopher C. Stacy
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".
Christopher C. Stacy
>> 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.
Lars Brinkhoff
> 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/
Lars Brinkhoff
> 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.
Kent M Pitman
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.
Daniel Barlow
> 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.
lin8080
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
Joe Marshall
> 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)
Johan Kullstam
(/ 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?
Rayiner Hashem
> Please explain why you think that it would be a style issue.
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.
Rayiner Hashem
> Please explain why you think that it would be a style issue.
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++.
Johan Kullstam
> > (/ 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?
Steven E. Harris
> 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
Duane Rettig
> > (/ 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 du...@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
Steven E. Harris
> 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
Rayiner Hashem
> are in standard C++ today.
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
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.
Marco Antoniotti
Steven E. Harris wrote:
> Johan Kullstam <kulls...@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
Marco Antoniotti
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
Duane Rettig
> 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.
Erann Gat
hel...@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.
Pascal Costanza
> 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
Brian Palmer
> 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.
Pascal Costanza
Brian Palmer <bpa...@rescomp.Stanford.EDU> wrote:
> g...@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
Steven E. Harris
> 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.
Erann Gat
> g...@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.
Erann Gat
<seha...@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.
Ray Blaak
> > 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,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
pete kirkham
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
Thomas Lindgren
g...@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
Janis Dzerins
> 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.
Bijan Parsia
> pete kirkham <pete-k...@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.
Jens Kilian
> 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.
--
mailto:j...@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]
Jacek Generowicz
> (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!"
Kaz Kylheku
> 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. :)
Marco Antoniotti
You do realize that you are posting on comp.lang.lisp, don't you? :)
Cheers
--
Marco
Jacek Generowicz
> > 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.
Jacek Generowicz
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.
Frank A. Adrian
>
> 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
Joe Marshall
> 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'.
Steven E. Harris
> 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.
Bob Bane
> 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
Steven E. Harris
> 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.
Erann Gat
> 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.
Rayiner Hashem
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++.
Rayiner Hashem
> (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.
Fred Gilham
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 gil...@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
Rayiner Hashem
> 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.
Joe Marshall
>> 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.
Erann Gat
<seha...@raytheon.com> wrote:
> g...@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.
Erann Gat
> I'm defending
> C++ against the criticism that its the worst invention in modern
> computer science.
What would you consider to be worse?
E.
Erann Gat
<gil...@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:
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.
Steven E. Harris
> 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
Rob Warnock
+---------------
| lin8080 <lin...@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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Will Hartung
"Ray Blaak" <rAYb...@STRIPCAPStelus.net> wrote in message
news:u4r0a2...@STRIPCAPStelus.net...
> g...@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
(wi...@msoft.com)
Pascal Costanza
> Pascal Costanza <cost...@web.de> wrote in message news:<costanza-A95AC3...@news.netcologne.de>...
>
>>In article <a3995c0d.03082...@posting.google.com>,
>> hel...@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
> > 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 du...@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
Jacek Generowicz
> 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
Jacek Generowicz
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.
Erann Gat
<seha...@raytheon.com> wrote:
> g...@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.
Frank A. Adrian
> g...@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
Michael Sullivan
> 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
Jacek Generowicz
> 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.
Erann Gat
<jacek.ge...@cern.ch> wrote:
Er, I think unlambda was not meant to be taken seriously. Not sure about
Intercal ;-)
E.
Jeff Caldwell
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:
...