Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Hercynium (8027)

  (email not shown publicly)
AOL IM: hercynium (Add Buddy, Send Message)
Yahoo! ID: hercynium (Add User, Send Message)
+ -

  Comment: I wrote a song parody about this once... (Score 1) on 2010.03.28 20:52

by Hercynium on 2010.03.28 20:52 (#71803)
Attached to: Some Facts About Schwern

Based on this photo:

Everyday I get up and pray to Schwern
And he increases the number of refs by exactly one
Everybody's coming to YAPC::NA these days
Last night there were perl hackers on my lawn

Take the perl-heads bowling, take them bowling.
Take the perl-heads bowling, take them bowling.

Some people say that bowling alleys have len(@lanes) < $small (have big lanes x2)
Some people say that bowling alleys all eq $the_same (all the same x2)
There's not a line that goes here that soundex_match($line, 'same') (rhymes with same x2)
Had a dream last night but I forgot what delete $dream{about} (what it was x2)

goto CHORUS;

Had a dream last night about use strict and warnings
Had a dream I wanted to sleep() next to plastic
Had a dream I wanted to bless your hashref
Had a dream it was about undef

(copied from my perlmonks profile)

Read More 6 comments
Comments: 6
+ -

  Comment: Re: Why Ruby is prettier and Padre changes the Per (Score 1) on 2010.02.09 17:36

For a while, I've had rattling around in my brain an idea for being able to do installations of Perl apps, from CPAN, with incredible flexibility.

I've yet to come up with a simple "pitch" for the idea, but let me try to describe...

First: Layouts

Different systems have different conventions for where applications, pieces of applications, and other related files et al. are to go. One may want to comply with the LSB, the FHS, Debian's policies, or whatever layout Windows or Solaris may dictate. Perhaps an admin wants to use a Stow-style layout, or even something they've come up with custom!

Next: Distributions

Typically one desires to obtain and install a particular distribution of software or data, or *something*. There are different types of distributions one would want to install: libraries, frameworks, CLI apps, GUI apps, web apps, servers, etc, etc...

Could it be possible to create an installation framework that can allow one to easily install any type of distribution with any type of layout and have the installed stuff Just Work(tm) while still allowing end-user customization of the process?

I've made past attempts at trying to envision the best way to go about it, but a combination of lack of tuits, and a seeming lack of demand has kept me from really trying to tackle it. One thing I'm certain of is that it would require creating Yet Another Build System. In addition, for things to work properly, distribution authors would probably be required to parameterize a lot more things, ie. a Lot More Work.

It's a dream, but hey, isn't that what code is made of? :-)

Read More 62 comments
Comments: 62
+ -

  Comment: Exciting work! (Score 1) on 2009.10.22 10:29

