In the application I'm working on now, there is much more CPAN code (Class::DBI, HTML::Template, CGI::Application, DBI, Data::FormValidator, SOAP::Lite, XML::Parser, etc.) than code written by me. The code written by me is the actual logic of the application, i.e. the part that couldn't possibly come from another source since it is specific to this project. | [reply] |
| [reply] |
I'm not questioning the seriousness of your projects. I was questioning the language that you used when you said, "90% of every Perl application has already been written, tested, and deployed."
Maybe it is a silly thing to harp on, but it is patently false.
-- dug
| [reply] |
The code I produce in Perl could easily be 10% of what I would produce doing everything in C without access to a huge library like CPAN.
| [reply] |
What libraries have you found yourself missing when programming in C?
Don't get me wrong, the CPAN is certainly one of my favorite things about Perl. I have just never had a job programming something substantial in any language that was already 90% complete. I would certainly never say that "90% of every" application in *any* language "has already been written, tested, and deployed". Some of them, sure. But not all of them.
-- dug
| [reply] |
Let's say I want to write a basic application. It reads in an XML file, does some stuff to it, then writes it out to a CSV. Quite a common thing to do, actually. It might look something like:
use strict;
use warnings;
use XML::Parser;
use Text::CSV;
# Do my parsing here ... maybe 100 lines
# Do my munging here ... maybe 100 lines
# Do my writing here ... maybe 25 lines.
A total of no more than 225 lines of code I wrote. Now, let's see how much code was provided for me. Not counting the amount of time I save because Perl natively does for me the following:
- Memory management
- Hashes as first class variables
- Lists as first class variables
- Datatype conversion
- A lot more than that
Already, I've saved about 25% over most other languages, just from choosing Perl!
But, that's not what you care about. XML::Parser was a huge portion of this application. Parsing XML is one of the harder things you can do. Let's say that takes about 1500 lines to do. (It's actually much more than that, but who's counting?)
Now, writing to a CSV sounds easy. But, it's actually really complicated. There're a lot of exceptions that have to be handled just right or you get screwed up. Let's say that's another 500 lines of code. (Again, it's more than that, but who's counting?)
So, we have at most 225 lines we wrote and at least 2000 lines we didn't have to. My math may be off, but that seems to be about 90% I didn't have to write, test, maintain, or do anything with ... except blithely use.
Those numbers hold pretty close, in nearly every application I've ever worked with. You want to deal with XSLT? No problem! Excel? Done. Databases? Nearly every one is supported out of the box. OO getting you down? Pick your poison.
Personally, most of my large apps are down in the 80-85% range, because I like to write large object hierarchies. But, that's just me. A lot of people (especially sysadmins) are in the 95-97%(!) range, leveraging huge amounts of code.
Update: I forgot to even mention the time savings, which are often in the 98-99.9% range. I once had a scripty-doo up and running that correlated information between an Oracle database, a MS-SQL database, and an XML document, outputting the results in Excel ... in less than 15 hours, from scratch. That is impossible in any other language. Period.
------
We are the carpenters and bricklayers of the Information Age.
The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6
... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
| [reply]
[d/l] |