4 ms·

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

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.

BugBrother 13y ago
Uh, no. That wasn't his own language features, he used Moose in the last example, it is the standard OO environment in Perl. To simplify a little, most new Perl code use Moose. The author did discuss a bit how Perl is extendable, which is where Moose comes from.
- einhverfr 13y ago
  To be clear, I am also the author of the PGObject::Util::DBMethod which adds the dbmethod() syntactic sugar used in the third class. One thing to note is that this was done specifically in the way it was so that it would fit in with Moose-like idioms, so it is more a matter of extending the Moo(se) way than it is creating a whole new idiom.
einhverfr 13y ago
> 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.

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.

BugBrother 13y ago

Uh, no. That wasn't his own language features, he used Moose in the last example, it is the standard OO environment in Perl. To simplify a little, most new Perl code use Moose. The author did discuss a bit how Perl is extendable, which is where Moose comes from.

einhverfr 13y ago
To be clear, I am also the author of the PGObject::Util::DBMethod which adds the dbmethod() syntactic sugar used in the third class. One thing to note is that this was done specifically in the way it was so that it would fit in with Moose-like idioms, so it is more a matter of extending the Moo(se) way than it is creating a whole new idiom.

einhverfr 13y ago

> 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.