Re^3: compiling perl scripts aka why is perl not as fast as C

C is a much simpler language than Perl and much easier to learn.

Surely you must be joking.

I can teach a programming novice how to write a short program which performs IO in an hour, and he or she has a better than decent chance of remembering how things work with a notecard or two of notes.

I can probably walk the same novice through compiling and running "Hello, world!" in that time and he or she might remember how things work.

It seems to me the reason there is a much stronger ethos of unit testing in the Perl community than in the C community is that the balance between run time and compile time errors is quite different between the languages.

No, it's because it's immensely easier to write tests in Perl than in C.

My guess is that per line of code typical Perl tends to pack in more bugs than typical C, just because Perl can do a heck of a lot more work in one line than C can.

I've heard the opposite, because Perl requires far fewer lines of code than the corresponding C. The bug defect rate tends to be constant per SLOC.

Comment on Re^3: compiling perl scripts aka why is perl not as fast as C

Replies are listed 'Best First'.
Re^4: compiling perl scripts aka why is perl not as fast as C by GrandFather (Saint) on Mar 21, 2010 at 22:27 UTC
C is a much simpler language than Perl and much easier to learn. Surely you must be joking. Not at all. But remember what the C language is without its standardish libraries - some simple control structures, a handful of data types, some arithmetic operators, some bitwise operators and some boolean operators. The core language is very small. Perl's core language on the other hand is huge and contains all sorts of subtle special magic. I agree it is harder to use C than Perl, but that is not the same as learning the language. No, it's because it's immensely easier to write tests in Perl than in C. I admit I write C++ rather than C so I don't know how hard or otherwise it is to write tests in C. However, in C++ using easily available test frameworks it's not a lot different to write test code in C++ than it is in Perl. The bug defect rate tends to be constant per SLOC. That would be my first thought too. However Perl rather encourages concatenating the odd map, grep, join, split and so on together into a single succinct line - what could be written over several lines collapses to one. Therein lies the problem with SLOC and Perl exacerbates the issue by often allowing the code to be as readable in the compact single line form as in the multiple line form. True laziness is hard work	[reply]

Replies are listed 'Best First'.

Re^4: compiling perl scripts aka why is perl not as fast as C
by GrandFather (Saint) on Mar 21, 2010 at 22:27 UTC

C is a much simpler language than Perl and much easier to learn.
Surely you must be joking.

Not at all. But remember what the C language is without its standardish libraries - some simple control structures, a handful of data types, some arithmetic operators, some bitwise operators and some boolean operators. The core language is very small. Perl's core language on the other hand is huge and contains all sorts of subtle special magic. I agree it is harder to use C than Perl, but that is not the same as learning the language.

No, it's because it's immensely easier to write tests in Perl than in C.

I admit I write C++ rather than C so I don't know how hard or otherwise it is to write tests in C. However, in C++ using easily available test frameworks it's not a lot different to write test code in C++ than it is in Perl.

The bug defect rate tends to be constant per SLOC.

That would be my first thought too. However Perl rather encourages concatenating the odd map, grep, join, split and so on together into a single succinct line - what could be written over several lines collapses to one. Therein lies the problem with SLOC and Perl exacerbates the issue by often allowing the code to be as readable in the compact single line form as in the multiple line form.

True laziness is hard work

[reply]