Re^2: Help me avoid writing C Programs in Perl for a living

These are the sorts of things I'm looking for:

* You can write code that simply won't work if it's misused.
* You can write Code with pluggable log points and business logic that becomes easy to test and manipulate with configuration instead of code hacks.
* ... allow you to write code boldly and quickly because you'll have the baseline correct behavior known.

As for test driven development, we are moving towards that. In fact I am co-pointing that study group. One of my basic precepts is going to be: If there's not a test for it, that code shouldn't exist. So if you write your own accessors, you need to write test for all your accessors. OTOH, if something like Moose is setting up your accessors in declarative style, then it becomes a question of: is Moose correct? Unfortunately, getting to the place of test-driven development, is going to be a very long road--we have 7 different systems, and hardly any shared code between them. On top of which, time for developing tests is allocated along with the time needed for bugfixes and adding new functionality.

Comment on Re^2: Help me avoid writing C Programs in Perl for a living

Replies are listed 'Best First'.
Re^3: Help me avoid writing C Programs in Perl for a living by stvn (Monsignor) on Mar 25, 2010 at 22:09 UTC
OTOH, if something like Moose is setting up your accessors in declarative style, then it becomes a question of: is Moose correct? FWIW, Moose is really well tested and the Moose development team is dedicated to test driven development. Class::MOP (the underlying meta object protocol that Moose is built on) has 2242 unit tests and Moose itself has 4632 unit tests. We also consider the test suites of the over 700 modules that depend on Moose to be an "external" test suite, so much so that we have a smoke testing setup which downloads and tests a set of approx. 100 of those CPAN modules and runs them before we release (and you can actually make it download all 700 or so if you want, but that tends to take a while). Additionally the Catalyst framework now uses Moose and since that is still a very active project Moose ends up getting exercised there as well. One of the key selling points of Moose is that you no longer need to write tedious and repetitive accessors and constructors all the time. Moose instead provides a sane, consistent and well tested object system which does these things for you. We test it, so that you don't have too. Now regarding "correct"-ness. No, we do not have a proof available to show that Moose is correct, but unless you're working in aerospace or academic research then I doubt that is what you mean. But you should know that Moose was built after about a year of steady R&D via the Pugs project and is based very heavily on tried and proven object models like CLOS and Smalltalk. It is and has been from the very start built as a solid production ready framework which very specifically does not make use of Perl black magic or insane hacks because the inherit fragility they bring to the code. In short, it is not a toy it is serious business. -stvn	[reply]

Replies are listed 'Best First'.

Re^3: Help me avoid writing C Programs in Perl for a living
by stvn (Monsignor) on Mar 25, 2010 at 22:09 UTC

OTOH, if something like Moose is setting up your accessors in declarative style, then it becomes a question of: is Moose correct?

FWIW, Moose is really well tested and the Moose development team is dedicated to test driven development. Class::MOP (the underlying meta object protocol that Moose is built on) has 2242 unit tests and Moose itself has 4632 unit tests. We also consider the test suites of the over 700 modules that depend on Moose to be an "external" test suite, so much so that we have a smoke testing setup which downloads and tests a set of approx. 100 of those CPAN modules and runs them before we release (and you can actually make it download all 700 or so if you want, but that tends to take a while). Additionally the Catalyst framework now uses Moose and since that is still a very active project Moose ends up getting exercised there as well.

One of the key selling points of Moose is that you no longer need to write tedious and repetitive accessors and constructors all the time. Moose instead provides a sane, consistent and well tested object system which does these things for you. We test it, so that you don't have too.

Now regarding "correct"-ness. No, we do not have a proof available to show that Moose is correct, but unless you're working in aerospace or academic research then I doubt that is what you mean. But you should know that Moose was built after about a year of steady R&D via the Pugs project and is based very heavily on tried and proven object models like CLOS and Smalltalk. It is and has been from the very start built as a solid production ready framework which very specifically does not make use of Perl black magic or insane hacks because the inherit fragility they bring to the code. In short, it is not a toy it is serious business.

-stvn

[reply]