Wednesday, July 28, 2004

Enterprise Perl

James Duncan talked about enterprise software. Programmers don't actually use the term "enterprise", it was invented by marketing people, but effectively its software that doesn't make money and it isn't the product itself but instead is deployed behind the scenes as an enabling tool.

The thing about enterprise software is that it has to work, and should fail as gracefully as possible. Historically Perl is described as a swiss army chainsaw, highly versatile but distressingly inelegant, and was used as an automation language.

He argues(!?) that unquestionably,
  • We should be writing object orientated code
  • You shouldn't repeat yourself (copy & paste is bad)
  • Cargo cult programming is bad
  • Use small or one concept methods
  • Contents of loop should be a method call
  • Constant should only appear in one place (common blocks?)
  • Config files are bad things (really?)
  • Logging should be at an appropriate granularity

More contraversially, we should all be using proper exception handling,

sub UNVIERSAL::exceptipn {
my $class = shift;
no strict refs;
@{$class . '::ISA' } = qw ( Error );

exception Foo;

and also,
  • Object orientated programing is about message passing
  • Data driven development is bad (use mechanisms)
  • State is a bad thing (creates tightly bound components)
  • But being stateless is a bad thing (implied knowledge)
  • Strike a balance between state and stateless-ness
  • Don't hardwire class names (why?)
  • Don't use arguements to constructors (really!?)
  • Better to call methods (what about overhead!)
  • Use method chaining to replace constructors (return $self)
  • Recompose types, subclassing in Perl is poor, so use tie'ing
  • Recompose builtins, better as methods (eek!)
  • Objects are rarely true as a result of constructing it
  • Conditionals are bad (confuses method names?)
  • Use value singletons and compare references

Some of which I agree with, and alot of which I don't...

Finally he argues that as a programmer you should ask who you're talking to, you aren't talking to a computer (we'd be writing in assembler), instead you're writing for other programmers.