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.
It would give and emberassing twist to the python vs. perl religious wars :)
after all, python people wrote a mailing list manager just so they wouldn't have to use majordomo written in perl.
Well, we could use python to write perl, perl to write python and have tons of fun.
There's that story about when steve jobs bought a cray machine. the sales manager called up the guy who designed cray (I forgot the name) and told him that apple bought a cray to be used for designing apple computers. The cray designer thought abit and said that it was logical - he is using an apple to design the cray.
Ballerinas have fins that you'll never find
There is a school of thought that says compilers and interpreters are systems programs and hence should be written in systems programming languages like C.
There is another school of thought that says the language being implemented is clearly the best in the world for almost all purposes, therefore its compiler/interpreter should be bootstrapped.
In general, I don't think that either of these attitudes is entirely appropriate. It strikes me that when implementing a translator for a programming language, that one would want to use a language that had:
1) Automatic lexer and parser generator tools. I suspect that the lack of these tools is not a real barrier though, since most compiler jocks know enough to rattle both off in a weekend.
2) Reasonable linguistic facilities for manipulating strings.
3) Reasonable linguistic facilities for specifying and manipulating user defined data structures -- particularly trees.
4) Some way to do information hiding and separate compilation. And perhaps other facilities for programming in the large.
5) A reasonably speedy implementation, so the translator that you're writing isn't hideously slow.
Now, does Perl have all of these attributes? Mostly. The thing that I would think you wouldn't want to do, is write a bytecode interpreter in Perl. This, you definitely want to do in C (if you're concerned with portability) or C/assembler (if performance matters more than anything else).
So, I'd expect a similar design decision was made for Topaz. In interpreters you have to deal with data structures that represent scalars, arrays, dictionaries, etc., so an OO approach might let you avoid hard-wiring an expected type, in favor of an expected interface. Whether this will pay off significantly is the purpose of the experiment.
"Jou don't get that from himplementing Perl in Java."
Sure you do, the interpreter is a Java program. The java program gets optimized so the perl implementation benefits from the optimizations. Of course you would never get the same speed as with compiled perl (since we are talking about an interpreter), you are right about that. But also a Perl JIT compiler could be written in Java, especially if it is supposed to compile to Java bytecode but other code should be no problem either.
But as I said in my original post, I don't belief Java is fast enough at this moment to meet the performance requirements for PERL (i.e. be as fast as modc, or whatever its called, for apache).
Jilles
> You are forgetting that class==private struct!
Well, no I wasn't, I was just using a contrived example. The point is that the reason it looks like C++ is doing something weird is because it just provides language definition capabilities needed to make first class types. I get your point though.
>Instead of using recursion, they wrote an
>iterative function with handcoded
> stack. They made the stack dynamic, extending
> their sizes using malloc() and free()!
Ha! To bad you can't tweak them about it without getting a bad grade.
Actually, call/return overhead is the least of your worries when you're calling malloc and free. On many systems, these are the slowest OS calls there are that don't do IO.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Chip listed a couple other contenders (ObjC, Eiffel, Ada) but decided not to choose them because of various issues ranging from implementation to the availability of compilers on many platforms. In the end he says:
"So, we're left with C++. It's rather like the comment that I believe Winston Churchill is reported to have said about democracy: It's absolutely the worst system except for all the others. So, C++ is the worst language we could have chosen, except for all the others. "
--mere mortal--
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!
(
Sather is an interesting language, but the resultant portable C code is, according to the testimonials on the Sather pages themselves, only as fast as the equivalent code written in C++.
;-)
Object Orientation is a relatively new paradigm, and work is still being done in making OO code run faster - in general. It is the OO heirarchy that slows down C++ compared to C, it is what helps make Java slower even though the JVM is a relatively efficient interpreter/VM, and it is what "crippled" languages like Smalltalk and Eiffel in the eyes of "real" developers. However, the ease of design and maintainability of OO code has inspired a lot of research into trying to speed up OO languages so they can compete with their functional counterparts.
The advantage of Sather isn't speed (not yet, maybe someday), but, according to the authors, ease of maintainability. This, however, might be a reason to make the choice to use this language. As C++ is fairly broken in some places due to the ad-hoc OO/C integration, it can be very quirky to work with, and it's easy to write bad C++. I'd need to study Sather in detail to say it is actually more elegant and maintainable than C++, but I rarely doubt claims that something is more elegant than C++
Unfortunately, though, to port the Perl source to Sather one would first need to port the Sather compiler to Windows, as Berkely hasn't bothered doing so... and the Perl6 team will obviously need to support Perl on Windows as that's been in the core Perl for a bit of time now...
Creating a formal language base to bootstrap a framework into C through LISP is a great idea... but according to Larry Wall, PERL can not be formally specified in such a manner, and therefore I believe that this tactic would not work in this case, though I have not really studied the possibility in any great detail.
The suggestion of rewriting Perl in Python is a bit silly... why not rewrite Perl in Scheme, TCL or Java... or Perl? Talk about speed not being an advantage... While Python is pretty fast, Java with a good compiler (such as Jikes) and a good JVM (such as Java2 with HotSpot) is faster, at least on our tests on WindowsNT and Linux.
If raw speed at the expense of maintainability (and therefore the possibility of speed lost to bad programming rather than a "bad language") is one's goal, C is still the language to use (or assembler if you're both wed to one chipset and a total maniac). Otherwise, there are a lot of choices, including C++.
I think C++ was chosen because porting from C to C++ isn't that difficult to do (at least to do very badly), and can be done incrementally. I think the efficiency of Perl in C vs C++ will depend entirely on the programmers and how they use the language. As one person already pointed out, if they use C++ for some added maintainability but with an eye towards speed (that is, use the parts that don't slow the program to a crawl), they'll do just fine on the speed front...
o/~ we are pissed, we are pissed, we have to resist... o/~ - ec8or
"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've seen a number of other projects (albeit not opensource) that have been re-written in C++. All have been a disaster. The memory footprint is always larger, and the speed of execution is noticably slower. Plus there is the learning curve involved with C++ for the developers involved in the previous project.
:-)
One application I had a lot of dealings with was re-written in such a way, and was so buggy that users reverted to the previous version, or went elsewhere. It even caused a number of NT migrations. Unfortunatly the C++ version was the only one that was Year 2000 compatable. I even spoke to the head of support at the UK end of the company - he did not admit there were any problems, probably to save his job. The product sucked more than a VAX (thats the UK vacuum cleaner, not a DEC machine!).
Another thing - have you seen how much memory gcc uses when compiling C++? With the sudden rise in memory prices I may not be able to compile perl6, as I won't be able to afford the extra gigabyte of RAM required!
Please, please, please don't do it.
ANSI C++ is a fine idea. Unfortunately the compilers haven't caught up with the ANSI standard yet. Some of them will never be ANSI compliant due to lack of vendor interest.
Mea navis aericumbens anguillis abundat
Having written in both, I can tell you that I am able to actually write faster code in C++ than in C, not to mention that I make MUCH fewer stupid mistakes because of better type
checking etc.
Remember that C++ is a semantic extension to C. So whatever C can do, C++ can do it too. There are two possible places where C++ can beat C: 1) inline functions and 2) using const reference parameter. The first can be solved using macros or compiler-specific inlines.
Based on my experience, the reason why some people find C is bigger than C++ is because the C code is written in a 'neat and tidy' fashion. C will punish you for this. If you want to write elegant code and want the compiler to figure out how to generate this efficiently, sometimes it is better to use C++. This phenomenon is similar to the case when assembly coders start to heavily use macros to make their code look neat and tidy, and later found out that it is much bigger than a C equivalent. C will look through the macros, and do proper register allocation and topologically sort the expressions for you.
You can use C++ as efficiently as C if you don't use the extensions. When you do, it MAY start to kill you. At best, it will simplify code writing and maintainence for something you can manually code in C anyway. Case in point, GTK. At worst, you end up with code bloat because compilers are either immature or there are semantic constraints that prevents it from doing further optimization, which can easily done by human inspection.
Kernighan/Ritchie designed C based on what they can generate in assembly. Stroustroup designed C++ based on what he can generate in C. There is going to be some efficiency in C++. So you have to ask yourself what is more important, ease of coding and maintenence (C++), or efficient and deterministic code (C)?
Hasdi
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.
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.
I have to agree with you on this one. C++ is probably the fastest OOPL around. You can code OO is C but it gets ugly. Stroustroup wants the code to be as elegant as other OOPL but can be as fast as C. That's why you have virtual, inline, const, and static keyword cluttering the class declaration.
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.
You are forgetting that class==private struct! At this point, a lot of compilers optimize ints and floats using automatic register allocation. Struct and array is usually implemented as a pointer to a memory on the current stack frame (Although since struct is well-bounded, there are optimization opportunity not in arrays). A C/C++ does not *care* how many temporary ints and floats you have, it will weed them out! struct/class temporaries always are spilled! You don't believe me, encapsulate your ints into a 'class Integer' and floats into 'class Float' and overload operators accordingly. Compile -O3 an arithmetic intensive functions one using pure ints and floats and the other substitute with 'class Integer' and 'class Float'. get code size using a dump utility. QED.
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.
I know what you mean. That's what they say at Ann Arbor too. Some professors are either misinformed or either doing a poor lip-service to real gurus. Instead of using recursion, they wrote an iterative function with handcoded stack. They made the stack dynamic, extending their sizes using malloc() and free()!
So what is wrong with the picture? The iterative function is poorly written. 99% of the time, the reason why recursive function is slower is because of the call/ret overhead and function header/tail overhead. If you replace this with a cmp/jmp, you will get much better performance, hence the endorsement for iterative functions. If you start using malloc() and free(), you are making the problem worse!
If you want to optimize something, don't look at the C code. Look at how the code is being generated. A smart compiler can automagically convert a recursive function into an iterative one, if it is tail recursive.
Enough ranting for one day. Back to work.
Hasdi
We run Perl5 in development but have been working very diligently to get it approved for prod, which currently uses v4. In my travels writing Perl code for Fortune 500 companies, this is a much more serious impediment to acceptance than the majority of Perl users realize. My largest clients are commercial banks and brokerage houses, and you constantly find machines at these places running versions like 5.002 or earlier.
The normal reaction from a Perl user at an ISP or an academic institution is that the people running that system must be really dumb or must not use Perl. This is not the case.
Many consultants like me and the software development staffs we work with are not the people that decide which development tools are used. These decisions are made by people at the Chief Technology Officer level at many companies. They tend to spend most of their time evaluating Closed Source Software because this is the software that is promoted through the corporate IT news, sales, and marketing channels.
OTOH, software that is actually used, like Perl, is considered an ancillary part of the UNIX OS build that is installed on each Sun, HP, or IBM server. The geeks in the back room often have to resort to civil disobedience in order to get a new version of Perl approved and installed.
Sorry if this seems slightly off-topic. To tie it back to the discussion about Perl 6 I would have to say, with all the new features we would like to add, we in the community need to re-double our efforts at advocacy. We need to do a better job of identifying places where obsolete Perl versions are still installed, and figure out ways to remedy the situation.
-- Dave Aiello
My point was not to detail the "splintering" but to indicate that it took place, and represents cause for the lack of stability of C++ on Linux.
I certainly agree that the now-much-better implementation results from the EGCS efforts.
If you're not part of the solution, you're part of the precipitate.
Kill paranthesized section and subsequent comma, and you get a little closer to my point. I wasn't attempting to take a historical look at OOP in general, just it's recent widespread popularity (with regards to C++ vs. C).
One might even say less useful. Java hurts my mind, yet C++ doesn't, so the term "unwieldly" is merely an opinion (well, it could be considered a documented fact in the case of certain languages.. but certainly not among the languages of choice), which is why I said "some" people might find it to be so.
Besides, C++ isn't so much a procedural/OOP hybrid as that it allows you to use C within C++ (though if you do, you are clearly missing the point of using C++ in the first place.. unless you have a real good reason for doing such a thing). Yes, Java lets you "play it safe" (and I won't even go into Objectionable C), but it sacrifices a bit of power and versatility. I'll take the power and versatility, thanks.
An excellent point, though I don't see how this debunks the notion that encapsulation, and subsequent ease of code maintenance, is not a primary factor is the widespread acceptance of OOP and/or C++.
~ Kish
Firstly, you can ignore the problem if you allow only the exact same executable to re-open the memory map. In that case, the vtable pointers that are in that persistent file should be valid, because the vtables have fixed virtual addresses in static storage. All you have to ensure is that the mapping of the region is to the same address so that pointers to within that storage also remain valid. Of course, this will not work if you change an recompile the program, because the vtables might then shuffle around.
Secondly, you can still hack outside of the C++ language to mess with objects' vtable pointers. It should be possible to wrap up this ugliness in a module that can be adapted for various compilers.
Ok, a lot of people seem to really hate C++. I think part of this is because Linus rejected for the kernel. This makes sense, though. The kernel is very low-level and you want as much control as possible. C++ is a bigger language, and it does more stuff behind your back. C is very predictable, and thats why C is such a good systems language.
But for a big, non-nuts and bolts project like perl, C++ has a few important advantages.
1. OO. I think this is obvious. Of course you can do OO in C, and C++ doesn't garentee a good object model, etc. But it is less work, "cleaner", and requires fewer dodgey practices like macros to make things work. Additionally, there is far more tool support for doing OO in C++ as opposed to C.
2. Templates/generic programming. Now that there is a cross-platform compiler that does these relatively painlessly (ecgs/gcc3), Open Source C++ programmers should have no qualms about exploiting this feature, as they have in the past. What do templates give you that macros and typecasts don't? Well, first of all, type safe containers. That means you can't add a string to a list of ints. It won't even compile. Compare this to the best C containers, which can only catch it at run-time (with a performance hit). If type safe containers aren't enough, the C++ standard template library gives you iterators. To make a long story short, iterators allow you to write container independant algorithms. Your sort routine will run on a tree, a hash, a list, a vector, etc. Try doing that in C without enough casts and macros to sterilize a rat. And of course, the STL comes with nice implementations of most of the well-known algorithms you are likely to need.
3. Exceptions. Exceptions are simply a more elegant way to program, as any Java programmer will tell you. It nicely solves the ever-recurring problem, "How do I return both an error code and a result?". No more if (foo() == -1) return -1; everywhere and wondering if returning TRUE means success or failure.
In summary, C++ isn't for everyone or every project. But it has some nice features that make it nice for large projects.
>> Nononono, everyone knows that it stands for Pathologically Eclectic Rubbish Lister :-)
> Just be careful which circles you swim in when you say things like that. I'm sure a lot of zealots would refer to such a thing as blasphemy.
Er... Direct quote:
"To those who merely like it, Perl is the Practical Extraction and Report Language. To those who love it, Perl is the Pathologically Eclectic Rubbish Lister".
Camel book, p. xi
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
Then you would break things like:
$onetwo = $one.$two;
and:
$blah = $one.scalar($two);
This becomes less of a benign "feature request" and more of a fundamental change in one of Perl's more frequently used operators.
Granted, you could make the distinction by looking for whitespace near the . (e.g. $blah = $one . scalar($two);), but you would still end up breaking a significant number of scripts. Plus it's less obvious when you see $one->{$two} versus $one.$two versus $one . $two. Also, how do you distinguish between $one->{'item'} and $one->item (a method)? Use paranthesis? Things get complicated.
Great. So now development of Perl is driven by least-common-denominator capabilities just so they can say "It works on Windows!" I thought the whole thing behind open source projects like this was that decisions could be made on technical merit rather than what some marketroid decided the software needed to be able to do. Or is that turning out to be just a myth?
Chip could have at least phrased that statement a little different to say something like, "We just want to make sure it works with Visual C++ so we can support Windows" rather than the "We're basing it on Visual C++ because we think supporting Windows is much more important than using a compiler where bugs really get fixed on a stable platform the developers really use" implications of the way he stated it.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
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.
Might I inquire what would give one such an impression? C is covered by ANSI standards, and so is C++ (not to mention, yay! ISO!), which means just about any compiler worth anything can compile perfectly ANSI compliant C or C++ code. Both are just about the epitome of portability (unless you count Java.. but you know, I don't feel like it), which aside from their being quite powerful languages, is what makes them languages of choice. C being a subset of C++, etc.. I'm not sure what would cause one to think of C++ as "less stable". Perhaps I'm not understanding the question? After all, it is rather early..
And since C++ is object oriented, it's a lot more.. useful.. in most situations than C. C still has its uses where C++ would be considered blatant overkill, but for anything that's going to be complex enough and is going to need to evolve a lot, C++ is the better alternative.
~ Kish
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.
Why doesn't someone bootstrap a perl compiler written in perl? This is usually the way it is done?
- 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.
Here are some good reasons why they might be considering using C++.
1. Perl is already written in C. C++ gives you an easier migration path from C than other languages. You can gradually move the program component by component. The C++ parts can freely call the C parts and everything is linked into a homogeneous whole.
2. Speed. Perl is a interpreter for a programming language. Moreover, it is widely used in practical applications. So it deserves to be written in a systems programming language that is statically typed and translates to reasonably efficient machine code.
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
If you use features such as polymorphism or RTTI, of course you get a performance hit, but if you try to implement the same things in C manually, you won't get any better results.
Slowness of the program comes from sloppy programming, it has nothing to do with the language.
My C++ is admittedly rusty, (I moved on to Java three years ago), but I don't recall any performance issues. I do remember being completely screwed by over-enthusiastic use of operator overloading, virtual base classes, fancy conversions, and especially templates, but not performance issues.
You say that it's the C++ glitz that makes the language slow. Exactly what features are you referring to, and what sort of performance penalty is incurred?
If I had to write C or C++ again, I would definitely want to use C++ (performance permitting), but I would be much more selective about the features I used.
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.
I've ported perl to a new OS and I've written my own modules, so I feel I have a relatively valid viewpoint on perl's internals.
Basically, the internal datastructures are hoary. They're awful to dig through, and even worse to try and modify. Even writing external modules for use in perl can be horribly nasty because of the structures involved, the reference counting, etc.
I'd say at this point there are about 10-20 people (at most) who are competent to go and change the guts of perl. That's not a large number, especially when they don't have all that many tuits.
One of the prime motivations of rewriting perl in C++ is so that things will be modularized so that the knowledge barrier is greatly reduced. Right now, you need to know how _everything_ works before you can modify _anything_.
I'll be quite glad to get rid of things like
return sv_2mortal(newSVpv(ret,len));, thank you very much.
How about, say, Sather? A clean, fast, free (libre and gratis), object-oriented, garbage-collected language, which (and this is the beauty) compiles into portable C, so you can bootstrap Perl without first bootstrapping Sather. You only need Sather if you want to tweak Perl.
If that's too much effort, then you've basically already made the decision that only C or C++ will do since that's the compiler that machines will already have, so there's not much point in talking about other languages you might have used were it not for that condition. But I think it would be a mistake for free software projects to mandate that only these languages will do - it's not a restriction that proprietary, binary-only releases labour under.
--
Xenu loves you!
Then you should check out the HTML::Mason module running under mod_perl. Even though I'm a hard-core Perl advocate, I was a big fan of PHP for web development (until I found Mason).
Very cool stuff...
--
--
A PC without windows is like chocolate cake with no mustard.