lines of code in perl vs. c 
Author Message
 lines of code in perl vs. c

Does anyone have a guess about the correlation between lines of code in
c and perl?  ie, If we are trying to normalize the "productivity" of
coding in perl, what would be a good constant to multiply the number of
lines of perl by?

Please, no discussions about meaningful productivity metrics.
--


(214)518-5050           | present.  Please forward mail through the
                        | above address.  Sorry for the inconvenience.



Tue, 22 Mar 1994 22:27:12 GMT  
 lines of code in perl vs. c
Perl is more concise than C in its built-in support for strings,
dynamically-sized lists, and pattern-matching.  A good set of canned
routines for C or C++ will negate much of this advantage.

Other than that, Perl is quite similar to C.  A quicksort or an
8-queens solver is about the same size in Perl and C.
--



Wed, 23 Mar 1994 04:10:18 GMT  
 lines of code in perl vs. c

Mark> Does anyone have a guess about the correlation between lines of code in
Mark> c and perl?

My experience is that a perl program offerring almost the same
features as a C program has about 10 to 20 percent amount of lines
that the C program has. The lines saved are invariably the ones that
caused the most problems in debugging time, namely the mainteinance
and manipulation of data structures.

Khun Yee
--

              Department of Computer Science, Middlesex College
     The University of Western Ontario, London, Ontario, N6A 5B7  CANADA



Wed, 23 Mar 1994 01:00:21 GMT  
 lines of code in perl vs. c


|
| Mark> Does anyone have a guess about the correlation between lines of code in
| Mark> c and perl?
|
| My experience is that a perl program offerring almost the same
| features as a C program has about 10 to 20 percent amount of lines
| that the C program has. The lines saved are invariably the ones that
| caused the most problems in debugging time, namely the mainteinance
| and manipulation of data structures.

I'll second that.  I haven't written a line of C to do sysadm work in
nearly two years, but I've written dozens of many-lined Perl programs,
and thousands of throw-away one-liners (including JAPH's :-).

The place where Perl saves me the most time is that I can nearly
always use the same sequence of characters (the Perl script) on all
five architectures that I deal with every day at iWarp.  But even with
just one machine, I'd still use Perl for most of these tasks, because
Perl is well qualified to do text sloshing and syscall making from a
simple language.  (Well, simple for me. :-) Subprocess management is a
bit hairy, but it's hairy at the syscall level anyway, and Perl can't
really hide that.

I'd qualify it in one area though: if you are dealing with heavy
structures because you are interfacing to Someone Else's Code (like
the OS, or some database), you should be well along in your
understanding of Perl and C before attempting such a feat.

print "Just another Perl hacker,", "writing one more throw-away JAPH" && ""
--
/=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\
| on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III      |

\=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/



Wed, 23 Mar 1994 02:22:13 GMT  
 lines of code in perl vs. c
What is everyone comparing perl to C for?  The real answer was provided
by my boss, who I finally got to look over the Camel book (thanks, Larry,
for your help!) and then told me:

"You know, perl kind of appeals to me.  Reminds me of fortran."

Ilana

--
Someday, perhaps, it will be considered a normal weekend's entertainment
to, say, suit up in Kevlar and go rocketing off a mile-long Teflon-coated
downspout, describing a perfect 200-foot Day-Glo arc before landing,
presumably without permanent injury, in a sea of Styrofoam peanuts.



Fri, 25 Mar 1994 23:57:14 GMT  
 lines of code in perl vs. c

Quote:

> "You know, perl kind of appeals to me.  Reminds me of FORTRAN."

Here all along I thought it reminded me of TECO.  (ITS TECO,
not DEC TECO.  The one the original Emacs was written in).


Sat, 26 Mar 1994 11:16:21 GMT  
 lines of code in perl vs. c

Quote:

> Perl is more concise than C in its built-in support for strings,
> dynamically-sized lists, and pattern-matching.  A good set of canned
> routines for C or C++ will negate much of this advantage.

> Other than that, Perl is quite similar to C.  A quicksort or an
> 8-queens solver is about the same size in Perl and C.

I agree.  And I think that you answer the original question quite
concisely.  Now if you'll indulge me, I'll digress.

