Re: The Perl Crackpot Index

Lots of points for designing a new CGI parser.

Check. I rolled my own CGI system because it was easy and the one most people were advocating (namely, CGI.pm) was horrible.

Very high points for arguing that you don't need strictures or warnings.

Need? Warnings come in pretty handy, although I do wish I could selectively shut off certain ones. I only use strictures when I'm writing a module that will get re-used by multiple programs. I certainly don't *need* either of them.

From Anonymous Monk's list...

Low points for "Perl is not object oriented"

How about, "Perl5's OO isn't very good, but Perl6 will fix it"?

Medium points for writing a database abstraction layer.

I've done that. It was a very simple one (basically, it had subs for retrieve(), add(), change(), find(), and so forth, all of which dealt with hashrefs. I've since started using Class::DBI instead, mainly because it's more standardized (in the sense that I'm not the only one who uses it), although in a couple of ways my system was better. Among other things, with my handrolled system, you didn't have to change the code if you added a field to a table, except if you wanted to do something with that field, of course. (It didn't do everything Class::DBI does, though; for instance, it didn't even think about cascading deletes. But, I don't need cascading deletes...)

Medium points for suggesting some random functionality needs to be in the Perl core.

The functionality provided by DateTime absolutely should be in core.

# Low points for each JAPH you've written. # Medium points for each JAPH you've posted.

Lost count long ago.

Low points for using map or grep in void context.

I've done that.

Low points for parsing HTML with a regex.

At one point I attempted to parse (a subset of) XML with a regex. Well, not fully parse, just enough to determine where to insert a certain element. Does that count? What if I tweaked the regex several times in response to bug reports before I gave it up and ended up using XML::Twig to solve the problem?

Medium points for not writing something now "because Perl6 will be here soon".

I've done that. There's a particular functionality that Emacs has, that I'd like to have in Perl, but I am not willing to implement it in Perl5, because the object model just doesn't provide the features I need to make it easy enough to be worth doing. But the Perl6 OO model will make it much easier...

Medium points for promoting whatever you use yourself when someone asks about a Perl IDE.

Emacs, of course.

Comment on Re: The Perl Crackpot Index

Replies are listed 'Best First'.
Re^2: The Perl Crackpot Index by autarch (Hermit) on Jul 27, 2005 at 15:29 UTC
The functionality provided by DateTime absolutely should be in core. Eek, no! The DT stuff needs to keep up with leap second and time zone change announcements, so it needs its own release schedule. We'd have to figure out a way to release data packages separately from what's in the core. Of course, in theory, I can see why this should be in the core, just because it's the kind of low-level data type that you want for programming. But given how easy CPAN is to use, is it really a big barrier? I think the big problem, as usual, is that there's lots of similar stuff to wade through. Fortunately, DateTime seems to have enough of a following these days that every time there's a datetime programming question, at least one respondent says "use DateTime", so the word is out.	[reply]

Replies are listed 'Best First'.

Re^2: The Perl Crackpot Index
by autarch (Hermit) on Jul 27, 2005 at 15:29 UTC

The functionality provided by DateTime absolutely should be in core.

Eek, no! The DT stuff needs to keep up with leap second and time zone change announcements, so it needs its own release schedule. We'd have to figure out a way to release data packages separately from what's in the core.

Of course, in theory, I can see why this should be in the core, just because it's the kind of low-level data type that you want for programming.

But given how easy CPAN is to use, is it really a big barrier? I think the big problem, as usual, is that there's lots of similar stuff to wade through. Fortunately, DateTime seems to have enough of a following these days that every time there's a datetime programming question, at least one respondent says "use DateTime", so the word is out.

[reply]

In Section Meditations