Re: Perl vs C

Perl is written in C.

If you want to utilize pure speed of the processor, If you have enough time and knowledge on C you can very well code/achieve everything using C. In C you have to manage the memory(allocation/deallocation) mistakes there will often lead to SEGMENTATION FAULT.

If you want the speed of C, with lots of flexibility in using/manipulation of data structures, if you want pick-up and use third party modules, with lots and lots of support & help from community(perlmonks) then perl is best. Whatever is possible to be achieved using C is achieved using perl also. Perl manages memory for you, but still you got to be careful on using the created data structures/variables otherwise you will end up in using all the available memory, I have been using perl for 4 years now and I have never got a SEGFAULT :) .

I compared only the points that suddenly struck my mind, I think there are so many of them like this.
Good question.

Vivek
-- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.

Comment on Re: Perl vs C

Replies are listed 'Best First'.
Re^2: Perl vs C by halfcountplus (Hermit) on Mar 15, 2009 at 04:56 UTC
"Whatever is possible to be achieved using C is achieved using perl also. Don't be insane. This is so obviously far from the truth as to be ridiculous. Perl is beautiful but SPECIALIZED. You will (almost) never realize the execution speed of C in perl which is why people do not write (eg) 3D API bindings for perl. What is the acronym for again, anyway?	[reply]
Re^3: Perl vs C by chromatic (Archbishop) on Mar 15, 2009 at 08:36 UTC
You will (almost) never realize the execution speed of C in perl.... That depends on what you're doing. If you want to compare the languages themselves (okay, you can use C's standard library), I can suggest several algorithms and data structures and tasks which will be as fast in Perl as in C. ... which is why people do not write (eg) 3D API bindings for perl. A far larger problem is data marshalling instead of opcode dispatch. What is the acronym for again, anyway? Perl is not an acronym.	[reply]
Re^4: Perl vs C by assemble (Friar) on Mar 16, 2009 at 13:03 UTC
I can suggest several algorithms and data structures and tasks which will be as fast in Perl as in C. I keep seeing people say this, but I've never managed to see it happen. Usually Perl is fast enough, but I've never managed to outperform the equivalent C program. Could you please provide some examples of what is faster in Perl than C, because I really am interested.	[reply]
Re^5: Perl vs C by chromatic (Archbishop) on Mar 16, 2009 at 18:08 UTC
Re^6: Perl vs C by assemble (Friar) on Mar 17, 2009 at 13:21 UTC
Re^3: Perl vs C by plobsing (Friar) on Mar 15, 2009 at 16:26 UTC
people do not write (eg) 3D API bindings for perl. Oh really? Of particular interest: Due to Perl's strength in string manipulation, there are cases where Perl can even outperform C when loading/manipulating shader programs.	[reply]
Re^3: Perl vs C by ForgotPasswordAgain (Vicar) on Mar 15, 2009 at 17:53 UTC
I wrote bindings for OGRE. I found them to be fairly fast, actually, though of course most of the execution is done in C++ land. You probably don't mean Perl specifically, but interpreted languages generally. But from what I see, a lot of times there are no bindings for Perl when there are for Python and Ruby. I think the reason for not writing bindings is not the speed (Perl is probably faster than Ruby, I don't know about Python) but rather the ease of writing the bindings. For example, for Python there is Py++; we don't have the equivalent of that for Perl.	[reply]