For me, the aspect of perl that makes it a productivity tool that
neither C, nor C++, can contend with, is its interpretive nature.
You can experiment with it without the delay of a recompile.

I know, I know.  There are plenty of other interpretive languages
to choose from.  In fact, most versions of BASIC for MesSDOS include
all the fancy system interaction functions that perl provides for
UNIX.  But that is the key.  Perl is for UNIX boxes.  I have never
seen another universally-available interpretive language that has
all the system functions built into it.

For non "system" code, Saber-C or some other interpretive C environment
would place a close second to development in perl.  And I would
never advocate perl for programming in the large.  Too many
hidden features in each of the built-ins.

BUT, ...  for {*filter*} system whacking, perl is the right one
baby, uh-huh.

randall.
--
   Randall S. Krebs     | Get one for your family and one as a gift.  Nothing

   Evans & Sutherland   | siren radio lantern for practicality and performance.
   Salt Lake City, Utah |               - a real ad in Parade Magazine
    Disclaimer:  E&S doesn't agree with me.  Why should you?



Sun, 27 Mar 1994 00:58:50 GMT  
 lines of code in perl vs. c


   I'd qualify it in one area though: if you are dealing with heavy
   structures because you are interfacing to Someone Else's Code (like
   the OS, or some database), you should be well along in your
   understanding of Perl and C before attempting such a feat.

  Even this isn't too complicated, once you understand the arguments to
pack/unpack properly. Where perl really has problems is when you need more than
one level of array. There a plenty of ways to kludge around this, but until
Larry adds a garbage collector, you'll still have to do almost as much work in
perl as you would in C.

  One idea I've been thinking about is some sort of structure compiler
