Why is python not written in C++ ?
in [Python]
|
From: Paul Rubin on 3 Aug 2010 05:48 Nobody <nobody(a)nowhere.com> writes: > One feature which can't readily be implemented in C is the automatic > clean-up side of the RAII idiom. I once did that by having an explicit stack of finalization records linked through the call stack. The "throw" routine would traverse the links to call the finalizers, until it found the matching "catch" which contained a longjmp target. It wasn't as crazy as this makes it sound.
From: Grant Edwards on 3 Aug 2010 10:05 On 2010-08-02, Aahz <aahz(a)pythoncraft.com> wrote: > In article <f9e652d6-3945-4c18-92f3-b85b994feb0b(a)k8g2000prh.googlegroups.com>, > Peter <peter.milliken(a)gmail.com> wrote: >>On Aug 3, 7:42=A0am, Mark Lawrence <breamore...(a)yahoo.co.uk> wrote: >>> On 02/08/2010 00:08, candide wrote: >>> >>> I can't understand why any serious programmer mentions C++. As soon >>> as I read it, I have to rush either to the kitchen to find a bowl to >>> throw up in, or head for the toilet so I can talk to the great white >>> telephone. >> >>With you there Mark - IMO C++ is an abortion that should never have >>seen the light of day. The idea of experimenting with creating an OO >>language by extending C wasn't such a bad idea for a "play thing" (by >>Stroustrop) but the fact that it somehow escaped from the Lab and >>people picked it up and ran with it on a commercial basis is just >>plain wrong! > > http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html It's funny (and sad) because it's so close to being true. (The effect, I mean, not necissarly the intent.) There's no computing problem so simple that it can't be solved in a complex and obtuse manner in C++. I know that's true of any language, but from what I've seen over the years, it "more true" in C++. -- Grant Edwards grant.b.edwards Yow! Should I get locked at in the PRINCICAL'S gmail.com OFFICE today -- or have a VASECTOMY??
From: Grant Edwards on 3 Aug 2010 10:11 On 2010-08-02, Paul Rubin <no.email(a)nospam.invalid> wrote: > Michael Torrie <torriem(a)gmail.com> writes: >> Sometimes, C++ is just the right tool for the job, despite all its >> warts.... C++'s object semantics (guaranteed destruction, scoping, >> etc) can sometimes work very well when you need the speed of a >> compiled language, but don't want to be quite as low-level as C. >> >> In this case, C++ is certainly not a better tool for the job than C. > > The stuff C++ adds to C is a mix of good and bad, and it's reasonably > possible to use just the good stuff and ignore the bad. Except nobody does. ;) > I've never programmed in Ada but I'm intrigued by these articles: > > http://adahome.com/Ammo/cpp2ada.html > http://www.adaic.org/whyada/ada-vs-c/cada_art.html > > I have the impression that Ada has an undeservedly bad rap because of > its early implementations and its origins in military bureaucracy. > I'd certainly consider it as an alternative to C or C++ if I had to > write a big program in a traditional procedural language. I've always thought Ada was a pretty nice embedded/systems languages, but some of the initial implementations were indede horrible. The one I used for a little while ran on VAX/VMS but didn't use the VMS filesystem, editors, or other utilities. The Ada enviroment was a completely closed, walled system. It kept it's "files" in some sort of opaque database and they could only be accessed, edited, compiled, etc. from within the Ada development enviornment (a system with really, really awful editing and build tools). There was a way to import/export files, but it wasn't easy. Still, the Ada-environment tools were _so_ bad that people exported a file, edited it using some VMS-based editor and the re-imported it whenever a change needed to be made. Apparently the intent was to provide the identically awful user-torturing-experience regardless of OS. -- Grant Edwards grant.b.edwards Yow! I represent a at sardine!! gmail.com
From: Carl Banks on 3 Aug 2010 12:15 On Aug 3, 2:29 am, John Bokma <j...(a)castleamber.com> wrote: > Carl Banks <pavlovevide...(a)gmail.com> writes: > > On Aug 1, 6:09 pm, John Bokma <j...(a)castleamber.com> wrote: > >> Roy Smith <r...(a)panix.com> writes: > >> > In article <4c55fe82$0$9111$426a3...(a)news.free.fr>, > >> > candide <cand...(a)free.invalid> wrote: > > >> >> Python is an object oriented langage (OOL). The Python main > >> >> implementation is written in pure and "old" C90. Is it for historical > >> >> reasons? > > >> >> C is not an OOL and C++ strongly is. I wonder if it wouldn't be more > >> >> suitable to implement an OOL with another one. > > >> > One thing that comes to mind is that it's much easier to distribute C > >> > libraries than C++ libraries. > > >> In the beginning of C++ there were programs that just converted C++ to C > >> (frontends). At least that is how the C++ compiler Acorn sold worked. > >> So I don't think your argument was much true back then. > > > No, it was that way back then too. They might all generate C code but > > different C code by different backends wouldn't be able to call each > > other natively. > > If you convert C++ to C, and compile the C code then that's not > different from compiling the C code itself, correct? > > > > For instnace the function > > > int foo(int); > > > might be name-mangled this way in one cfront: > > > foo$d > > > and this way in another: > > > ____int_foo__int_i > > But they call both the C libraries in the same way. Go look at the original claim, the one that you responded to. "It's much easier to distribute C libraries than C++ libraries." Of course they can both call C libraries. All modern C++ compilers can too, not just cfronts. What almost no C++ compiler or C++ front can do is call a C++ library that a different C++ compiler or C++ front generated. (Unless they export function calls with C linkage, but that's not too helpful since the ostensible benefit of C++ is function overloading and subclassing and such, which you can't do at all between different compilers or fronts.) Hence, "It's much easier to distribute C libraries than C++ libraries." [snip rest of post that misses the point] Carl Banks
From: Ethan Furman on 3 Aug 2010 13:02
John Bokma wrote: > Michael Torrie <torriem(a)gmail.com> writes: > >> On 08/01/2010 07:09 PM, John Bokma wrote: >>>> One thing that comes to mind is that it's much easier to distribute C >>>> libraries than C++ libraries. >>> In the beginning of C++ there were programs that just converted C++ to C >>> (frontends). At least that is how the C++ compiler Acorn sold worked. >>> So I don't think your argument was much true back then. >> No, he is still right. Each C++ implementation did name mangling >> differently leading to "C" libraries that had incompatible names and >> signatures. Also each frontend could have generated incompatible >> vtables and other C++ structures. So C code generated by one C++ >> frontend could not easily call C code generated by another C++ frontend. >> So the same arguments that are made about C++ now were just as valid >> back then when C++ was merely a fancy preprocessor. > > See my other post: I understand that two C++ preprocessors can't call > each others generated code, but if one uses C++ and knows that one can > only use shared C libraries on target systems, and not C++ libraries > that might be present (or more likely not: C++ was new in those days). So if Python were written in C++, and an extension was written in C++, how could the two call each other? ~Ethan~ |