Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Mar 2002 17:36:09 -0600
From:      "Mike Meyer" <mwm-dated-1015889770.ae113d@mired.org>
To:        Joe Halpin <joe.halpin@attbi.com>
Cc:        freebsd-chat@FreeBSD.ORG
Subject:   Re: C vs C++
Message-ID:  <15494.42985.820103.310309@guru.mired.org>
In-Reply-To: <3C8686E6.F76B8B56@attbi.com>
References:  <3C8529DA.FA8ABCE@mindspring.com> <20020305164151.T5854-100000@alpha.yumyumyum.org> <15493.24457.986109.726909@caddis.yogotech.com> <3C8573B2.35144B17@attbi.com> <200203051407.g25E7Cd67446@bugz.infotecs.ru> <001201c1c464$06416fd0$f642d9cf@DROID> <15493.49014.254461.125446@guru.mired.org> <3C8686E6.F76B8B56@attbi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Joe Halpin <joe.halpin@attbi.com> types:
> Mike Meyer wrote:
> > Joe Halpin <joe.halpin@attbi.com> types:
> > > 1. C++ is a more difficult language than C because it does more stuff
> > > than C. Ditto vs Java.
> > No, it doesn't do more stuff than C, Neither does Java. See the
> > Church-Turing thesis. Java and C++ are harder to learn because they
> > have more *features* than C.
> Sorry, I thought "had more features" was something like "did more".

I don't see it that way.  more in a bit.

> For example, assembly language doesn't do anything Python can't, but
> Python does more (at least, per statement) than assembly language.

That depends on the statements in question, the assembler, and the
coding style of the two programmers.

> I'm not sure I  understand your point. Are you trying to say that all
> Turing complete  languages are equally difficult?

No, I'm saying that all turing complete languages can do the same set
of things. If you want to divide languages up into levels in some
manner, it makes more sense to talk about "features".  For example,
LISP-like languages have closures. OO languages can emulate them with
callable objects. To do either in C, you pretty much have to write an
interpreter for a language to do it - but you can still do it.

They thing is, those two features don't make the languages more
difficult; they make them less difficult, because you they allow you
to do things easily that would be very hard in C. In at least one case
- Scheme - features get added by removing restriction rather than
adding language constructs. That means that there is less to learn
about the language, even though it has more features. Experienced
programmes have problems with it because they have to unlearn things
they thought were invariants across languages.

> > > For years I have been seeing this assertion on the net over and over. I
> > > still don't see the expected result (ie, Java applications displacing
> > > C/C++ applications).
> > I see it happening, then the products vanish because they can't
> > compete on a speed basis. VM's were a good idea when UCSD did it back
> > in the mid 70s. I think the hardware is fast enough to support it now,
> > but you've got to tie the parts together write.
> So are you agreeing with me?

Half-way. People believe it can be done, and they get the code written
- only to discover that the results aren't fast enough.

> My experience is that most performance problems come about from the way
> something was coded, not the language it was coded in. Even in Java, you
> can do JNI functions if performance is really an issue.

That's close to my experience, with one exception. Once you get to
high level languages (and I don't count C as such - it's a portable
assembler) the quality of implementation of the libraries is
critical. I know of cases where code written in Java outran the same
algorithms in C, because the Java spent 90% of it's time in optimized
string routines in the java implementation, whereas the C used
hand-rolled C routines to that oinked every time they were invoked.

> > Python is succeeding in some strange places, because it's trivial to
> > take a collection of subroutines that deal with a data structure they
> > pass back and forth as arguments, and turn it into a Python
> > object. Which means you get to play with those complex, compiled
> > environments in an interpreted environment that could be used as a
> > shell, if you were really crazy.
> Don't know anything about Python. How does this affect C vs C++? Or Java
> vs C++? or perfomance, or ... ?

Python provides a VM, ala Java, and as such if you're considering
Java instead of C++, Python would be a valid contender. In general,
it's not as fast because typing is done at runtime instead of compile
time. Given my druthers - which doesn't happen often enough - I'd
rather write in python, profile the code, then rewrite the classes
were most of the time is spent in either C or Java, depending on the
project constraints.

	<mike
--
Mike Meyer <mwm@mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15494.42985.820103.310309>