which would turn a description of the structure of a file into perl code
to read and write records. I find that a lot of the stuff I use to read
binary files can be cobbled together from boilerplate ["You can't make shoes
from boilerplate, they'd be too heavy to walk in!"  - "Thank you, Bernard."] -
adding this boilerplate to c-to-perl shouldn't be *too* hard.

Simon



Mon, 28 Mar 1994 00:35:06 GMT  
 lines of code in perl vs. c

Simon> One idea I've been thinking about is some sort of structure
Simon> compiler which would turn a description of the structure of a
Simon> file into perl code to read and write records. I find that a
Simon> lot of the stuff I use to read binary files can be cobbled
Simon> together from boilerplate ["You can't make shoes from
Simon> boilerplate, they'd be too heavy to walk in!"  - "Thank you,
Simon> Bernard."] - adding this boilerplate to c-to-perl shouldn't be
Simon> *too* hard.

I have been thinking, how about using the same idea for data
structures as in the functional language Miranda? In that language,
recursive structures are declared and no pointers are involved for the
programmers. They are also easy to handle.

Khun Yee
--

              Department of Computer Science, Middlesex College
     The University of Western Ontario, London, Ontario, N6A 5B7  CANADA



Mon, 28 Mar 1994 04:44:13 GMT  
 lines of code in perl vs. c

Quote:

>For me, the aspect of perl that makes it a productivity tool that
>neither C, nor C++, can contend with, is its interpretive nature.

I agree.  Interpreters are superior for ill-specified and frequently
changing tasks.  Many system administration and report generation
tasks fall under these categories.

The importance of an interpreter is not that the program is
interpreted (=slow), but that the source is the program.  There is no
opaque intermediate code that hides the program from you.

This means the program is easy to examine and easy to change.  Would
that all programs were that way.  In a world of inadequate and
inaccurate documentation, the program is its own best specification.

Now, indulge my digression.

A good Perl program seems to me harder to read than a good C program.
I think the problem is noise characters like "$" and "&".  The average
Perl program is dominated by them.  Most Perl programs would be just
as readable, maybe more so, without them.  They're more heavily inked
than lowercase letters so they tend to draw your eye, unlike
punctuation.  You'd think you could train yourself to ignore them, but
there are rare places where they're crucial to the meaning of the
program.  This may be one reason people confuse <FH> and <$FH>.  The
"$" is so ubiquitous it doesn't seem to have meaning.
--



Mon, 28 Mar 1994 12:24:31 GMT  
 lines of code in perl vs. c
| A good Perl program seems to me harder to read than a good C program.
| I think the problem is noise characters like "$" and "&".  The average
| Perl program is dominated by them.  Most Perl programs would be just
| as readable, maybe more so, without them.  They're more heavily inked
| than lowercase letters so they tend to draw your eye, unlike
| punctuation.  You'd think you could train yourself to ignore them, but
| there are rare places where they're crucial to the meaning of the
| program.  This may be one reason people confuse <FH> and <$FH>.  The
| "$" is so ubiquitous it doesn't seem to have meaning.

Hear, hear!  I agree completely!  I really, really like Perl scripts,
but I grow really, really tired of those dollar-signs ($).  This is one
of the reasons why I am investigating using python -- it's
signal-to-noise ratio is much higher than Perl's.  Even though it may
not be as optimized as Perl is by the One True Hacker, nor as well
tested by the Teeming Perlophytes, it has some very nice features.

Oh well.


     Center for Computational Sciences and Engineering (CCSE)
          University of California, Santa Barbara (UCSB)
           3111 Engineering I, Santa Barbara, CA 93106



Tue, 29 Mar 1994 05:06:15 GMT  
 lines of code in perl vs. c
| | A good Perl program seems to me harder to read than a good C program.
| | I think the problem is noise characters like "$" and "&".  The average
| | Perl program is dominated by them.  Most Perl programs would be just
| | as readable, maybe more so, without them.  They're more heavily inked
| | than lowercase letters so they tend to draw your eye, unlike
| | punctuation.  You'd think you could train yourself to ignore them, but
| | there are rare places where they're crucial to the meaning of the
| | program.  This may be one reason people confuse <FH> and <$FH>.  The
| | "$" is so ubiquitous it doesn't seem to have meaning.
|
| Hear, hear!  I agree completely!  I really, really like Perl scripts,
| but I grow really, really tired of those dollar-signs ($).  This is one
| of the reasons why I am investigating using Python -- it's
| signal-to-noise ratio is much higher than Perl's.  Even though it may
| not be as optimized as Perl is by the One True Hacker, nor as well
| tested by the Teeming Perlophytes, it has some very nice features.
|
| Oh well.

As Larry has said in this forum before, what's all the objection to
having a reserved character denote scalar variables (or any type of
variable, for that matter)?

Would you rather that your scripts broke because some reserved word
got added later?  I think it was Tom that said that some version *1*
Perl scripts still fired up and ran, even though the manpage for Perl
has gone from 15 pages to 75 pages in that period of time, and dozens
of new reserved words added.

It's a namespace problem, people.  But then, the issue of namespaces,
like nearly anything else, is probably a religious matter. :-)

$print = "Just another Perl hacker,"; print $print
--
/=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\
| on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III      |

\=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/



Wed, 30 Mar 1994 00:35:24 GMT  
 lines of code in perl vs. c

Quote:

>As Larry has said in this forum before, what's all the objection to
>having a reserved character denote scalar variables (or any type of
>Would you rather that your scripts broke because some reserved word
>got added later?  I think it was Tom that said that some version *1*

1. Larry's own metaconfig package broke when the keyword "package" got
added, because it used the lowercase word "package" as a filehandle.

2. You rarely need to add a new reserved word.  Only words that have
syntactic value need to be reserved.  Perl has dozens of builtin
function names that happen to be reserved but don't have to be.  Perl
only has thir{*filter*} keywords with syntactic meaning, some of which are
redundant or can be made redundant.

3. Given less than thir{*filter*} keywords, wouldn't it make more sense to
distinguish the keywords with a special character instead?  An average
program is going to use variables, subroutines, and operators much
more than it uses keywords, so this would be more compact.

4. The syntactic keywords are mostly control structures, like while
and if.  When was the last time you wanted to use while or if as a
variable name?  And that still needn't be fatal.  PL/I lacks reserved
words, although it takes a lot of effort to parse properly.

5. It is useful to separate the builtin function namespace from the
user's namespace, but there are less noisy ways than stuffing a "&" in
front of every user function.  Perl already has packages to manage
namespace.  Why not use these?  (Yes, I know packages were a late
invention.  This is irrelevent to evaluating Perl as it is today.)

6. Perl's prefixes determine value type, not object type.  In BASIC,
FOO$ means string object FOO.  In Perl, $foo can mean a scalar object,
a vector object, or a table object, depending on what comes next.
This is much harder to read and much more confusing.
        print $x
        # are you surprised by the next line?
        {3,4};

7. Except "&".  "&" denotes object type, not value type.  &foo means
subroutine foo.  Why don't you say $foo() when you want to call
subroutine foo and get back a scalar value?

8. Filehandles and dirhandles don't get a prefix.  Why don't they have
a prefix?  Or rather, why does everything else have a prefix?

9. Shell programming uses $foo, without the complications of Perl.
The $ just means evaluate the next word as a variable.  And in "rc",
the Plan 9 shell, $ is explicitly an operator.  You can chain it:
        a=b; b=hello; echo $ $ a world;

10. The $ in shell is needed because the normal state of words is
quoted.  Variable substitution is the exception.  In Perl, most words
are meant to be evaluated.  Quoting is the exception.

11. The $ in shell is used less than in Perl, because data streams
(e.g. files and pipes) are the primary data type in shell programming.
Perl lacks the communicating-sequential-processes view of the world
that shell has, so variables are necessary in Perl to shuffle data
around.  The use of $_ is an attempt at faking this, but it only
provides a single channel of communication.

12. Perl and shell really have little in common.  Perl is much more
like C.  C doesn't use prefixes, and you can correctly claim that C
has namespace problems, but Perl's package mechanism adequately deals
with this in medium to small projects.  For medium to large projects,
you need something more, to deal with package name clashes.

Having said all that, let me say that I have never had problems with
Perl's prefix scheme.  Perhaps having followed Perl since version 1
helps.  Back when $ was the only prefix, things made sense.  Each new
prefix and the form it took also made sense, given the existing
constraints of the language.  But newcomers to the full-fledged
language seem to get confused by the weirdness of it all.

It's nice and all that Perl 1 scripts still run, but the backward
compatibility has resulted in a something that's terribly twisted.
There are other ways of supporting old programs.
--



Wed, 30 Mar 1994 12:11:24 GMT  
 lines of code in perl vs. c

:  One idea I've been thinking about is some sort of structure compiler
:which would turn a description of the structure of a file into perl code
:to read and write records. I find that a lot of the stuff I use to read
:binary files can be cobbled together from boilerplate

already done: use c2ph.

--tom



Thu, 31 Mar 1994 05:28:08 GMT  
 lines of code in perl vs. c


Quote:
> As Larry has said in this forum before, what's all the objection to
> having a reserved character denote scalar variables (or any type of
> variable, for that matter)?

IMHO, the objection is against the special variables, whose names do
have some resemblance to modem noise. Although a number of them can be
avoided if you like (e.g. $_, $` and friends) you still need access to
$!, $=, $^ etc. if you need the associated functionality.

Personally, I would not mind something like an internal package:

    print STDERR "Error: cannot open $file, reason: $Perl'LastError\n";

or even pseudo packages:

    $STDOUT'TopOfForm = "std_top"; $STDOUT'Form = "std_out";
    $STDERR'Buffered = 1;

Although a little bit harder to write, this would increase readability
and maintainability a lot.

        Johan
--

Multihouse Automatisering bv                   uucp: ..!{uunet,hp4nl}!mh.nl!jv
Doesburgweg 7, 2803 PL Gouda, The Netherlands  phone/fax: +31 1820 62911/62500
------------------------ "Arms are made for hugging" -------------------------



Wed, 30 Mar 1994 19:25:50 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. good code vs code that works

2. -ln015 on #! line -vs- command line

3. PERL vs. C/C++ code size factor

4. Performance of Perl scripts vs. compile C code

5. HELP: Automatic Execution of perl scripts RE: first line of code #!/usr/bin/perl/

6. Perl line numbers vs Apache error_log reported numbers?

7. price of perl (was Re: GUI vs command line)

8. Perl module to count lines of code and comments

9. In-lining Perl Code???

10. Perl script for counting lines of c code

11. end-of-line characters for distributed Perl code

12. Where to post Perl code (<100 lines)

 

 
Powered by phpBB® Forum Software