Actually I quite agree, Perl does allow really bad code to be written, and makes it quite easy.
I believe that this is a strength when you're dealing with small tools, and definately a hinderance when working with large projects.
However, I don't see it as an argument why Perl can't / shouldn't be used for large projects. If, as you say, there are coding standards, peer review and some decent programmers working on it, then some wonderfully concise, efficient and maintainable code can come out of it.
What I'm sick of, is people criticizing my use of Perl for various projects, with statements like "You should use a *standard* enterprise scalable development architecture such as J2EE, not Perl which is only good for prototyping".
I realise it's not you, but I really do want to know why people say that.
I'd be very interested in this, except for the single fact that's it's Java?
I may be offending some people here, but I hate Java. After having worked with it for a couple of years I hate it even more.
I've often had the need to store objects in other languages (Perl, PHP) and I'd have to say I've had a bit of difficulty mapping the data into an RDBMS, but not enough trouble to make me want to switch languages.
Actually, I don't have a huge problem with the Java language itself, just that it has to run in a VM, it's slow, takes ages to compile, has crappy string handling (compared to Perl/PHP but better than C)..
I have a slightly similar problem with my IBM Thinkpad. When it's plugged in and I'm not wearing shoes and I touch the headphone port I get quite a painful shock. It's surprisingly easy to do, since most of the time my thinkpad stays connected on top of my TV, so if I happen to grab it the wrong way, I hate to give up watching TV for a while and just sit there whimpering.
We do this, although on a slightly smaller scale at the ISP where I work. We have a weekly backup of around 1TB (incrementals), and the tape system was giving us problems. So we switched to a disk-based system, which, apart from disk failures has been quite good.
I wrote some perl software to handle the backups, as a client and a server, as well as reporting, archiving old backups to tapes (may as well make use of the money invested in the tape robot), and cleaning up space.
It's called dbackup, and it's at http://www.dparrish.com/dbackup.html
Oh.. and in one of the C source files I have access to, is a 74 line function to remove a trailing " ".
You don't want to know what the rest of it is like.
Stabbed in the back by my own website..
tsk tsk.
That's an easy one to explain.. Where I work, the only C/C++/Java code I have access to is strictly confidential.
Excellent! A coherent argument :)
Actually I quite agree, Perl does allow really bad code to be written, and makes it quite easy.
I believe that this is a strength when you're dealing with small tools, and definately a hinderance when working with large projects.
However, I don't see it as an argument why Perl can't / shouldn't be used for large projects. If, as you say, there are coding standards, peer review and some decent programmers working on it, then some wonderfully concise, efficient and maintainable code can come out of it.
What I'm sick of, is people criticizing my use of Perl for various projects, with statements like "You should use a *standard* enterprise scalable development architecture such as J2EE, not Perl which is only good for prototyping".
I realise it's not you, but I really do want to know why people say that.
"As for Perl and the DB modules, they're great for small or stopgap systems"
That same argument again? It does matter what language you write in, you can still get appalling code if you don't know what you're doing.
I am still yet to see a good reason why Perl cannot be _effectively_ used for anything other than a small/stopgap system.. Can you provide one?
Wonderful. I could quote college programming texts too if I wanted.
Even if I believed that 100% of the time your short statement was correct, it has nothing to do with my comment.
E.g.: PHP and Perl have no build in object
serialization and deserialization.
Perl:
use Storable;
my $string = freeze $bighash;
my $anotherhash = thaw $string;
PHP:
$string = serialize($bighash);
$anotherhash = unserialize($string);
Both of these are built-in (or close to it).
I'd be very interested in this, except for the single fact that's it's Java?
I may be offending some people here, but I hate Java. After having worked with it for a couple of years I hate it even more.
I've often had the need to store objects in other languages (Perl, PHP) and I'd have to say I've had a bit of difficulty mapping the data into an RDBMS, but not enough trouble to make me want to switch languages.
Actually, I don't have a huge problem with the Java language itself, just that it has to run in a VM, it's slow, takes ages to compile, has crappy string handling (compared to Perl/PHP but better than C)..
Yuck!
I have a slightly similar problem with my IBM Thinkpad. When it's plugged in and I'm not wearing shoes and I touch the headphone port I get quite a painful shock. It's surprisingly easy to do, since most of the time my thinkpad stays connected on top of my TV, so if I happen to grab it the wrong way, I hate to give up watching TV for a while and just sit there whimpering.
We do this, although on a slightly smaller scale at the ISP where I work. We have a weekly backup of around 1TB (incrementals), and the tape system was giving us problems. So we switched to a disk-based system, which, apart from disk failures has been quite good.
I wrote some perl software to handle the backups, as a client and a server, as well as reporting, archiving old backups to tapes (may as well make use of the money invested in the tape robot), and cleaning up space.
It's called dbackup, and it's at http://www.dparrish.com/dbackup.html
If you're like me, living in Australia and paying 15c/mb for your traffic... That's $105 in download costs, plus the $3.99 to watch the movie once.
How can that be cheaper than paying $34.95 for the DVD?