Slashdot Mirror
Perl6 Being Rewritten in C++
jamiemccarthy writes "A rewrite of Perl in C++ is underway. The audacious plan, now called Topaz, will become Perl6 if and when it's successful. Its author, Chip Salzenberg, will
tell you all about it. " Wow. That's quite a project - you can also listen to Chip's talk given at the OpenSource Convention. For those you unaware, Chip is one of the Perl core developers.
And they're off! We already have some vague allusions to C++ being a bad idea, and the cross platform card has been played mighty early, implying that C is better than C++ for that. This is an exciting match, ladies and gentlemen, and we'll keep you updated as the race continues. We have yet to see any real material claims, be we expect plenty of personal anecdotes and opinions this match. It promises to be an exciting time, so stay tuned!
(
"Macros are the reason to dump C for C++? "
Macros are evil. Each time you use a macro you are working around a language limitation. C++ has more language constructs than C so you can avoid macros more often. The nice thing about C++ is that the use of those language constructs is optional. I.e. if the use of a certain language construct in a certain spot of your program has a serious performance impact on your program the solution is simple: don't use it.
"Overall this will end up one of two ways: 1) it will fail because C++ is too slow or 2) it will succede because he uses C++ only for what advantages the syntax can provide him without being trapped into the glitzy (and mostly useless) constructs that make C++ about as speedy as my grandmother on a cold winter day."
I would go for number 2 and would like to add the prediction that if this thing is designed in a proper way, performance might actually be better than the old C version.
One of the arguments for reimplementing was that the current version is so complex that there are only a handfull of programmers who have enough knowledge to make non trivial changes to the code. A nicely designed C++ version of Perl could change this. An example of an increasingly successfull C++ implementation is Mozilla. It is fast, well designed and progressing really fast.
This discussion seems to be drifting in the "you can do anything in C" direction. While this is certainly true, it does not mean that C is the best solution for everything. Most perl users at least wouldn't dream of using C for the stuff they normally use perl for. Why?? perl is a better solution for their problem.
Likewise, C++ is a good language for large, complicated software. It's OO features allow for better structuring of the programs, and its C inheritance allows for performance optimizations should they be needed.
"Along those lines: I heard a good joke recently. A JIT compiler for Java that claimed to run code "just as fast as C++"! I laughed for minutes. Then I cried when I realized that this will likely work as an add campaign. Sigh."
You'll be crying a lot in the coming few years. Probably Java is not a good solution for implementing perl right now. But I wouldn't be surprised if it becomes an option in a few years. Perl is used mainly for server side processing of scripts. Good performance is essential there. Java has been coming quite nicely in this area and can be expected to improve even further the coming few years.
from the article: "I finally realized that Perl may be competing with Java in the problem space, but when you're writing Perl, implementing the Perl runtime, really what you're doing is something equivalent to writing a JVM. You're writing the equivalent of a Java Virtual Machine. Now, would you write a JVM in Eiffel? I don't think so. No, so neither would you write the Perl runtime in Java or in Eiffel"
While this may be true, implementing Perl in Java would mean that pearl benefits from all the optimizations in the Java vm (that would otherwise have to be implemented in the C++ version of perl). It would also mean that Perl would benefit from the portability of Java. One major advantage of a Java implementation would be that it would be far easier to maintain than a C or C++ implementation.
Jilles
I don't know where this idea that C++ generates slow exectuables came from. Bad programming create slow executables.
Early OO systems did a lot of runtime message passing, so they _were_ slow. C++, on the other hand implements a lot of the OO paradigm at compile time for more speed.
Virtual function DO add a table lookup each time they're called, but this would only have any effect during a tight loop. And you don't have to use them if you don't want them, but they do provide the benefit f reducing the need for type unsafe downcasting.
The other argument I've seen about C++ has to do with it somehow not being as "close to bare metal" as C. This impression comes from the fact that C++ does a lot of weird things like construct temporary objects to fit an object into an expression where it otherwise can't be used. Of course C does this too; if f takes a float and i is an int, then in the expression "f(i)", C constructs a float out of i for you. The difference is that C++ allows you to create bonafide first class types.
If you don't want temporary objects constructed, code around this problem. After all, in C++ you can always define both f(int) and f(float), but in the end it won't make any difference because most of the time you'll be doing the equivalent conversion in the function anyhow.
A lot of the hot opinion about C++ "inefficiency" reminds me of all my CS professors who used to say as an article of faith that "recursion is inefficient", and then go on to code elaborate ugly iterative algorithms to get around this. Well, one day I went home and ran a few algorithms through the profiler, and guess what? Most of the time there was no difference, and some of the time the recursive algorithm was a tad faster.
You can't trust your intuition about what is fast and what is slow. So, profile your code. If a virtual function or constructor for a temporary is taking a lot of time in a tight loop somewhere, optimize just that one piece by coding around the problem. Usually performance problems tend to be in a very tiny fraction of code.
I think that a lot of bad C++ comes from the fact that some programmers can't effectively use the extra flexibility that the language provides. They say if all you have is a hammer, every problem looks like a nail. If you have a hammer and a screwdriver, you're not in any better position unless you can tell the difference between a nail and a screw.
In the end, I personally prefer C, because I find it small and elegant. Look at how thin K&R is! C++, because it exposes so much language definition machinery to the programmer, will never be as elegant, but it is nonetheless in most respects very well thought out.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
After reading the article and the posts, I feel compelled to share my thoughts and experiences with both languages.
I've been a software engineer for 13 years. My first exposure to C came during a junior year course, Survey of Programming Languages, at ULowell, now UMass/Lowell. Once exposed, there was no going back. I was hooked. IMHO, it was so much better than Pascal. Once exposed, my Turbo Pascal went back to the bookshelf, never to be used again.
My initial exposure to C++ came during my senior year. I was enrolled in a compiler design course and the professor was a Modula-2 fanatic. Since half of the class were budding C gurus, he relented and allowed us to use "this new language", C++. We shelled out the $$$; he went to the Harvard Coop to buy copies Stroustrup's book.
I was impressed by the differences between C and C++. I particularly liked the organizational improvements that class definitions had over struct definitions. I found it a joy to code.
The project for the course was to build a Pascal-subset compiler. We couldn't use global variables and all functions, except for the tokenizer, had to fit on one page of hard copy printout. At the end of the course, he ran informal benchmarks for our compilers in terms of output size and compilation speed. My C++ compiler was the fastest and 3rd in efficiency!
Fast forward to the real world. After working for Omtool and Phoenix Technologies coding C and x86 assembler respectively, I worked as chief software engineer at Image Concepts. As chief software engineer, I was to design and develop their image cataloguing database product. To do so, I had the freedom to pick and choose the development tools and platforms for development. Since our product was slated to run on Unix/X11, Mac System 7 and Win3.x systems, I chose C. Again, portability, and the fact that Unix shipped with free compilers and Image Concepts was a very small company...
Once I started working at Pegasystems, after 6 years at Image Concepts, C++ became the language of choice, both for day job and night coding. Why? Code organization. Even though I wrote my C code in a C++ style, first argument to functions written for a particular struct was a pointer to a variable of that struct, C++'s constructors, destructors and exceptions made error management much, much better.
Typical C function (pseudo-code):
open file
if error: return
alloc memory
if null: close file and return
read from database
if error: free memory, close file and return
do something else
if error: yada, yada, yada...
C++:
open file object
if error: return
init buffer object
if error: return (file object destructor closes file)
read using database object:
if error: return (buffer object frees memory, file closed)
-or-
throw exception on error, which will also call destructors
You get the idea. When using C, I spent more time writing error management code than writing the algorithm. Worse, the algorithm was hidden amongst the error checking and management code. In C++, I build my libraries of well-designed classes and exceptions and, wow, you can actually see the logic. What a concept!
C++ isn't perfect, particularly some implementations. However, now that the language has been standardized, it should become more portable.
Languages are tools. We use them to design apps. We use the compilers to build the apps. Some are better than others in some areas. Each has a place. I use C++ for systems programming. I use Perl for CGI programming. For pattern parsing and portable scripting, Perl gets the nod. For outright speed, C++ gets the nod.
Is C better than C++? Vice versa? Is Java better? Is C++ purely OO? Does it really matter? Just pick a language, write the app, and distribute your work and add some value to the computing community at large. 'Nuff said.
One caveat to note regarding C++: templates and shared libraries are a bitch to implement well, that is, if you don't want multiple copies of stack scattered throughout your libraries. Both Visual C++ and Metrowerks CodeWarrior had ways of working around this, to have stack in one library and have other libraries link back to the first one, but the syntax each used were extensions off of standard C++. I don't how G++ will handle this.
Well, so what the article says is basically this: "over long time we have done a shitload of
adhoc programming without order or system. Now
we look at it and we are scared. So we will just
drop everything we'v done and rewrite this whole
thing in some other language. We hope that objective nature of C++ will solve the problems
we as programmers cannot resolve (such as writing
a good structural code)."
Well, it won't... It will be slow as hell, Perl
not being a jetrocket now will be worse then your
java in Netscape on a 486:) And if they can't
keep their code neat - no OO language is going
to save them...
Sad..very sad.. they are smart people but that
doesn't necessarily gives discipline.
From the article:
Why not use C? Certainly C does have a lot to recommend it. The necessity of using all those weird macros for namespace manipulation, which I'd rather just use the namespace operator for, and the proliferation of macros are all disadvantages. Stroustrup makes the persuasive argument that every time you can eliminate a macro and replace it with an inline function or a const declaration or something or that sort, you are benefiting yourself because the preprocessor is so uncontrolled and all of the information from it is lost when you get to the debugger. So I'd prefer to use C++ for that reason.
Macros are the reason to dump C for C++? Woah, I got off of perl5-porters way too soon. Not to start a language war or anything, but this article read like a C++ lovers manifesto, not a reasonable set of excuses to use the language to re-impliment one of the most powerful and stable interpreted languages ever.
If you want a clean object model, just look at GTk+. If you want to eliminate macros just use inlines. Most people have a hard time with the idea of building inlines in header-files, and I don't blame them, but that's how you're going to end up doing it in C++.... And, don't try that "inline isn't in most C compilers" because most OSes don't ship with a C++ compiler. If you say that you can just buy one or get GCC, then the one you buy will almost certainly also be a C compiler that handles inline, and gcc supports inline (or __inline__ if you have -ansi turned on).
OTOH, macros are a good thing. Yep, I said what you thought I said. When a macro performs only a simple syntactic transformation, that's fine. I've never once been caught by such a thing. When a macro is a few lines of code, you've failed to correctly design your program, and I've lived in debugger-hell for that one. I can certainly see the value of consts over macros for variables, but that's not even something that's hard in C.
Overall this will end up one of two ways: 1) it will fail because C++ is too slow or 2) it will succede because he uses C++ only for what advantages the syntax can provide him without being trapped into the glitzy (and mostly useless) constructs that make C++ about as speedy as my grandmother on a cold winter day.
Along those lines: I heard a good joke recently. A JIT compiler for Java that claimed to run code "just as fast as C++"! I laughed for minutes. Then I cried when I realized that this will likely work as an add campaign. Sigh.
- There not being a normative standard.
- There not being a good free compiler.
- Interoperability of LIBC++ versions has not been real good.
What this adds up to is that C++ on Linux has had some fairly severe handicaps. Several are no longer in effect; we'll see if this allows C++ to "get up and walk."That became untrue a year or so ago, when the ANSI C++ committee released the "final" standard.
G++ only fairly recently has started to be both "reliable," "correct," and "nearly completely conformant to standard."
The gyrations between GCC and EGCS, which has recently become GCC, did not help.
The claim is that there shouldn't need to be Yet Another Noninteroperable Version of the GCC libc++ library; I'm inclined to wait six months and see...
(My personal suspicion is that there may continue to be some LIBC++ gyrations for a while...)
If you're not part of the solution, you're part of the precipitate.
I believe difficulty in code maintenance with languages such as C was one of the primary reasons for the spawning of object oriented programming languages (complex and sometimes unwieldly though they may be to many), such as C++.
~ Kish
Something that's been rumbling in my head for a little while. Where do we draw the line between real C++ and pseudo-C++?
:)
For instance, if I write something using MFC (CMapStringToPtr or the less disgusing CMap template) then, well, it isn't real C++ is it? I won't be able to compile it anywhere else. I'll be stuck with that god awful library.
So you start using STL, beacause it's ANSI'd and open and designed by adults who knew what they are doing. You go looking for (and find) a convenient map template and in the process notice templates for near as dammit everything else! Strings, memory allocation, streams, the whole enchelada.
So, to be *real* C++, should I only be using the stl library, doing #include "string" and only stretching as far as #include "cstdio" when I feel a nasty hack urge coming on? Can I say goodbye to the happy days of getting a char* to the first byte and bouncing along the string until it dereferences to zero? Do I, in short, have to clean my act up?
And to what extent do other major C++ projects do this, especially given the relative newness (in terms of C++ standardisation) of the STL?
Dave
(offtopic note) MFC is horrible. Immense kudos to the ATL team for a fine piece of work.
I know they should be angle brackets, couldn't remember the HTML to make the browser not think they were tags. At least I previewed.
I write a blog now, you should be afraid.