What is wrong with OO ?
Travis C. Porco
>Try reading one of Steve Heller's books on C++. They are designed so that
>absolutely anyone can understand. I am not saying that C++ is the easiest
>thing on earth to learn. Sometimes, there is difficulty associated with
>learning (even elementary arithmetic has perils for those who have not yet
>grasped all nuances). Learning C++ is not so difficult that a capable high
>school student cannot learn it.
But first, one must ask whether it is desirable to learn it in the first place. C++ is by all accounts exceedingly difficult to master. What is the return
on our time investment? Especially when there are even higher level
languages available than C++, in particular Common Lisp with its object system
CLOS.
The choice of language tools is not, as some would say, a matter of
"programming religion" purely. Some languages really do provide enhanced
productivity by abstraction. Who would deny that it is faster and safer
to write applications in C than in assembler?
--Travis Porco
Dann Corbit
Travis C. Porco <po...@stat.Berkeley.EDU> wrote in article
<5d6ld7$i...@agate.berkeley.edu>...
> >Try reading one of Steve Heller's books on C++. They are designed so
that
> >absolutely anyone can understand. I am not saying that C++ is the
easiest
> >thing on earth to learn. Sometimes, there is difficulty associated with
> >learning (even elementary arithmetic has perils for those who have not
yet
> >grasped all nuances). Learning C++ is not so difficult that a capable
high
> >school student cannot learn it.
>
> But first, one must ask whether it is desirable to learn it in the first
place.
> C++ is by all accounts exceedingly difficult to master.
genius. There are thousands of commercial programmers and analysts who
have made the leap. Many times as many as Lisp and Smalltalk put together.
> What is the return
> on our time investment? Especially when there are even higher level
> languages available than C++, in particular Common Lisp with its object
system
> CLOS.
What a load of crap. If you are talking about 'return on investment' C++
is absurdly higher than Common Lisp. Look at the amount of development
that is going on in C++ and compare it with what is going on in Lisp. Only
a fool will thing they will get a higher ROI from a study of Lisp, which is
at least as difficult to master as C++. Go to a bookstore, and see how
much effort is being put forth to provide C++ instruction, compared to
Lisp. Will you be able to use your Lisp skills on every platform you might
need to work on? Look at the tools that are available for C++ compared to
Lisp. Will you be able to pull a big pile of Lisp code into your design
tool and automatically create object diagrams from it? On dozens of
platforms? Yes, I do realize that Smalltalk and Lisp are viable tools that
do answer real-life business problems. Sometimes they are the best tool
for the job. Just less often than C++. How many trained programming
resources does a typical organization have for C++ verses those
alternatives? Neither Smalltalk nor Lisp will ever have the following nor
the utility that C++ does.
> The choice of language tools is not, as some would say, a matter of
> "programming religion" purely. Some languages really do provide enhanced
> productivity by abstraction. Who would deny that it is faster and safer
> to write applications in C than in assembler?
Please don't let Nudds hear you. And it is not always true. Just most of
the time.
As always, all this stuff is IMO - YMMV.
Please send hate mail to me, rather than pollute the newsgroups with a
language war.
dco...@SolutionsIQ.com
cosc...@bayou.uh.edu
Dann Corbit (dco...@solutionsiq.com) wrote:
: Travis C. Porco <po...@stat.Berkeley.EDU> wrote in article
[Snip]
: > But first, one must ask whether it is desirable to learn it in the first
: place.
: > C++ is by all accounts exceedingly difficult to master.
: By what accounts? I have no problem understanding it, and I'm not a
: genius. There are thousands of commercial programmers and analysts who
: have made the leap. Many times as many as Lisp and Smalltalk put together.
He said "master", not "understand". Understanding C++ is one thing,
but mastering it is another. There are so many nuances and
pathological horrors that await you in the bowels of this, the
most overrated of languages, that you will be befuddled time
and again, and turn your tear stained faced up towards the heavens
and cry "Why me Lord, why hath thou forsaken me?!?!?".
First, you have the miserable failings of C to contend with, and
then you have the extra horrors that C++ decided to throw in for
good measure. Object oriented extensions slapped on top of an
inadequate, archaic, low level language, a programming experience
do not make.
: > What is the return
: > on our time investment? Especially when there are even higher level
: > languages available than C++, in particular Common Lisp with its object
: system
: > CLOS.
: What a load of crap. If you are talking about 'return on investment' C++
: is absurdly higher than Common Lisp. Look at the amount of development
: that is going on in C++ and compare it with what is going on in Lisp.
That depends on what you define as "return on investment". If
by "return on investment" you mean better job opportunities, then
yes C++ sure does have a higher return on investment. But if
you mean the ability to produce reliable, maintainable code, then
C++ is a complete failure in this regard and gives you zero return
on investment.
: Only
: a fool will thing they will get a higher ROI from a study of Lisp, which is
: at least as difficult to master as C++.
Kindly leave some of your belligerence at home. This is a public
forum where many different opinions and facts are discussed, and
your attitude does little to promote intelligent discourse.
: Go to a bookstore, and see how
: much effort is being put forth to provide C++ instruction, compared to
: Lisp.
While you're at it, see how much effort is being put forth to provide
Visual Basic instruction. Popularity and Quality are very often
two mutually exclusive things. Do not confuse the two. C++ is
a miserable language, but one that is tremendously popular.
If you want to ride the wave of popularity, then be my guest.
However, some of us are leaving our surfboards at home and
prefer to swim upstream, to where the real gains are.
Lisp, while not my favorite language, is a language that is
leaps and bounds ahead of C and it's inbred cousin, C++.
The fact that in Lisp you can worry about coding the problem
at hand, rather than playing with copy constructors, assignment
overloading, pointers, and destructors speaks for itself.
: Will you be able to use your Lisp skills on every platform you might
: need to work on?
Yes. You see, Lisp is not only available as is, but is also the
extension language for Emacs, The World's Finest Editor (tm). With
Lisp under my belt I can customize Emacs to jump through hoops and
boost my productivity by leaps and bounds, even if my job entails
programming in another language (I've already used it to save some
*SERIOUS* time at work).
Furthermore, there's the Scheme Shell, which you can use for
UNIX shell programming, and who knows what else -- in addition
to your standard Lisp code.
Furthermore, others do code in Lisp. I've seen various extension
packages written in Lisp, even the videogame Abuse, had some
Lisp code in there.
: Look at the tools that are available for C++ compared to
: Lisp.
Given C++'s uselessness, you'll need them.
: Will you be able to pull a big pile of Lisp code into your design
: tool and automatically create object diagrams from it?
It depends on the tools and vendor now doesn't it?
: On dozens of
: platforms?
Ditto, but more likely for C++ due exclusively to it's popularity.
: Yes, I do realize that Smalltalk and Lisp are viable tools that
: do answer real-life business problems. Sometimes they are the best tool
: for the job. Just less often than C++.
Actually, it's the other way around. It's rare when C++ is needed
to do something that a superior language cannot do better. C++
is used for one reason and one reason only -- popularity. It is
the fad, and hence it is used. It is a woefully inadequate
programming language for even the most trivial of tasks.
: How many trained programming
: resources does a typical organization have for C++ verses those
: alternatives?
And how many roaches can one find in a house versus humans?
: Neither Smalltalk nor Lisp will ever have the following nor
: the utility that C++ does.
Nor will they have the bugs, crappy reputation, or laughable
"features".
:
: > The choice of language tools is not, as some would say, a matter of
: > "programming religion" purely. Some languages really do provide enhanced
: > productivity by abstraction. Who would deny that it is faster and safer
: > to write applications in C than in assembler?
: Please don't let Nudds hear you. And it is not always true. Just most of
: the time.
Nudds, dear lord people really have it in for that guy.
: As always, all this stuff is IMO - YMMV.
Ditto here.
: Please send hate mail to me, rather than pollute the newsgroups with a
: language war.
: dco...@SolutionsIQ.com
--
Cya,
Ahmed
You call it romance,
You're full of shit!
"Filler" by Minor Threat
William Paul Vrotney
In article <01bc12c6$a036c5e0$ca61...@DCorbit.solutionsiq.com> "Dann
Corbit" <dco...@solutionsiq.com> writes:
>
> Travis C. Porco <po...@stat.Berkeley.EDU> wrote in article
>> > >Try reading one of Steve Heller's books on C++. They are designed so
>> that > >absolutely anyone can understand. I am not saying that C++ is the
>> easiest > >thing on earth to learn. Sometimes, there is difficulty
>> associated with > >learning (even elementary arithmetic has perils for
>> those who have not yet > >grasped all nuances). Learning C++ is not so
>> difficult that a capable high > >school student cannot learn it. > > But
>> first, one must ask whether it is desirable to learn it in the first
>> place. > C++ is by all accounts exceedingly difficult to master.
> By what accounts? I have no problem understanding it, and I'm not a
> genius. There are thousands of commercial programmers and analysts who
> have made the leap. Many times as many as Lisp and Smalltalk put together.
>
>> > What is the return > on our time investment? Especially when there are
>> even higher level > languages available than C++, in particular Common
>> Lisp with its object system > CLOS.
> What a load of crap. If you are talking about 'return on investment' C++
> is absurdly higher than Common Lisp. Look at the amount of development
> ... [+ more of the usual non-Lisper prejudice]
> Please send hate mail to me, rather than pollute the newsgroups with a
> language war.
> dco...@SolutionsIQ.com
>
There should be a word to describe this. The poster starts a war and then
proclaims that nobody else is allowed a post to defend.
In the great C++/Lisp wars of the past there was usually mostly postings
from either skilled side. I wonder what postings from those that have
mastered both Lisp and C++ would be like. I think that most of us would
value their opinions more than the single skilled.
--
William P. Vrotney - vro...@netcom.com
Thomas Fischbacher
"Dann Corbit" <dco...@solutionsiq.com> writes:
> > C++ is by all accounts exceedingly difficult to master.
> By what accounts? I have no problem understanding it, and I'm not a
> genius. There are thousands of commercial programmers and analysts who
> have made the leap. Many times as many as Lisp and Smalltalk put together.
"Just because there are more cockroaches than human beings does not
neccessarily mean that cockroackes are on a higher level of evolution."
> What a load of crap. If you are talking about 'return on investment' C++
> is absurdly higher than Common Lisp. Look at the amount of development
> that is going on in C++ and compare it with what is going on in Lisp.
That's right. But the difference is: you can solve problems in LISP. :-)
> a fool will thing they will get a higher ROI from a study of Lisp, which is
> at least as difficult to master as C++. Go to a bookstore, and see
The problem with LISP is: you need quite some mathematical background
and knowledge of other functional languages to fully appreciate
it. When I first "collided" with LISP, I found it a horrible thing,
wondering how anyone with a bit of common sense could be so masochistic
to use such weird stuff. That time, I did everything in C. (C++ wasn't
available. Later on I learned C++ and first, I really found it great,
but only until I got into contact with Lambda Calculus, Combinatory
Logic and another functional language looking not that horrible. Then
I discovered that problems can be solved in functional languages! Wow!
Languages like C++, Java, etc. somehow seem to exist only to create
yet more problems you have to solve which don't have to do anything
with what you intitially wanted from the machine.
500 lines C++ => 50 lines ML - that's been an experience.
Meanwhile, I do almost anything in functional languages, modtly in
LISP. Sigh.
--
regards,
Thomas Fischbacher - t...@another.gun.de
fisc...@informatik.tu-muenchen.de
Anonymous
For the most part nothing...
OO is ok with me. I naturally construct my object oriented
taxonomies with nouns & verbs and with some re-work every
thing fit's and works ok.
I give it a thumbs up.
cosc...@bayou.uh.edu <cosc...@Bayou.UH.EDU> wrote in article
<5d8o3v$f...@Masala.CC.UH.EDU>...
Travis C. Porco
In article <oa1d8uf...@hphalle0i.informatik.tu-muenchen.de>,
Thomas Fischbacher <fisc...@hphalle0i.informatik.tu-muenchen.de> wrote:
>"Dann Corbit" <dco...@solutionsiq.com> writes:
>> > C++ is by all accounts exceedingly difficult to master.
>> By what accounts? I have no problem understanding it, and I'm not a
>> genius. There are thousands of commercial programmers and analysts who
>> have made the leap. Many times as many as Lisp and Smalltalk put together.
>"Just because there are more cockroaches than human beings does not
>neccessarily mean that cockroackes are on a higher level of evolution."
:)
"Thou shalt not follow a multitude to do evil."
>The problem with LISP is: you need quite some mathematical background
>and knowledge of other functional languages to fully appreciate
>it. When I first "collided" with LISP, I found it a horrible thing,
>wondering how anyone with a bit of common sense could be so masochistic
>to use such weird stuff. That time, I did everything in C. (C++ wasn't
>available. Later on I learned C++ and first, I really found it great,
>but only until I got into contact with Lambda Calculus, Combinatory
>Logic and another functional language looking not that horrible. Then
>I discovered that problems can be solved in functional languages! Wow!
>Languages like C++, Java, etc. somehow seem to exist only to create
>yet more problems you have to solve which don't have to do anything
>with what you intitially wanted from the machine.
>500 lines C++ => 50 lines ML - that's been an experience.
>Meanwhile, I do almost anything in functional languages, modtly in
>LISP. Sigh.
My experience has been the same.
I started programming in Fortran and PL/I in 1983, then switched to C.
I made an effort to learn C++ when it first came out and was very
enthusiastic at the time. I made another effort several years later
before realizing that it just wasn't helping me get my work done.
Now I use ML for almost everything. Most of my projects are small and
limited by development time; ML has allowed me to finish projects in about
20% of the time it would have taken in C. Without this extra productivity,
I could never have finished some of my projects last year.
--Travis Porco
Travis C. Porco
In article <01bc12c6$a036c5e0$ca61...@DCorbit.solutionsiq.com>,
Dann Corbit <dco...@solutionsiq.com> wrote:
>Travis C. Porco <po...@stat.Berkeley.EDU> wrote in article
>> >Try reading one of Steve Heller's books on C++. They are designed so
>that
>> >absolutely anyone can understand. I am not saying that C++ is the
>easiest
>> >thing on earth to learn. Sometimes, there is difficulty associated with
>> >learning (even elementary arithmetic has perils for those who have not
>yet
>> >grasped all nuances). Learning C++ is not so difficult that a capable
>high
>> >school student cannot learn it.
>> But first, one must ask whether it is desirable to learn it in the first
>place.
>> C++ is by all accounts exceedingly difficult to master.
>By what accounts? I have no problem understanding it, and I'm not a
>genius. There are thousands of commercial programmers and analysts who
>have made the leap. Many times as many as Lisp and Smalltalk put together.
I'm sure lots of people have taken the trouble to learn C++. I'm sure some
people have even mastered it. Now I don't think anyone has ever done a
formal difficulty study of C++ vs LISP or ML or Smalltalk. You'd have to
for example, randomly allocate a bunch of beginners to a C++ group or to
a Lisp group, give each some standard textbook and a programming problem,
have a measure of learning success, etc.
So we really do have to make do with imperfect sources of information.
The choice of language tools is too important to throw information away and
choose at random. At the same time we have to watch out for unreason, fud,
and so on.
Regarding C++, I've never heard anyone say that C++ is "simple", for instance.
The common wisdom does seem to be that C++ is not mastered quickly. I've
seen this opinion expressed in books on C++ and by its advocates as well
as by its critics. The advocates usually are claiming that C++ is hard,
but it is worth the effort.
Now I didn't get up one morning with dislike for C++;
on the contrary--I embraced it enthusiastically at first, and tried on
many occasions to begin object-oriented design in C++ (in other words, I didn't
just use it as "a better C"). I've been programming for many years,
starting with Fortran and PL/I on a UNIVAC 1100 and Pascal on a Vax before
moving to C. And I've just never experienced so much frustration as I
experienced with C++.
And I don't think I'm alone. (A certain 'machismo' keeps some people from
admitting that C++ is hard to learn and hard to use. Some colleagues of
mine find mastery of C++ to be a mark of distinction, as if a person must
be very smart or talented to have mastered this language.
But obviously all such attitudes are illogical, since what is important
is choosing the right tool for the job and GETTING THE JOB DONE.)
I'd rather spend what time and imagination I have on the problem at hand,
freed from trying to understand the arcana of a language as needlessly
complex as C++.
>> What is the return
>> on our time investment? Especially when there are even higher level
>> languages available than C++, in particular Common Lisp with its object
>system
>> CLOS.
>What a load of crap. If you are talking about 'return on investment' C++
>is absurdly higher than Common Lisp. Look at the amount of development
>that is going on in C++ and compare it with what is going on in Lisp. Only
>a fool will thing they will get a higher ROI from a study of Lisp, which is
>at least as difficult to master as C++. Go to a bookstore, and see how
>much effort is being put forth to provide C++ instruction, compared to
>Lisp. Will you be able to use your Lisp skills on every platform you might
>need to work on? Look at the tools that are available for C++ compared to
>Lisp. Will you be able to pull a big pile of Lisp code into your design
>tool and automatically create object diagrams from it? On dozens of
>platforms? Yes, I do realize that Smalltalk and Lisp are viable tools that
>do answer real-life business problems. Sometimes they are the best tool
>for the job. Just less often than C++. How many trained programming
>resources does a typical organization have for C++ verses those
>alternatives? Neither Smalltalk nor Lisp will ever have the following nor
>the utility that C++ does.
It is true that the mass migration to C++ gives advantages to those who
program in it, for the same reason that there are advantages to program
in Cobol.
In my experience, I can get a program up and running in ML (which I have
used more than Lisp) about 4-5 times faster than in C++. My disappointment
in C++ led me to explore the functional languages. I realize that everyone's
mileage may vary. From my experience, returning to C++ would cost me 80%
of my productivity, and the bandwagon benefits of C++ just cannot match
such a staggering cost.
>> The choice of language tools is not, as some would say, a matter of
>> "programming religion" purely. Some languages really do provide enhanced
>> productivity by abstraction. Who would deny that it is faster and safer
>> to write applications in C than in assembler?
>Please don't let Nudds hear you. And it is not always true. Just most of
>the time.
>As always, all this stuff is IMO - YMMV.
True enough. I'm not interested in a language war, but there has _got_ to
be space to discuss our choice of tools. I discussed some of the
difficulties above, and offer only one persons opinion.
I gave C++ a lot of well-intentioned and sincere time; I _started_ as a C
programmer trying to move to C++. I'm just trying
to encourage others to give the Lisp or ML the same chance I gave C++.
You might find that programming has become fun, interesting, and productive
again. And of course YMMV.
--Travis
Travis C. Porco
In article <5d8o3v$f...@Masala.CC.UH.EDU>,
cosc...@bayou.uh.edu <cosc...@Bayou.UH.EDU> wrote:
...
>Actually, it's the other way around. It's rare when C++ is needed
>to do something that a superior language cannot do better. C++
>is used for one reason and one reason only -- popularity. It is
>the fad, and hence it is used. ...
Exactly. We see, already, the retreat to the popularity argument.
This is a bad sign. The popularity argument has some--but only some--
merit. When it starts to be the most convincing reason to use
a language or system, you know the language or system has become
obsolescent, and a parachute to progress.
Thus C++ enters the company of DOS, FORTRAN-77, COBOL, SAS. Ugly,
obsolete tools that no one likes, but that we have been stuck with.
Maddening frustration and exhausted resignation replace the
enthusiasm of the dedicated programmers, and missed deadlines and
unpredictable failures become the expected standard.
Fortunately, with Standard ML, CAML, Common LISP, Scheme, Scheme-TK,
Prolog, Mercury, SmallTalk, MUPAD--there are now more excellent tools that
are available than ever before. And there are the even better tools
that tomorrow's men and women of imagination will provide. All
it takes is the open-mindedness to be sincerely open to change
and improvement.
--Travis Porco
Jose Castejon
Travis C. Porco wrote:
>
> In article <5d8o3v$f...@Masala.CC.UH.EDU>,
> cosc...@bayou.uh.edu <cosc...@Bayou.UH.EDU> wrote:
I find this discussion quite interesting, as it is addressing
implicitly a topic that has worried me for some time: What good is
C++ for? More to the point, what features does it provide that makes
it superior to C?
These questions are motivated by the same frustration that
other posters have expressed, to wit, that originating from a having
to learn a pretty complicated beast, without actually perceiving what
advantages the whole thing could incur into as compared to plain C.
I would be very grateful if somebody can provide examples of
the convenience of using C++ instead of C: what kind of problems,
techniques, and programming approaches. The books I have consulted
fail to do so.
vlad
po...@stat.Berkeley.EDU (Travis C. Porco) wrote:
>I'd rather spend what time and imagination I have on the problem at hand,
>freed from trying to understand the arcana of a language as needlessly
>complex as C++.
There is nothing that forces you to use the features you don't understand nor
can master. Once you understand and master the language (any language),
you will call for more features, since you will think the language is too
simple.
That's what happened to Smalltalk. It is regarded to be simple and people are
calling for more power now. In time being, when they don't get the desired power
from Smalltallk, they fake it using C++.
Vlastimil Adamovsky
** C++ and Smalltalk consultant **
* http://www.stepweb.com *
Travis C. Porco
Reply to Ian Joyner, regarding the futility of discussions about
computer languages.
I got a number of nasty flames by e-mail, so I'll respond to some
misunderstandings, and then leave discussions about languages to
folks with asbestos suits.
Yes, hard engineering discussions are indispensable to any
serious discussion of languages, and I have indeed read your paper on
C++. In fact, in its second edition, it was one of the things that
convinced me that there really _was_ something wrong with C++.
It is tough when you are an end user of a language. Since I'm not
a computer scientist or language professional, it is hard to state
_exactly_ why FORTRAN IV was harder to use than Pascal say, or why
C++ seems so much harder to me than ML. Nevertheless, I try hard
to stay out of language discussions, preferring to use the tools that
work for me and silently get the job done.
I also cheerfully admit that self-selected testimonials like the one
I posted earlier have no statistical validity. Any more than the
"everyone's using C++, so it must be the best" has validity.
The C++ people would do well to stay away from the bandwagon arguments
and the argument that says (or implies), "C++ isn't difficult; if you
can't master it at once, you must be stupid."
Of course, C++ is not all bad either. It did accomplish the goal of
adding object orientation to C. And low-level languages do have their
place. Sometimes you have to do some numerical task in an inner loop.
I also didn't mean to implicitly flame Ada. At least Ada was designed
consciously for a purpose. If you're going to write code for controlling
cruise missles, then safety ought be a very high priority indeed. I
admire the appreciation for human factor realities the Ada people always
seem to express, and I'd use Ada if I ever had to use a procedural
language.
OK, enough.
--Travis Porco
Paul Campbell
Jose Castejon wrote:
>
> Travis C. Porco wrote:
> >
> > In article <5d8o3v$f...@Masala.CC.UH.EDU>,
> > cosc...@bayou.uh.edu <cosc...@Bayou.UH.EDU> wrote:
>
> I find this discussion quite interesting, as it is addressing
> implicitly a topic that has worried me for some time: What good is
> C++ for? More to the point, what features does it provide that makes
> it superior to C?
>
> These questions are motivated by the same frustration that
> other posters have expressed, to wit, that originating from a having
> to learn a pretty complicated beast, without actually perceiving what
> advantages the whole thing could incur into as compared to plain C.
>
often in teams. To anyone who has worked in such an environment
the extra features of C++ over c offer huge advantages in areas of
modularity and code reuse.
In other words the one of primary design aim of C++ was to address
well known large-scale software engineering problems (The same problems
that OO is trying to address) while making use of peoples existing
C skills. It is really not possible to get a "feel" for these
issues unless you have been there so you will just have to take
it on faith that the advantages are real.
> I would be very grateful if somebody can provide examples of
> the convenience of using C++ instead of C: what kind of problems,
> techniques, and programming approaches. The books I have consulted
> fail to do so.
It is difficult to give convincing trivial or small demostrations
of these advantages because the advantages in these sorts of cases
are indeed often marginal. But it is precisly because the examples
are *small* that the advantages of using C++ do not appear to be
that great.
Paul C.
UK.
cosc...@bayou.uh.edu
Paul Campbell (Paul_Cam...@lucent.com) wrote:
: Jose Castejon wrote:
: >
: > Travis C. Porco wrote:
[Snip]
: C++'s intended target audience is programmers who on large projects,
: often in teams. To anyone who has worked in such an environment
: the extra features of C++ over c offer huge advantages in areas of
: modularity and code reuse.
With all due respect that's a load of BS. C++'s faults become
ever more acute *WHEN* you are on a large project working with
a team. C++ becomes an even bigger liability in that case
than it already is! Have some folks use C "features", do
funny things in constructors and/or destructors and throw
in some friend functions and see how quickly it takes for
your project to break down.
The one language that I've seen, which can truly claim the
honor of being developed with the team in mind is Ada.
Take a look at Ada and you'll see what a *REAL* language
is like. This isn't some dirty hack thrown together
and pushed off on a hapless public, this is a well thought
out system. You can see the reasoning behind features,
and the use for them rather than flaws and blunders
that are the definition of C++.
: In other words the one of primary design aim of C++ was to address
: well known large-scale software engineering problems (The same problems
: that OO is trying to address) while making use of peoples existing
: C skills. It is really not possible to get a "feel" for these
: issues unless you have been there so you will just have to take
: it on faith that the advantages are real.
The advantages are not real. If this was C++'s goal, then it is
an even greater failure than I thought. C++ makes it tremendously
easy for you to get lost in a maze of code, and have your code
do things behind your back. No way on Earth that such a system,
which is the pinnacle of danger could be designed for TEAM work.
In a group project you want *CONTROL* and *CLARITY*. You
want to be able to read and maintain the code produced by
others, and to discourage them from trying funny things.
C++ just opens a whole new pandora's box of tragedies.
: > I would be very grateful if somebody can provide examples of
: > the convenience of using C++ instead of C: what kind of problems,
: > techniques, and programming approaches. The books I have consulted
: > fail to do so.
: It is difficult to give convincing trivial or small demostrations
: of these advantages because the advantages in these sorts of cases
: are indeed often marginal. But it is precisly because the examples
: are *small* that the advantages of using C++ do not appear to be
: that great.
When the examples are small, it's hard to see what benefits C++
has over C.
When the examples are somewhat larger than trivial, then it's
easy to see what benefits C++ has over C.
When the examples are large, it's easy to see what benefits C++
does not have over C.
And the sad thing is that C is a miserable joke to begin with.
Comparing C++ to C is like comparing a dung beetle to a maggot
infested carcass. Niether can be considered desirable
by any stretch of the imagination, it's only in comparison
to each other that any illusion of quality can be brought
forth.
: Paul C.
: UK.
--
Cya,
Ahmed
Andrew Koenig
> But first, one must ask whether it is desirable to learn it in the first place.
> C++ is by all accounts exceedingly difficult to master.
I guess that depends on which accounts you consider.
--
--Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
cosc...@bayou.uh.edu
Travis C. Porco (po...@stat.Berkeley.EDU) wrote:
[Snip]
: Regarding C++, I've never heard anyone say that C++ is "simple", for instance.
: The common wisdom does seem to be that C++ is not mastered quickly. I've
: seen this opinion expressed in books on C++ and by its advocates as well
: as by its critics. The advocates usually are claiming that C++ is hard,
: but it is worth the effort.
Precisely. While C++ can be relatively simple if you use it as
a "better C", trying to use it for what it was intended for -- OO
development shows you just how complex a beast it is.
: Now I didn't get up one morning with dislike for C++;
Niether did I.
: on the contrary--I embraced it enthusiastically at first, and tried on
: many occasions to begin object-oriented design in C++ (in other words, I didn't
: just use it as "a better C"). I've been programming for many years,
: starting with Fortran and PL/I on a UNIVAC 1100 and Pascal on a Vax before
: moving to C. And I've just never experienced so much frustration as I
: experienced with C++.
I'm from a slightly different background. I started in BASIC then
other brief stints with various languages (SNOBOL being the one
I spent some appreciable time with) then on to Pascal, and then to
C, which turned me off so I went back to Pascal, but eventually
realizing the advantages C had over Pascal I returned to it.
It's interesting to note that the only reason I even gave C
a second chance was that Pascal (as defined by the standard)
was so useless. Anyhow I got to like C for the simple reason
that I didn't know that there was any better, and that whole mess
of arcana became like a macho badge of programmer's "mine is
bigger than yours". Then I started really trying to develop
code, and realized that C was a load of crap. C++ held my
interest for a while, but again it rapidly proved to be
as inadequate as C was, just a layer of hype over the core
of crud. At this time I was actively searching around for
other languages (programming is a hobby to me as well as my
job) and I found numerous superior languages including Ada,
and later I stumbled into functional programming.
Anyhow to make an already long story short, I got into Haskell,
and gave Lisp a second try and am enjoying it much more
the second time around. The only reason I even touch C now is
because my job requires it :(.
I'm a newbie to Lisp, but I can already develop projects in a
fraction of the time it would take me to do them in C. That's
saying something right there.
: And I don't think I'm alone. (A certain 'machismo' keeps some people from
: admitting that C++ is hard to learn and hard to use. Some colleagues of
: mine find mastery of C++ to be a mark of distinction, as if a person must
: be very smart or talented to have mastered this language.
: But obviously all such attitudes are illogical, since what is important
: is choosing the right tool for the job and GETTING THE JOB DONE.)
Heck, many believe that you aren't worthwhile unless your code is
an unreadable mess! The Obfusicated C contest comes to mind as
well as the numerous faces who've stopped me and said "dude
check this out, bet you can't tell what it's doing". Of course
looking at someone else's code for a short amount of time will
quickly change such attitudes.
: I'd rather spend what time and imagination I have on the problem at hand,
: freed from trying to understand the arcana of a language as needlessly
: complex as C++.
Full agreement here. I'm enjoying programming in Lisp. I can think
of what needs to be done and work on implementing it in rather
high level terms with few hurdles along the way. I chuckle to
myself as I'm well into my project when I think that by if I
were doing it in C or C++ I'd be trying to track down core dumps.
[Snip]
: It is true that the mass migration to C++ gives advantages to those who
: program in it, for the same reason that there are advantages to program
: in Cobol.
Yeah if you're willing to ignore the fact that the language is complete
drivel, this migration can almost seem worthwhile.
: In my experience, I can get a program up and running in ML (which I have
: used more than Lisp) about 4-5 times faster than in C++. My disappointment
: in C++ led me to explore the functional languages. I realize that everyone's
: mileage may vary. From my experience, returning to C++ would cost me 80%
: of my productivity, and the bandwagon benefits of C++ just cannot match
: such a staggering cost.
Same here. I think that for many people, programming in just about
any language other than C/C++ leads to productivity gains.
[Snip]
: >As always, all this stuff is IMO - YMMV.
: True enough. I'm not interested in a language war, but there has _got_ to
: be space to discuss our choice of tools. I discussed some of the
: difficulties above, and offer only one persons opinion.
Ditto here, although I do feel very bitter about C & C++. The fact
that it is a disaster area, yet I'm forced to use it, and it's so
widespread just depresses me. Do you realize how much further
the computer science field would be if C/C++ had not been adapted
as a de facto standard? Given that we had languages more advanced
than C++ over 2 decades ago, I can only weep at the thought of
where we COULD have been now if we had used one of those instead
of *THIS*.
Imagine if Smalltalk or Haskell or Lisp or ML were the big thing.
Imagine if we had the tools, support, the base and that we were
working off of that. We'd have software that worked, that arrived
sooner, that cost less, and that was more of a joy to program in.
That's why I feel bitter. I feel that the computer science field
as a whole has been given the shaft.
: I gave C++ a lot of well-intentioned and sincere time; I _started_ as a C
: programmer trying to move to C++. I'm just trying
: to encourage others to give the Lisp or ML the same chance I gave C++.
: You might find that programming has become fun, interesting, and productive
: again. And of course YMMV.
I agree fully. Admittedly Lisp originally turned me off because of
all those parenthesis and the non-infix notation, but now I'm getting
used to it, and it still is a great language in spite of that
(some may say because of that).
To anyone out there who's using C/C++, look around you. Pause and
check out other languages -- if for nothing else just to see what's
out there. There is a great world of wonderful languages that is
literally yours for the taking. From the object oriented purity
of Smalltalk to the safety and rigidity of Ada to the flexibility
and power of Lisp to the beauty, safety, and perfection of Haskell
and Concurrent Clean.
: --Travis
--
Cya,
Ahmed
Wanna grow
Up to be,
be a Debaser!
"Debaser" by the Pixies
Andrew Koenig
> I would be very grateful if somebody can provide examples of
> the convenience of using C++ instead of C: what kind of problems,
> techniques, and programming approaches. The books I have consulted
> fail to do so.
You might have a look at the book I wrote with Barbara Moo,
``Ruminations on C++'' (for more information, see
http://www.aw.com/cp/koenig-moo.html)
The book starts out with a programming example that shows
some things that C++ can do and C can't. Much of the rest
of the book is examples of using C++ to solve problems.
Bill House
FWIW, I think that the emerging field of agent-oriented programming may be
just the thing to promote a linguistic renaissance in software. Firstly,
writing IAs in C++ would be like going from Las Vegas to LA via Omaha --
agents need an agent execution environment, which C++ does not include.
Secondly, the notion that agents communicate via an agent communication
language (ACL) promotes the creation of specialized ACLs for
application-specific uses. These factors (IMO) will favor languages like
SmallTalk (dynamic execution environment) and Lisp (ideal for implementing
specialized ACLs).
-- Bill
cosc...@bayou.uh.edu <cosc...@Bayou.UH.EDU> wrote in article
>
> [Snip]
Travis C. Porco
In article <E57Mx...@nonexistent.com>, vlad <vl...@world2u.com> wrote:
>po...@stat.Berkeley.EDU (Travis C. Porco) wrote:
>>I'd rather spend what time and imagination I have on the problem at hand,
>>freed from trying to understand the arcana of a language as needlessly
>>complex as C++.
>There is nothing that forces you to use the features you don't understand nor
>can master. Once you understand and master the language (any language),
>you will call for more features, since you will think the language is too
>simple.
I want power, flexibility, and safety--without having to deal directly with
any pointers. In a word, Lisp or ML, or the Languages Which Are To Come. :)
--Travis
rey...@ibm.net
In <5dp3d1$a...@agate.berkeley.edu>, po...@stat.Berkeley.EDU (Travis C. Porco) writes:
>In article <E57Mx...@nonexistent.com>, vlad <vl...@world2u.com> wrote:
>>po...@stat.Berkeley.EDU (Travis C. Porco) wrote:
>
>>>freed from trying to understand the arcana of a language as needlessly
>>>complex as C++.
We all at times forget what programming is all about: Solving problems and
by extention using the right tools to solve a particular problem. I think C and
C++ have their place in developing low level systems (real time systems,
compilers...).
>>There is nothing that forces you to use the features you don't understand nor
>>can master. Once you understand and master the language (any language),
>>you will call for more features, since you will think the language is too
>>simple.
Perhaps the problem is that those "features you don't understand nor
can master" are the best way that language can do a particular task.
>I want power, flexibility, and safety--without having to deal directly with
>any pointers. In a word, Lisp or ML, or the Languages Which Are To Come. :)
>Travis
Have you ever looked at Modula-3?
The SRC distribution has:
A large standard library (libm3) providing
A multithread, incremental, generational, conservative garbage collector
Text manipulation.
Generic Containers: Lists, Sequences, Tables, SortedLists, SortedTables
Atoms and Symbolic expressions (Lisp like lists)
An extensible stream IO system
Typesafe binary object transcription (persistent objects)
Operating system interfaces
Portable interfaces to the language runtime
Matt Austern
cosc...@Bayou.UH.EDU (cosc...@bayou.uh.edu) writes:
> In numerous languages (like Haskell) pointers are never needed,
> and you can happily manipulate trees and other traditionally
> "pointer-dependent" data structures with greater ease than
> you could in languages which require pointers. In other languages
> the use of the aforementioned pointers are only required when
> you need certain data structures like trees (ie: Ada). In
> C however, you need pointers for tasks which do not require
> them -- modifying arguments to functions!
In C++, however, you don't need pointers for that task. Why pick
on C's deficiencies in an article that isn't even being posted
to a C newsgroup? This article is posted to comp.lang.c++ and
comp.lang.lisp; neither of those newsgroups deals with C.
cosc...@bayou.uh.edu
rey...@ibm.net wrote:
: In <5dp3d1$a...@agate.berkeley.edu>, po...@stat.Berkeley.EDU (Travis C. Porco) writes:
: >In article <E57Mx...@nonexistent.com>, vlad <vl...@world2u.com> wrote:
: >>po...@stat.Berkeley.EDU (Travis C. Porco) wrote:
: >
: >>>I'd rather spend what time and imagination I have on the problem at hand,
: >>>freed from trying to understand the arcana of a language as needlessly
: >>>complex as C++.
: We all at times forget what programming is all about: Solving problems and
: by extention using the right tools to solve a particular problem. I think C and
: C++ have their place in developing low level systems (real time systems,
: compilers...).
I'd probably restrict the domain much more to only portions of
the aforementioned systems which need the speed that C & C++
provide (assuming they can beat other better alternatives in
those fields).
: >>There is nothing that forces you to use the features you don't understand nor
: >>can master. Once you understand and master the language (any language),
: >>you will call for more features, since you will think the language is too
: >>simple.
: Perhaps the problem is that those "features you don't understand nor
: can master" are the best way that language can do a particular task.
With C & C++ it's more like these "features" are always looming
above our heads. For instance the whole pointer fiasco in C.
When is the user required to manually manipulate pointers?
In numerous languages (like Haskell) pointers are never needed,
and you can happily manipulate trees and other traditionally
"pointer-dependent" data structures with greater ease than
you could in languages which require pointers. In other languages
the use of the aforementioned pointers are only required when
you need certain data structures like trees (ie: Ada). In
C however, you need pointers for tasks which do not require
them -- modifying arguments to functions!
This is a clear example of complexity that is not needed, but
which is forced upon the user regardless. Now a portion of
your thinking is devoted to juggling the pointers of the
function you are writing, and remembering to manually dereference,
and realizing that any blunder at this point could easily lead
to an error requiring hours of debugging time.
The situation is even nastier when you already wrote a function,
but want its parameters to be modified, or vice versa. Then
you have to go and modify every reference to the variable
for a task which in other languages requires a mere alteration
of the parameter list in the declaration and invocation.
Again there is no excuse for this kind of mess, and it is a prime
example of the "needless arcana" of which a previous poster
spoke.
: >I want power, flexibility, and safety--without having to deal directly with
: >any pointers. In a word, Lisp or ML, or the Languages Which Are To Come. :)
: >Travis
: Have you ever looked at Modula-3?
[Snip of Modula-3 features]
I for one am happy that all was not lost on Pascal. It's nice to see
languages like Modula-3, Ada, and Oberon which inherited the
Pascal legacy of clarity, elegance, and simplicity, but not lack
of functionality. While I'm a functional language person myself,
if I couldn't have functional languages usurp C/C++'s dominance,
I believe that one of the above languages would make very
worthy alternatives.
--
Cya,
Ahmed
Brains for dinner, brains for lunch
Brains for breakfast, brains for brunch
Brains at every single meal
Why can't we have some guts?
"Brain Eaters" by the Misfits
cosc...@bayou.uh.edu
Matt Austern (aus...@isolde.mti.sgi.com) wrote:
: cosc...@Bayou.UH.EDU (cosc...@bayou.uh.edu) writes:
: > In numerous languages (like Haskell) pointers are never needed,
: > and you can happily manipulate trees and other traditionally
: > "pointer-dependent" data structures with greater ease than
: > you could in languages which require pointers. In other languages
: > the use of the aforementioned pointers are only required when
: > you need certain data structures like trees (ie: Ada). In
: > C however, you need pointers for tasks which do not require
: > them -- modifying arguments to functions!
: In C++, however, you don't need pointers for that task. Why pick
: on C's deficiencies in an article that isn't even being posted
: to a C newsgroup? This article is posted to comp.lang.c++ and
: comp.lang.lisp; neither of those newsgroups deals with C.
Oh you want C++ deficiencies? Well off the top of my head:
1) Type checking is *STILL* a joke
2) They still haven't fixed the problems with arrays
not being first class data types -- check out
the problems with template functions.
3) Multiple inheritance. Need I say more?
4) Name mangling.
5) Pointers are still laughable.
6) As if the trouble with pointers isn't enough, references
were added with even more danger!
7) You can typecast yourself to hell and back.
8) The whole concept is flawed (OO concepts pasted onto
an unreadable "portable assembler"?).
There you go -- take your pick.
BTW, these were off the top of my head.
Travis C. Porco
In article <5dqhl2$ej2$1...@news-s01.ca.us.ibm.net>,
<fran...@natserv.com> wrote:
>In <5dp3d1$a...@agate.berkeley.edu>, po...@stat.Berkeley.EDU (Travis C. Porco) writes:
>We all at times forget what programming is all about: Solving problems and
>by extention using the right tools to solve a particular problem. I think C and
>C++ have their place in developing low level systems (real time systems,
>compilers...).
Yes. Though even here there are solid alternatives; I particularly admire
Ada's secure, no-nonsense approach. I cannot speak for systems programmers,
but I can see that C's low-level approach and widespread availability would
make it a good choice for such tasks. After all, that's what it was designed
for in the first place.
...
>Perhaps the problem is that those "features you don't understand nor
>can master" are the best way that language can do a particular task.
>>I want power, flexibility, and safety--without having to deal directly with
>>any pointers. In a word, Lisp or ML, or the Languages Which Are To Come. :)
>>Travis
>Have you ever looked at Modula-3?
...
I've never used Modula-3, but since Wirth wrote it, I bet it is safe,
elegant, and consistent.
--Travis
Vlasyimil Adamovsky
po...@stat.Berkeley.EDU (Travis C. Porco) wrote:
>I want power, flexibility, and safety--without having to deal directly with
>any pointers. In a word, Lisp or ML, or the Languages Which Are To Come. :)
VisualBasic version 5 supports POINTERS!!!! It is their marketing WEAPON!!!
Bob Jarvis
Vlasyimil Adamovsky <vl...@world2u.com> wrote in article <E5Gyu...@nonexistent.com>...
> po...@stat.Berkeley.EDU (Travis C. Porco) wrote:
>
> >I want power, flexibility, and safety--without having to deal directly with
> >any pointers. In a word, Lisp or ML, or the Languages Which Are To Come. :)
>
> VisualBasic version 5 supports POINTERS!!!! It is their marketing WEAPON!!!
Oh, now *that's* a scary thought! I've seen organizations adopt VB because "...the
programmers are too dumb to cope with pointers". Now they're going to put pointers
in VB? Well, maybe those that flee in panic before the Evil Pointer Beasts will find
the Safe Way Home to Smalltalk. :-)
--
Bob Jarvis
Mail addresses hacked to foil automailers!
Send replies to jar...@timken.com
Erik Naggum
* cosc...@Bayou.UH.EDU
| In C however, you need pointers for tasks which do not require them --
| modifying arguments to functions!
the very existence of a "better" mechanism to do this in C++ (references)
suggest that multiple return values really do make a lot of sense, despite
all the hostile arguments from certain camps when you suggest this. that a
widely used tool like `perl' also supports them as a matter of course, and
to its users delight, is perhaps indicative of a fundamental flaw in the
argument that functions in programming languages should only return one
value, as opposed to functions in mathematics, which already differ greatly
from "our" functions.
incidentally, I happen to dislike the approaches to faking the return of
multiple values that don't actually return multiple values: structs in C,
lists in Scheme, OUT arguments in Ada, NAME in Simula, VAR in Pascal,
references (mere syntactic sugar for pointers) in C++, etc.
my favorite example is getting the current time under Unix and in C:
`gettimeofday' takes two pointers to structures you have to declare and
possibly allocate memory for, fills them in for you, and then you get to
retriev the values from them. the function returns four integers in this
very complicated way: seconds since the epoch, microseconds into the
current second, time zone as the number of minutes west of Greenwich, and
the type of daylight savings time to apply. let's also not forget that
`gettimeofday' includes an error return value to indicate only one kind of
error: "an argument address referenced invalid memory", or a stray pointer.
to decode this time into your current timezone, you need to decode it with
the function `localtime', which, unsurprisingly, takes a pointer to the
first return value from `gettimeofday' and returns a pointer to statically
allocated memory that contains the values you need in a structure. you
need to make certain that you copy all of these values to your own space
before some other function clobbers it. `localtime' returns 11 values,
most of which you don't need. (and then, of course, the day of the month
is a number in the range 1-31, but the month is a number in the range 0-11
and the year is 1900 less than the actual year, but that's another can of
worms.) all this to achieve the effect of multiple return values! to
summarize: `gettimeofday' requires pointers to preallocated memory to
return multiple values, and has an error return value to barf on the
address of that memory, while `localtime' returns a pointer to a static
memory area overwritten by each call. this epitomizes the Unix interface
as I see it -- Unix doesn't give its programmers the time of day.
#\Erik
--
my other car is a cdr
cosc...@bayou.uh.edu
Erik Naggum (er...@naggum.no) wrote:
: * cosc...@Bayou.UH.EDU
: | In C however, you need pointers for tasks which do not require them --
: | modifying arguments to functions!
: the very existence of a "better" mechanism to do this in C++ (references)
: suggest that multiple return values really do make a lot of sense, despite
: all the hostile arguments from certain camps when you suggest this.
Multiple returns make plenty of sense.
: that a
: widely used tool like `perl' also supports them as a matter of course, and
: to its users delight, is perhaps indicative of a fundamental flaw in the
: argument that functions in programming languages should only return one
: value, as opposed to functions in mathematics, which already differ greatly
: from "our" functions.
Frankly I'm all for the return of multiple values from functions.
: incidentally, I happen to dislike the approaches to faking the return of
: multiple values that don't actually return multiple values: structs in C,
: lists in Scheme, OUT arguments in Ada, NAME in Simula, VAR in Pascal,
: references (mere syntactic sugar for pointers) in C++, etc.
Well I like to be able to simply return the values without
faking also, but if the "faking" is transparent then I won't
mind. For instance, Haskell doesn't allow multiple returns
from functions but it does consider the tuple to be a basic
data type and therefore multiple values can be encapsulated
in a tuple and easily used. For instance:
(x, y, z) = f a b c
Here, f is returning one value, a tuple, but you can place
variables inside the tuple and they will get the value of
each corresponding element. Tuples are also homogenous, so
even though this is "faking", it's virtually invisible and
is even better than the real thing since you can store
the entire return in one variable and later pick out the
components with great ease and elegance.
[Snip -- long but excellent example of the convolutions you can
go through to simulate multiple return values]
: all this to achieve the effect of multiple return values! to
: summarize: `gettimeofday' requires pointers to preallocated memory to
: return multiple values, and has an error return value to barf on the
: address of that memory, while `localtime' returns a pointer to a static
: memory area overwritten by each call. this epitomizes the Unix interface
: as I see it -- Unix doesn't give its programmers the time of day.
All I can say is I couldn't agree more. Great example and a
great point.
: #\Erik
: --
: my other car is a cdr
--
Cya,
Ahmed
cosc...@bayou.uh.edu
cosc...@bayou.uh.edu (cosc...@Bayou.UH.EDU) wrote:
: Erik Naggum (er...@naggum.no) wrote:
: : * cosc...@Bayou.UH.EDU
: : | In C however, you need pointers for tasks which do not require them --
: : | modifying arguments to functions!
: each corresponding element. Tuples are also homogenous, so
^^^^^^^^^^
Hetereogenous is what I meant to say. Apologies all.
[Snip]
: : #\Erik
: : --
: : my other car is a cdr
: --
: Cya,
: Ahmed
--
Cya,
Ahmed
I had an operation, a statement of our times
They tied my balls together, what's inside is not alive
"Operation" by the Circle Jerks
Simon Brooke
In article <E5Gyu...@nonexistent.com>,
vl...@world2u.com (Vlasyimil Adamovsky) writes:
> po...@stat.Berkeley.EDU (Travis C. Porco) wrote:
>
>>I want power, flexibility, and safety--without having to deal directly with
>>any pointers. In a word, Lisp or ML, or the Languages Which Are To Come. :)
>
> VisualBasic version 5 supports POINTERS!!!! It is their marketing WEAPON!!!
I think this is the point at which the heroic councel in the film
folds his arms and smiles sweetly at the judge.
I have no questions, M'Lud. The defence rests.
--
si...@intelligent.co.uk (Simon Brooke) http://www.intelligent.co.uk/~simon
[ This mind intentionally left blank ]
Cyber Surfer
With a mighty <30648287...@naggum.no>,
er...@naggum.no wibbled into the void...
[beautiful critique of C/C++ kludges for returning multiple values]
> to summarize: `gettimeofday' requires pointers to preallocated memory to
> return multiple values, and has an error return value to barf on the
> address of that memory, while `localtime' returns a pointer to a static
> memory area overwritten by each call. this epitomizes the Unix interface
> as I see it -- Unix doesn't give its programmers the time of day.
This problem isn't even unique to Unix, but I don't want to spoil such
a wonderful punchline with mere pedantry. ;-)
If you'll permit me, I'd like to save this in a page in my homepage,
as I can forsee a time when it'll be useful to refer a C++ programmer
to it. You'll get _full_ credit for it, of course.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
b...@teco.net
"Dann Corbit" <dco...@solutionsiq.com> starts a C++/Lisp war...
>What a load of crap. If you are talking about 'return on investment' C++
>is absurdly higher than Common Lisp.
No it's not. Not by a long shot.
>Look at the amount of development
>that is going on in C++ and compare it with what is going on in Lisp.
What exactly does that prove??
>Only
>a fool will thing they will get a higher ROI from a study of Lisp, which is
>at least as difficult to master as C++.
No it's not.
>Go to a bookstore, and see how
>much effort is being put forth to provide C++ instruction, compared to
>Lisp.
Show's how much more difficult C++ is that it needs so many books to
explain it.
>Will you be able to use your Lisp skills on every platform you might
>need to work on?
Yes, definitely.
>Look at the tools that are available for C++ compared to
>Lisp. Will you be able to pull a big pile of Lisp code into your design
>tool and automatically create object diagrams from it?
Yes, of course.
>On dozens of
>platforms?
Sure.
>Yes, I do realize that Smalltalk and Lisp are viable tools that
>do answer real-life business problems. Sometimes they are the best tool
>for the job. Just less often than C++.
Wrong.
>How many trained programming
>resources does a typical organization have for C++ verses those
>alternatives?
What does that prove?
>Neither Smalltalk nor Lisp will ever have the following
What does that prove?
>nor
>the utility that C++ does.
Wrong.
>As always, all this stuff is IMO - YMMV.
If it's just your opinion, then why go around stating this crap as facts?
Chris Bitmead
>incidentally, I happen to dislike the approaches to faking the return of
>multiple values that don't actually return multiple values: structs in C,
>lists in Scheme,
I don't see the problem of returning lists as in Scheme.
There is a proposed standard for multiple return values in scheme. It
can be implemented as syntactic sugar for returning lists.
Chris Bitmead
>With all due respect that's a load of BS. C++'s faults become
>ever more acute *WHEN* you are on a large project working with
>a team. C++ becomes an even bigger liability in that case
>than it already is! Have some folks use C "features", do
>funny things in constructors and/or destructors and throw
>in some friend functions and see how quickly it takes for
>your project to break down.
I do agree. C++ does tend to impose more structure and order on large
projects. Trouble is, eventually too much time is spent trying to keep
the structure and order coherent (not to mention compile times), and
too little time actually making real progress and it all breaks down.
Erik Naggum
* Erik Naggum <er...@naggum.no> writes:
| incidentally, I happen to dislike the approaches to faking the return of
| multiple values that don't actually return multiple values: structs in C,
| lists in Scheme,
* Chris Bitmead
| I don't see the problem of returning lists as in Scheme.
that's just like saying you don't see the problem of returning structures
in C, isn't it? returning a compound structure is very different from
returning multiple values, and specifically so in the many cases where only
the first value will be used.
when multiple return values require special care in the compiler, be that
with some heavily optimized forms of lists, or register-allocated vectors
or whatever, it is silly to argue that they aren't special and could just
as well be represented by some ordinary data type.
| There is a proposed standard for multiple return values in scheme. It
| can be implemented as syntactic sugar for returning lists.
I really hope it can be implemented more efficiently, too.
#\Erik
--
if you think big enough, you never have to do it
Chris Bitmead
>* Erik Naggum <er...@naggum.no> writes:
>| incidentally, I happen to dislike the approaches to faking the return of
>| multiple values that don't actually return multiple values: structs in C,
>| lists in Scheme,
>
>* Chris Bitmead
>| I don't see the problem of returning lists as in Scheme.
>
>that's just like saying you don't see the problem of returning structures
>in C, isn't it? returning a compound structure is very different from
>returning multiple values, and specifically so in the many cases where only
>the first value will be used.
I fail to see the big difference. Sure, having a standard way of doing
it allows the compiler to make more optimisations. (The more library
functions in a language that are standardised the better you can
optimize. Nothing unique about multiple return values).
Just to illustrate, here is an example the Scheme multiple return
value standard proposal, implemented as lists. (It's probably a naive
and flawed implementation), but you get the idea about how little
difference there is.
(define values list)
(define (call-with-values val func) (apply func (val)))
e.g.
(call-with-values (lambda () (values 6 7)) *)
=>42
>when multiple return values require special care in the compiler, be that
>with some heavily optimized forms of lists, or register-allocated vectors
>or whatever, it is silly to argue that they aren't special and could just
>as well be represented by some ordinary data type.
>
>| There is a proposed standard for multiple return values in scheme. It
>| can be implemented as syntactic sugar for returning lists.
>
>I really hope it can be implemented more efficiently, too.
>
>#\Erik
>--
>if you think big enough, you never have to do it
--
---------------------------------------------------------------
| Chris Bitmead.....................................9690 5727 |
| Chris....@Alcatel.com.au............................... |
---------------------------------------------------------------
"Simply drag your mother in law's mobile phone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."
Erik Naggum
* Erik Naggum
| that's just like saying you don't see the problem of returning structures
| in C, isn't it? returning a compound structure is very different from
| returning multiple values, and specifically so in the many cases where only
| the first value will be used.
* Chris Bitmead
| I fail to see the big difference. Sure, having a standard way of doing
| it allows the compiler to make more optimisations. (The more library
| functions in a language that are standardised the better you can
| optimize. Nothing unique about multiple return values.)
|
| Just to illustrate, here is an example the Scheme multiple return value
| standard proposal, implemented as lists. (It's probably a naive and
| flawed implementation), but you get the idea about how little difference
| there is.
sigh. let me illustrate what I mean with "in the many cases where only the
first value will be used" since you (and others) continue to talk about
operations on _all_ the returned values. in Common Lisp, `floor' of one
argument returns two values, the largest integer smaller than the argument,
and the "rest". normally, you don't need the second value.
in Common Lisp, (+ (floor 17.42) 3) evaluates to 20. if I read your Scheme
proposal right, you need to know that the function can return multiple
values and the expression becomes (+ (first-value (floor 17.42)) 3), where
`first-value' is just another name for `car'. it is _this_ aspect of
multiple values that requires special handling in the compiler, and which,
if you fake them with lists or whatever, you _still_ must recognize as a
special property of the first of the returned values that does not apply to
the first element of a returned list.
a multiple value return mechanism that does not cons is _very_ valuable.
one that conses and costs a hell of a lot more than normal value returns
(e.g., in always having to fetch the first value explicitly) is just too
painful to use.
William D Clinger
This message was composed in response to a thread whose subject
was "What is wrong with OO ?". I have changed the subject line,
removed comp.lang.c++ from the list of newsgroups, and added
comp.lang.scheme (in case its residents need new fuel).
The code posted by Chris Bitmead was not a correct implementation
of R5RS multiple return values, which requires (VALUES X) to be
equivalent to X, and requires (CALL-WITH-VALUES * -) to evaluate
to -1.
It is true that an inefficient version of the R5RS multiple value
facility can be implemented in R4RS Scheme using lists, but the
code is somewhat more complex. Furthermore an implementation
in R4RS Scheme wouldn't be able to perform full error checking.
Erik Naggum (er...@naggum.no) wrote:
> in Common Lisp, (+ (floor 17.42) 3) evaluates to 20. if I read your Scheme
> proposal right, you need to know that the function can return multiple
> values and the expression becomes (+ (first-value (floor 17.42)) 3), where
> `first-value' is just another name for `car'.
If FLOOR were to return two values, and FIRST-VALUE were a procedure,
then both
(+ (floor 17.42) 3)
and (+ (FIRST-VALUE (FLOOR 17.42)) 3)
would be errors because both contain a call to FLOOR in which the
continuation demands exactly 1 argument.
This is a matter of philosphy. The Scheme community considered
a semantics in which the continuation passed to FLOOR would
accept 1 or more return values, but some felt that Common Lisp's
implicit ignoring of extra return values would lead to bugs in
which a return value that should not be ignored would be.
#flame on
In fact, the Scheme community went so far as to adopt a semantics
in which
(begin (floor 17.42) 3)
would be an error if FLOOR were to return 2 values. I think this
is incredibly silly. I would be unhappy with any implementation
of R5RS Scheme that does not provide the option of ignoring such
"errors".
#flame off
Erik continued:
> a multiple value return mechanism that does not cons is _very_ valuable.
This is an endorsement of the R5RS mechanism, which does not
require consing.
Will
Marco Antoniotti
William D Clinger <wi...@ccs.neu.edu> writes:
...
>
> #flame on
>
> In fact, the Scheme community went so far as to adopt a semantics
> in which
>
> (begin (floor 17.42) 3)
>
> would be an error if FLOOR were to return 2 values. I think this
> is incredibly silly. I would be unhappy with any implementation
> of R5RS Scheme that does not provide the option of ignoring such
> "errors".
>
> #flame off
>
> Erik continued:
> > a multiple value return mechanism that does not cons is _very_ valuable.
>
> This is an endorsement of the R5RS mechanism, which does not
> require consing.
>
> Will
(declaim (extension:flame-on))
Congratulations to the Scheme community :) It took them 13 years to
adopt as a standard what was there and obviously useful (and non
consing) in Common Lisp in 1984. Of course, in the process the
semantics had to be changed. :)
In the year 2010 R6RS will probably contain a "standard" version of
'format' or maybe of keywords parameters. :)
(declaim (extension:flame-off))
--
Marco Antoniotti - Resistente Umano
===============================================================================
robert fielding
Chris Bitmead <Chris....@Alcatel.com.au> wrote in article
<BITMEADC.97...@Alcatel.com.au>...
The biggest problem of all is that you can't neglect the human aspect of
programming language design. The discipline is not in the language itself,
so you have to waste a good chunk of time and money on imposing it. In
the design of C++ is a punishment/reward system that is heavily in favor of
violating OO.
True programming freedom is having a language that is strict enough to make
certain classes of programming errors unthinkable, and real optimization is
using better
algorithms (which may be too unwieldly to write in a really raw language
like C++).
For example:
O(n^2) algorithms written in optimized assembler can't compete with
O(n*lg(n)) algorithms
written in ...say pitiful VB... if you give it enough data to chew on.
With 32M-64M becoming standard on PCs, that day is coming very soon. The
capacity of PCs is changing the whole meaning of 'optimization' and it is
making less and less sense to haggle on bytes and CPU cycles. Really good
algorithms can be a pain to write in
C++ because it's too close to the metal, so you see silly people trying to
save bytes
and CPU cycles within an algorithm that is wasting an order of magnitude
more than it
ever should in any language whatsoever. C++ should not be used for most
types
of applications because of its promiscuity, inconsistency, and complexity.
rob