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 ]

ggoebel (893)

+ -

  Comment: Larry, chromatic, etc ... are more like the Carlos (Score 1) on 2010.06.15 15:15

by ggoebel on 2010.06.15 15:15 (#72082)
Attached to: Perl 6: True-Believer Syndrome

I found this last bit amusing. -I assure you Larry, chromatic, etc. are not like Carlos. I.e. they are not fictitious 2000 year old spirits...

Perl 5 continues to be actively developed and maintained. Rakudo Star is being readied for release (an 80+% complete Perl 6 implementation). And counting the number of active developers, commits, and monitoring IRC channels, it looks to this observer that Perl 6 projects are ramping up.

If Larry and company are having fun designing and implementing a new language which attempts to infuse new ideas and life into Perl 6... Why should you care? Why should I care that you care?

A question for you Ank. Why bother railing against Perl 6? Why are you so invested in taking it down a notch? Are you simply a troll? Are you only interested in stirring the pot? Or do you have a positive constructive destination in mind for these rants?

Read More 1 comments
Comments: 1
+ -

  Comment: checking your ironman status (Score 1) on 2010.03.02 14:12

by ggoebel on 2010.03.02 14:12 (#71741)
Attached to: I'm a snowplow

Should be documented somewhere shouldn't it?

Substituting the appropriate gender and (nickname or fullname)... this should work:

Read More 5 comments
Comments: 5
+ -

  Comment: easier install/maintainance of Perl distributions (Score 1) on 2010.02.09 14:29

Use cases...
  • End user can download and execute an application implemented in perl application without knowing what Perl is.
  • Developer can easily add, remove, and upgrade Perl modules without affecting system/os Perl installation. (Default to having CPAN install to a user_perl overlay?)
  • Systems Administrator can easily add, remove, and upgrade site_perl without affecting developer and/or application overlays.
  • Developer when releasing perl application has easy way to bundle all current differences from the installed vanilla/core Perl distribution into application distribution. I.e. option to use pre-existing perl w/ application overlay or standalone perl app install.
  • A best practices / EPO / Modern / Strawberry / etc. CPAN bundle of modules which work on *NIX, Windows, OSX _AND_ which can be installed and upgraded without requiring external development tools. I don't care if this requires a pure perl implementation for all dependencies... or a way to ship binaries. -So long as we don't require the installer/developer to have or use a C/C++ compiler, etc.

A common thread in these use cases is that different module versions should be able to co-exist in an installed perl distribution. The most common cases are probably system perl, developer perl, and bundling an application's dependencies.

How to add this complexity without making it a burden? Allowing us to keep around all versions of modules? Have different levels of overlays beyond site_perl?

However implemented... It would be nice if the solution didn't require completely separate Perl installs or a revision control system.

Read More 62 comments
Comments: 62
+ -

  Comment: Re:Good start, here's a few more ideas... (Score 1) on 2009.08.05 17:04

by ggoebel on 2009.08.05 17:04 (#69890)
Attached to: The "Marketing" BOF
Voting for leaders is a bad idea. Let the natural leaders emerge by proving themselves through act and deed.
Read More 8 comments
Comments: 8
+ -

  Comment: Re:Don't just market the language (Score 1) on 2009.07.28 17:47

I think you're hitting the nail on the head.

Everything else sets the stage... but without the killer app, we can't attract the magpies.

Then again, a killer app which attracts developers... won't be able to retain them if the support infrastructure is a maze of twisty passages all different

We need it all. And if somebody(s) can chart a course... then perhaps we can each scratch an itch that gets us there.

Read More 36 comments
Comments: 36
+ -

  Comment: The known unknowns, the unknown unknowns, ... (Score 1) on 2009.07.28 12:33

I think we could use some good blogs on marketing and visual vs. functional design, etc. A website dedicated to grinding this particular ax would welcome. Articles in a well read online publication would be excellent. Ignorance can be cured.

Some of what needs to be done, may appear as simple window dressing. But a consistent style guide and resources for building Perl websites that would like to use it would be great.

There are a lot of unorganized efforts out there. Things like making it easier to install libraries and applications as a user with limited rights. And many module maintainers are rewriting their OO code making Moose the defacto standard.

This is fairly typical for open source projects. But Perl could definitely use some cat herding public health policy person(s) to help us all stay on top of best practices.

As a part-time Perl programmer, my Perl is a mismatch of old and new practices. With all the Perl resource scattered about, I never know where to go to find a rational discourse on current best practices and recommended libraries.

Alias, thank you for all your efforts. Dare I say, that I've heard Perl needs a pumpking...

Read More 36 comments
Comments: 36
+ -

  Court ruling on violation weakens Artistic license on 2007.08.26 5:53 ggoebel

Submitted by ggoebel on 2007.08.26 5:53
There's story on Slashdot about a recent court decision concerning the Artistic license. The decision interprets the violation of the Artistic license as breach of contract instead of copyright infringement. I.e. the licensor in this case has not been allow to get an injunction on the licensee to prevent them from continue to redistribute their code.

The slashdot article references Law & Life and the JMRI project page

Looks like we may all be thanking Allison Randal and her efforts developing the Artistic 2.0.
  • Could the same thing happen under the Artistic 2.0 or Will further revisions to the Artistic license be required?
  • Should adoption of Artistic 2.0 wait until Perl 5.10?
Read More 0 comments