> I don't know why this guy thinks it's a good idea to create his own idioms and language features which inhibit the ability to understand the code by pretty mu

> I don't know why this guy thinks it's a good idea to create his own idioms and language features which inhibit the ability to understand the code by pretty much anybody else. First, there are two ways to read that last example: 1. Literally as Perl code: has() and dbmethod() are functions. There is no difference between has id => (is => 'ro', isa => 'Int'); and has(id => (is => 'ro', isa => 'Int')); If that doesn't occur to you, you have no Perl experience ;-). 2. as language extensions: has and dbmethod define new aspects to the class in a declarative way. The thing is, these are both simultaneously true, and that means you can read them as #2 when coding and fall back to #1 when debugging. Since they are simultaneously true, there's no difference between writing new functions and what we do here, except that this allows (and does not require) one to think about the code in additional ways. As a note, exactly what people I know like about working with Lisp on large projects is the mutability and the ability to create very useful and readable idioms for the project.