by Hercynium on 2009.10.22 10:29 (#70939)
Attached to: Hague grant work: the new regex engine and NQP

This is terrific, pmichaud! I think having Perl 6 Grammars and Regexes in NQP will make it a killer app for Parrot.

Thank you for all your hard work and innovation!

Read More 1 comments
Comments: 1
+ -

  Comment: Re:global bad, lexical good (Score 1) on 2009.10.19 13:48

hear hear!

Whenever I encounter a substantial (>100 lines) perl script with no main sub I get nervous.

A quick, one-off script may not require the extra structure and discipline, but we all know how easily a one-off can become mission-critical... and quickly grow in size scope and function.

In my opinion, file-scoped vars are nearly as bad as true globals, and packaged-scoped vars less-so, but still best to avoid, unless the alternative is sufficiently more complicated code somewhere else.

By using a main block/sub you make it much clearer each time a file, package, or global var is declared/defined, plus code that is intended to execute only once is also clearer.

In the end, the maintenance programmer will thank you for confining as much code as possible to lexical blocks. Always think of the maintenance programmer... remember, it may be YOU... or a violent psychopath who knows where you live.

Overall, the only reason I can think of to *not* use a main sub (and therefore minimize file/package/globals) is in the interest of the bad kind of laziness, the kind that saves a second now because of not caring for later.

Read More 5 comments
Comments: 5
+ -

  Comment: There should be a "NoScript Appreciation Award" (Score 1) on 2009.09.29 15:27

by Hercynium on 2009.09.29 15:27 (#70695)
Attached to: Javascript

My current employer is a web-based business and one of the things I love is how they bend over backwards to ensure that their site is fully functional and looks 100% correct *without* JavaScript.

We've even had to battle with our payment processor since they recently said they require users to have JS enabled to complete their transaction and that's just ridiculous - it worked *fine* before!

I hereby nominate my $work_website for the first annual "NoScript Appreciation Award" :-)

Read More 2 comments
Comments: 2
+ -

  Comment: Re:DDT & Benchmarking (Score 1) on 2009.09.08 22:10

Indeed, in this case the test harness *is* testing on a more functional/integration level. As we refactor the code that runs the client's site, we want to ensure that we neither break any part of the site nor slow it down.

Still, using this type of technique has made me wonder if there is a good way of encouraging benchmarks of perl modules by piggy-backing on the tests.

An example of this can be found in the test suite for Sort::Maker. (It was actually Uri's advice to look at that module's tests that inspired the design of my website DDT code)

I do understand that benchmarking typically needs much more "context" than unit tests, but a test harness with an API that enables/encourages 'performance comparisons' with other code that does the same thing could be a good springboard to get people providing benchmarkable code/tests in their CPAN dists.

Read More 10 comments
Comments: 10
+ -

  Comment: DDT & Benchmarking (Score 1) on 2009.09.07 21:27

I wonder if your post today was inspired by what I wrote in reply to your last post or we're just on the same wavelength with this. :)

At YAPC::NA this year I did a lightning talk on a web-testing framework I built for a client*. The main topic was just that the tests were all data-driven, and because of that I gained a pile of great functionality, not least of which was the ability to turn my test suite into a benchmarking suite seamlessly.

By running via prove or directly, each script was a set of unit tests. By running under a utility I called "bench", those same test scripts became benchmarks (unless marked as not suitable in the test data structure)

*Funny story - schwern told me "Congratulations, you've just re-invented Selenium!" Lo and behold I looked at Selenium and showed it to the client and they are *delighted* that I threw away a month's work! ;-)
Read More 10 comments
Comments: 10
+ -

  Comment: Re:The important thing here (Score 1) on 2009.09.04 17:48

Personally, I take a couple of things into account when I decide whether or not extra modules constitute "bloat".

First, how likely are these modules to fail to install on the target platform(s)? If they are going to make my code harder for the sysadmin (often myself) to move, port, and maintain in the future they may not be worth pulling in to my dependency chain.

Second, how does this module perform given how I will be using it in my code? How does it perform compared to it's alternatives?

Third, do I need any of these dependencies for anything else in the app? Are they good enough that I would use them instead of *their* alternatives? That's usually not a problem for me, but I *do* think about it.

I'm the type of programmer who will spend an extra hour or two writing code several ways, then selecting the one that I believe best reflects my overall needs. Yes, I throw out *lots* of code. I don't care.

The CPAN already provides me with excellent tools to gauge how using dist/module will affect my program's portability and to some extent maintainability. CPANTS also lets me get at a glance some useful info on kwalitee and that factors in as well.

The only thing not already handed on a silver platter to Perl developers are benchmarks - and I don't expect that to change any time soon! (would be nice for CP6AN though *hint hint*)

Read More 11 comments
Comments: 11
+ -

  Comment: Re:The root problem is interspersing code with POD (Score 1) on 2009.07.27 13:20

by Hercynium on 2009.07.27 13:20 (#69686)
Attached to: Three things in Perl 6 that aren't so great
I think you've touched upon something that leads to the root of the issue - the fact that there are several different types of documentation that is produced, each with different display needs and different audiences, and possibly different authors.

Like you said, comments are written by the programmer, for other programmers (including oneself) and are intended to communicate knowledge about the nearby code.

On the other hand, POD's purpose is a little more loosely defined. POD is usually written by the programmer, usually for the end-user of the code, usually with the purpose of being displayed separately from the code.

Notice I used the word "usually" a lot there.

What this suggests to me is that POD's purpose is probably being stretched a little too far. POD seems to suffer from the problem of being a documentation jack-of-all-trades - and master of none.
Read More 16 comments
Comments: 16