From: ········@bayou.uh.edu
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5ldgf5$v1t$1@Masala.CC.UH.EDU>
Dean Roddey (·······@ng.netgate.net) wrote:
: ········@bayou.uh.edu wrote:
: >
: > Common Lisp does this, and as usual does it much better. You are
: > given a powerful world AND the ability to easily define a new world,
: > right down to creating your own language structures -- in essence
: > re-creating the language in ways that C++ can't even begin to dream
: > of. Your argument falls short.
: >
: The fact that another language does it means that C++ does not?
C++'s lack of features is only one aspect of our discussions. However,
even pointing out poorly implemented features, and ones implemented
late at that are very relevant as they show poor design. That is
my ultimate point.
: Once
: again, it makes no difference whether Lisp does it or not, becuase Lisp
: is so far out of the mainstream that it is irrelevant. Get Lisp into the
: mainstream and, if its really better than C++, I'll be on it like white
: on rice. I'm more than ready to take something better, but its got to
: also be commercially and professionally viable.
A language's quality has nothing to do with how frequently it is used.
That is a function of marketing and marketing alone. C++ made it
because it was a superset of C, so it automatically had a huge
advantage right there. C made it because it was almost mandatory
to know it to program in Unix. Notice how quality had nothing
to do with the rise of these languages.
: I'm not sure though that I WANT to create a new language. C++ does not
: allow you to create different fundamental language syntax or define new
: operators. I think that is the correct cut off point. Building worlds
: upon a common substrate is a powerful concept because the user's
: language skills apply to any new system. Only the higher level world
: implemented is different.
You are avoiding the point -- and that is that Common Lisp is more
powerful than C++ and more flexible to boot, so your entire argument
that C++ is the way it is because you can't provide power without
sacrificing flexibility is nonsense.
: > And languages that give you nothing will always be a burden on the
: > programmer who is forever cursed with having to re-invent the
: > wheel.
: >
: No, they BUY a wheel out of a nice selection of wheels that roll they
: way they like instead of having to take the wheel that comes on the car.
So you are saying that C++ is like a car without wheels -- which
is informative because a car without wheels cannot be driven which
makes it useless. The analogy fits perfectly.
: > So instead of providing power that the user could use, we say "hey
: > it could be out of date, let's not give the user diddly"?
: >
: Already answered.
Inadequately as usual.
: > Power can be provided with both the ability to re-implement as needed,
: > and to take advantage of a flexible framework. You are thinking
: > in a simplistic, flawed manner -- the C++ way.
: >
: You'll have to expand on that argument cause I get nothing out of it.
: How can your language X, which implements a particular view of a file
: system take advantage of a different file system, with different
: capabilities without effectively changing its file system API?
By providing a flexible API that can accomodate many different file
systems that's how. Then the implementation underneath does whatever
it needs to do, the programmer need not be aware of it.
: If it
: changes its file system API for every platform its on, how is that all
: that different from C++ having class libraries on each platform, except
: that the C++ libraries on that platform probably take better advantage
: of the platform capabilities?
You are confusing interface with implementation. I find it delightfully
ironic that this mistake would be made by a C++ advocate. It just
adds more credence to what I'm saying.
: How can it take advantage of a fundamental
: system like NT's security system in which elaborate permissions can be
: set on every single object in the system without fundamentally changing
: its entire library API?
I just answered that above.
: It would be nice to have a single API that fits all, but it will never
: happen. I've done a lot of work in this area and I know its not possible
: to make everyone happy. Java's AWT will soon discover this ugly fact, if
: they have not already.
It depends on the scenario now doesn't it? In the case of tradeoffs
it is possible to reach a good compromise -- which is what your
argument for C++ is, that it is a good compromise, or are you
retroactively rescinding your argument now?
: ------------------------
: Dean Roddey
: The CIDLib Class Libraries
: 'CIDCorp
: ·······@ng.netgate.net
: http://ng.netgate.net/~droddey/
: "Software engineers are, in many ways, similar to normal people"
--
Cya,
Ahmed
The grass is never greener,
On the other side,
I'll sit right here and frolic in the dirt and gravel
"Let the Bad Times Roll" by the Vandals