http://qs321.pair.com?node_id=36095


in reply to How big is yours?

With regard to those "N-thousand lines of code" statements, please bear in mind that one line in Perl is many lines in other languages. For a more quantitative point of view on this, please see any of the function-point-metric comparisons of current programming languages (e.g., this one).

One related important point is the observation that the number of errors in a program increases linearly with the size of the program (in lines of code) (see Code Complete : A Practical Handbook of Software Construction. By McConnell, Steve M. ).

This obviously means: less code to write for a given functionality means less errors. And less errors make for faster development, and better applications.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Replies are listed 'Best First'.
RE: RE: How big is yours?
by Caillte (Friar) on Oct 12, 2000 at 22:01 UTC
    While in university I wrote a talker for my fiancee and I to get together on. It came out at around 40,000 lines of code altogether (Ok, I admit I got carried away... it was almost a complete MUD including online coding by the time I finished ;) ) After a while I got bored with chasing rogue pointers and decided to do a complete rewrite in a language I had just heard about, Perl. The new system came in at under 10,000 lines ;)

    Seriously though, the question is not really how big a perl program can be, there is no reason why you couldnt write full applications in perl (the people I work for, for example, have a working perl library exceeding 100,000 lines of code) the big question is 'is Perl really the right language?'

    Perl has a number of great things going for it, primarially things like modules that avoid the need to reinvent the wheel and it's easy syntax structure that allows the programmer to concentrate on program flow rather than havng to worry about every little detail. The result of this is most perl programs will be smaller (in terms of lines) and more rapidly written than in other languages. However, the exact same thing works in reverse when it comes to program efficency. Perl is, by definition, an inefficent language when it comes to computer resources. It has to be simply due to the fact that it is interpreted 'on the fly'.

    Therefore, while perl could be used for almost any program, there are a number of situations that preclude it.

    A shame really ;)

      The 'on the fly' remark is a little misleading. Yes, Perl is an interpreted language. However, it's compiled into bytecode and then executed, when possible. (Things like eval which make my life more convenient can be evaluated at run time.)

      The compiler's pretty good about optimizing things, as you'd expect from Real Computer Scientists, so there are things Perl can do faster than the corresponding C program. In other cases, Perl may be slower, but even taking that into account, it's faster to write, debug, and execute a Perl program that runs at half the speed of a C program that takes twice as long to write and to debug.

      The O'Reilly site has chapter 18 (or so) from the new Camel available online, and it goes into the life cycle of a Perl program including the compilation stage. Could be worth a look.

RE: RE: How big is yours?
by Nitsuj (Hermit) on Oct 12, 2000 at 09:27 UTC
    Just remember...

    That measure of quality is a measure of the quality of the pm's. It's sort of like people comparing JAVA, without it's set of libraries, it's nothing. It's sort of like saying that one line of C is thousands of assembly lines. A line of C and a line of perl can be roughly equivalent given that the object code is out there to back it up. Perl is good because of the support of people like us, who improve upon it, with the great tools that the core language gives us.

    Just Another Perl Backpacker