Re^6: Perl for big projects

Hi, [id://chromatic]. I'm not certain what point you were trying to make here. Suggesting that some features are missing from all languages, doesn't negate the value of the ones they do contain. There is a place for, say, strict type checking, and Perl doesn't require that. Other languages do. They are probably a better choice in some instances.

Perhaps your point was that no language features can substitute for adequate code review and testing. This is true. Even so, code review and testing do not prevent disastrous bugs from getting through to production. Review alone doesn't catch all the bugs. Relying on language features doesn't catch or prevent all the bugs, either. If I had to choose *only* one safeguard, I'd opt for code review and testing, having many eyeballs look over the code. But refusing to use other available tools is (IMNSHO) taking unnecessary risks. Just because there are laws and police to protect my property, doesn't mean I leave my doors unlocked.

Understand that I'm not being critical of Perl. I love that language, and it's almost the only thing I use. Still, it isn't perfect, and it isn't necessarily the best language to use in every situation.

Comment on Re^6: Perl for big projects

Replies are listed 'Best First'.
Re^7: Perl for big projects by chromatic (Archbishop) on Jul 14, 2006 at 19:20 UTC
My point is that I've personally encountered very few maintenance problems while using Perl caused by anything remotely resembling a type error that a static type system could catch. (Perhaps a handful or two in eight years.) (Hey, I've even written simple Haskell code that passes the type inferencer but has a trivial mathematic proof violation.) I've almost never failed to encounter bad identifier names, poor factorization, massive duplication, and poor factorization in code with maintenance problems. My theory is, fix the big errors first. People write bad code badly. Don't pretend that static analysis or compiler tools can fix anything but trivial errors. It (currently) can't.	[reply]
Re^8: Perl for big projects by rhesa (Vicar) on Jul 16, 2006 at 13:46 UTC
I've almost never failed to encounter bad identifier names, poor factorization, massive duplication, and poor factorization in code with maintenance problems. I like the way you make your point by mentioning "poor factorization" twice ;^)	[reply]


more useful options
	PerlMonks