From owner-freebsd-chat Wed Mar 6 15:36:20 2002 Delivered-To: freebsd-chat@freebsd.org Received: from mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 330FA37B404 for ; Wed, 6 Mar 2002 15:36:12 -0800 (PST) Received: (qmail 78219 invoked by uid 100); 6 Mar 2002 23:36:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.42985.820103.310309@guru.mired.org> Date: Wed, 6 Mar 2002 17:36:09 -0600 To: Joe Halpin Cc: freebsd-chat@FreeBSD.ORG Subject: Re: C vs C++ 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> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.48 (Python 2.2 on freebsd4) Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Joe Halpin types: > Mike Meyer wrote: > > Joe Halpin 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. 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