Slashdot Mirror

I've used pp and it worked well enough for me. Of course if you have binary modules you need to build them on a platform that's compatible with the intended destination.

http://search.cpan.org/~smueller/PAR-Packer-0.982/lib/pp.pm

Not only is this old, as many have pointed out, but there is even a Perl module (Audio::M4P::QuickTime) which has a dedicated function for that: CleanAppleM4aPersonalData.

Not only is this old, as many have pointed out, but there is even a Perl module (Audio::M4P::QuickTime) which has a dedicated function for that: CleanAppleM4aPersonalData.

I have no problem with the 2 years for regexes though that could have happened as an extension to perl 5 (i.e. really slow but at least the syntax would have worked). That is it could have been done in parallel in terms of design.

You're looking for Perl6::Rules, which has several annoying limitations that go away only when you build your own regular expression engine (though to integrate lexical variable handling per the Perl 6 specification, you also have to rework how Perl 5 handles lexicals and aliasing).

Any indication of how steep the curve is going to be for those latter bugs / features?

I can imagine that a few of them will be tricky, but Rakudo right now supports some tricky features, so the balance of easy/difficult to implement won't shift too much.

1. Sounds like treasure ( pearls)
2. Reinforces their need to hide their booty by making indecipherable maps to the treasure buried within
3. Incomprehensible mangling of commong symbols, like their english dialect.
4. It often requires the programmer to consume large amounts of rum as a coping mechanisim
5. New virtual machine Parrot named after favorite pet
6. Can use actual pirate language to program Acme::Lingua::Pirate::Perl

...when your machine can play it for you?

In today's modern lifestyle, it's hard to find the time to do everything. But now with SweeperBot, there's no need to give up minesweeper!

SweeperBot plays mineseeper for you! It's free, it's efficient, and it's open source! Simply download and double-click, and then spend your time doing more productive things... like playing freecell.

It's not very sexy, but it's fascinating and readable. I remember coming across it in Dillons bookshop, not knowing the name, and flicking through. Half an hour later, when I realised the time, I knew I had to buy it! Other books go into more exhausting detail (Knuth in particular), or cover a wider range (Knuth again!), or more modern ideas or languages. But Sedgewick is a great read, and I've been through it several times.

It covers all the basics (maths, searching, sorting, strings, graphs, and touches on FFTs and hardware and optimisation), and gives enough detail that you could go off and write some programs yourself. But more importantly, it explains them: how each algorithm works, what it's trying to achieve, how it behaves, and why. And it's because it explains the ideas so well that I'd recommend it. After every section I felt I'd learned something -- not because I had to, but for the sheer pleasure of understanding something new and interesting.

Other recommendations: Effective Java (a staggering amount of insight into the language), Thinking in Java (by someone who understands that language is more than just syntax), Deep C Secrets (again a pile of insight, interspersed with anecdotes and some rather off-the-wall diversions), Programming Pearls and More Programming Pearls (problem-solving in bite-sized chunks -- a little dated but still interesting). Plus I've already mentioned Knuth. K&R is well done, though narrow in scope. I find Design Patterns useful, but more for clarifying things I've already seen than for learning new things. I've never actually read The Mythical Man-Month, but people I respect mention it, so I'm sure it's well worth reading too!

Of course, times being what they are, especially in this field, a lot of interesting stuff is on-line. Some hat should go without saying hereabouts include the latest Jargon File, some of Eric Raymond's books, and more online documentation and archives than anyone but Google can cope with.

Other interesting articles include The Programmer's Stone, a guide to writing Unmaintainable Code, The Ten Commandments for C Programmers (annotated edition), Ken Thompson's Reflections on Trusting Trust, What Colour are your Bits?, and Guy Steele's Growing a Language.

ActivePerl has like a brazillion modules available for it.

Not really. ActiveState made bizarre PPM binary compatibility decisions, which meant that their version of Scalar::Util didn't include the XS components. As the 5.8.x series continued, more and more modules relied on that XS component, which meant that increasing amounts of the CPAN weren't available as PPMs. I don't know the exact figures, but it wouldn't surprise me if one-third to one-half of the CPAN were unavailable from AS's repositories.

(Did you know Alias is one of the CPAN administrators?)

Hey! Python can run Perl? That's awesome. Do you have a link for that? I'd love to be able to use my favourite language on what is by all accounts a great interpreter.

(If you want to run Python on Perl instead, you can. Perl: the choice is yours.)

You are correct. It is.

The CPAN testers was conceived back in May 1998 by Graham Barr and Chris Nandor as a way to provide multi-platform testing for modules. Today there are 2,653,748 tester reports and more than 400 testers giving valuable feedback for users and authors alike.

CPAN modules are probably better tested cross-platform than libraries for any other language.

This was solved in Perl a long time ago.

No, really!!

Quantum::Superpositions

Chess::Piece::Knight.

Perl is awesome!

The shim is called "perlgcc" and IIRC, it shipped on the companion disk. It is also here: http://search.cpan.org/~aburlison/Solaris-PerlGcc-1.3/pod/perlgcc.pod

BTW, I did have both the Sun compilers and GCC installed. Again, as I said in my OP, I probably could have recompiled an entirely new perl binary with GCC, but I shouldn't have to. Perl is basic tool. It should "just work".

Yes:
http://search.cpan.org/~abigail/Regexp-Common-2.122/lib/Regexp/Common/profanity.pm

For pretty much any useful stock problem solved by regular expressions, see Perl's Regex::Common module. A lot of these patterns are fiendishly complicated to deal with edge-cases properly.

Saw this one recently, by Andrew Savige. He did use a Perl module to generate the regex itself, but even so!

http://search.cpan.org/dist/Acme-EyeDrops/lib/Acme/EyeDrops.pm#99_Bottles_of_Beer

(I would quote the final result but /. won't allow that many "junk" characters.. let's hope that doesn't cripple this entire discussion.)

The problem is there really is no working "ODF Toolkit".

Are you sure about that?.

I know Perl is not considered sexy by the fad-hunting 'programmers' that haunt sites like this, but it works. And OpenOffice::OODoc is a very nice toolkit to programmatically create and manipulate ODF documents.

Mart

GUIs suck [...snip...] Scripting is your friend here.

If you're using some proprietary something-or-other that has a GUI but no command line interface, you could try wrapping it with a command line GUI test tool. I've done this with Perl and Win32::GuiTest. I'm sure your language of choice has something similar.

There's a module in CPAN for this. It rips out the images and runs them through Tesseract. It's worked well the few times I've tried it. Certainly well enough for search engine indexing.

Also, my understanding of the "dark web" concept was that it refered to sites that had no links going to them, so no spiders are able to access them. I'm not seeing how any of this would fix the "problem".

The only news here is that Google doesn't already index form content in drop down boxes and selection menus. Seems that would have been a fairly obvious extension.

yeah, but as implementing an OpenID consumer is such a doddle, I'm sure CmdrTaco could read the example perl docs and slap it into the authentication system on /. in 5 minutes.

The tricky bit is tying your existing user to your openid login.. maybe it'd take him 10 minutes :-)

Oops! I love Perl, btw.

'Oops'? Don't you mean D'oh ?

* Audio language selection (how do you write code to tell if the guy is speaking in french as opposed to spanish?)

Convert speech to text then use that text to guess the language (i.e., use a tool such as this).

It may be more trouble than it's worth though... :)

Parrot is a virtual machine that pre-dates .NET and has many of the similar objectives. Probably the reason that no-ones put PPI and .NET together into something like IronPerl is that there are more interesting projects around, like JIT conversion of .NET bytecode to parrot bytecode. Then who needs Mono :-).

You whine too much.

There's more than one way to do it.

If you want to do joins on data that you have in CSV files, just insert them into an SQLite database first.

XML/XPath support: XML::XPath

If you want to code .Net, use C#. If you want to use CPAN, use Perl. The two languages are getting more similar all the time, with each release of C# getting better.

and you end up with really ugly code that isn't very maintainable

Why? I've written plenty of OOP Perl, and it's no more or less maintainable than any other language. Well, assuming you aren't a moron, anyway.

The problem with the Perl 5 implementation of OOP is that the programmers sees all the OOP plumbing (the fact that an object is (usually) a hash).
However this is fixed by Moose.pm (a Perl 5 module) and Perl 6.

You can follow the development of Rakudo, the implementation of Perl 6 on the Parrot virtual machine, on www.rakudo.org. Not yet ready for general use, but already good enough to discover the language.

Suits who pick the technology are usually wrong, and seldom obeyed.

Strawberry Perl and ActivePerl are both pretty nice packages. Many Win32 modules like Win32::OLE, Win32::API, and more in the Win32 and Win32API namespaces are perfectly usable.

The places most qualified to answer specific questions are probably comp.lang.perl.moderated (or maybe comp.lang.perl.misc) and Perlmonks. I don't know too much first-hand about PerlGuru, but they do have a section specific to Win32 programming with Perl and I've heard some good things.

Suits who pick the technology are usually wrong, and seldom obeyed.

Strawberry Perl and ActivePerl are both pretty nice packages. Many Win32 modules like Win32::OLE, Win32::API, and more in the Win32 and Win32API namespaces are perfectly usable.

The places most qualified to answer specific questions are probably comp.lang.perl.moderated (or maybe comp.lang.perl.misc) and Perlmonks. I don't know too much first-hand about PerlGuru, but they do have a section specific to Win32 programming with Perl and I've heard some good things.

I have no opinion about the lack of of a finished and well distributed Perl6, but you are completely wrong to say that CPAN is not getting any more useful additions. Since 2000 the number of cpan modules has grown from about 5,000 to 14390 (you can see the count and other stats, such as the number of authors registered at http://cpan.org/) Also, some of the code I've seen in the past few years is among the best. For example Moose, (http://moose.perl.org/) is a full on meta object stack for Perl, and makes writing very clear OO code trivial.

To answer the general question, "Where is IronPerl", I guess I have to say that most people in the Perl community are pretty die hard Unix people so unless we are getting paid to work on Windows supporting it is an afterthought.

Also, the CPAN philosophy is to try to write stuff that runs everywhere, and an IronPerl would be something specifically for Windows, so that's not going to be popular.

I'm not sure what you mean by lack of XML/Xpath support. There's probably a 100 modules on CPAN dealing with this.

To be honest, I am not familiar with DBI::CSV, but I really don't see not being about to do joins on a text file to be a major defeat for a language. If you could give me an example of what you are trying to do I'd be happy to comment.

In Perl there are modules for everything.

I like them, cheap and reliable, plus there's a CPAN module to interact with them. Personally I would also investigate running your own DNS servers, with Bind a simple run of sed through the text config files and a restart and you're done.

I'm not so sure about the quality of random perl fragments from google searches.

I found the perlipc docs quite useful - if you're not just writing throwaway scripts you are going to have to handle signals and exceptions.

http://search.cpan.org/~rgarcia/perl-5.10.0/pod/perlipc.pod

Then there's also:
http://faq.perl.org/

Some people use the perl cookbook - http://oreilly.com/catalog/9780596003135/

So far I haven't really had need to look at that much.

Specifically search.cpan.org.

Sometimes I browse around to see what I might come up with for new modules. The documentation is awesome because not only is it formatted, but you also can link directly to a specific version, see the installation test report for various OSes for that version, see submitted bugs, other comments and module dependencies.

The most annoying thing is having to go on the web to find a doc. PHP is horrifying enough and then you read the docs and find all the exceptions to whatever rule (and the bugs) in the comments.

For Perl:
perldoc -f [function name]

Or perldoc [Module::Name] (also man Module::Name works on most Linux distros)

Also on Linux, 'man perl' gives a list of a whole ton of man pages that give you specific information on regexes, objects, references, syntax, variables, etc.

And if you have to have it in a pretty web interface it is indeed all online
(module docs are as well)

Say what you want about Perl but it has tons of useful modules and it is very well documented.

p5p uses a tool called perlbench to check performance periodically. It doesn't cover every combination of language features, but it's a good baseline.

One way to mitigate all the nuttiness that lazy developers put into Perl is to take the suggestions from a script called 'perlcritic' on the -harsh setting.

Doc for Perl::Critic

On our team, we have developers that are hackers to college interns. This stops the hackers from writing illegible punctuation explosion code and stops interns from making common mistakes.

In addition, the level of expression (i.e. TMTOWTDI) means in practice that highly varying programming styles occur throughout large, long-lived bodies of code. As a result, significant Perl-based business applications tend to become hard-to-maintain hairballs of divergent style and subtly variegated concept.

Very true ... which is why Perl::Critic was created. While I suspect this isn't available for other languages, perl's flexibility in this case provides both the problem and a solution.

a reason _can_ be: http://search.cpan.org/

Which of the many object systems for Perl have you used?

There are regular, ordinary, blessed hash objects. Then there are many more.

You might want to look up Moose and Object::InsideOut on CPAN Search.

There are also Object::Declare, Object::Prototype, Class::Dot, and others which are less widely used.

In Perl, TIMTOWTDI, and you can probably find one that you like if you're willing to look. Just be careful who else's code you have to maintain, because they might have taken TIMTOWTDI too far and use a way that's better left not done.

In perl I doubt the author could even say what his/her code written a couple of months ago does without studying it for a while.

Authors not remembering what code does is not a perl problem, it can happen in any language. Perl has tools to help stop this from being a problem, such as perlpod and perldoc. The programmer can put documentation and notes into the program near the code that needs documenting. Then if a programmer needs to know a couple of months later what code does, they can simply read the fine documentation, which will be right there in the files.

Here's a simple example of some perlpod. Please see man perldoc and man perlpod for more information. You can use the same pod to document the file, generate man pages, and generate html.

=head2 some_func($x, $y)

Returns the result of the fabulous function.
Long description of what the function does. Blah blah blah.

=cut

sub some_func
{ my ($x, $y) = @_;
# do something here
return 42;
}

In perl I doubt the author could even say what his/her code written a couple of months ago does without studying it for a while.

Authors not remembering what code does is not a perl problem, it can happen in any language. Perl has tools to help stop this from being a problem, such as perlpod and perldoc. The programmer can put documentation and notes into the program near the code that needs documenting. Then if a programmer needs to know a couple of months later what code does, they can simply read the fine documentation, which will be right there in the files.

Here's a simple example of some perlpod. Please see man perldoc and man perlpod for more information. You can use the same pod to document the file, generate man pages, and generate html.

=head2 some_func($x, $y)

Returns the result of the fabulous function.
Long description of what the function does. Blah blah blah.

=cut

sub some_func
{ my ($x, $y) = @_;
# do something here
return 42;
}

There's one big diifference, however: python is a well-designed, highly structured language. Perl sort of grew organically from a couple of scripting languages, and had OO pasted on later.

You can argue that Perl's OO is pasted on, which is somewhat true, but that doesn't mean that it isn't powerfull. Try Moose. Certainly OO is a thing being fixed in Perl6. Until that is available use Moose or try to realize that OOP isn't the only form of programming.

Saying indirectly that Perl5 isn't well designed, just pisses me off. It grew organically, but changed during these years and got refined. If you keep to best practises, Perl code can be as readable as any language and even better as it is more powerfull.

I stumbled upon brackup not too long ago, trying to solve a similar problem.

I believe brackup solves (1) I believe they want to support windows, and test on it, You can put the script + cygwin on a usb drive (2) (Dunno if it has an ftp plugin, but you can snag a perl dev to add that; it supports amazon s3, and sftp at least), (3) supports incremental updates, (4) does that too.

http://search.cpan.org/~bradfitz/Brackup/

Svn trunk and his release here:

http://brad.livejournal.com/2205967.html

Brackup is a Perl script for doing incremental backups. It's a bit like JungleDisk (see other posts here), except the client is freeware.

While JungleDisk uses S3 for storage, Brackup has the option to store on S3 or on a filesystem. You basically end up with (optionally) encrypted blocks, referenced by keys.

I've taken a peek at the code. You wouldn't need to be much of a Perl guru to hack in FTP support if that's what you want.

This isn't an endorsement for Brackup - I don't use it myself, although I've given it a trial run, been impressed, and may well take it further when I get around to it.

The CPAN module Log::Log4perl is a great tool for logging -- it means you can stick in plenty of debug statements, and dial them up for debugging, then dial them down in Production.

This module uses several message levels; in descending order of importance they are FATAL, ERROR, WARN, INFO, DEBUG and TRACE. It's possible to log messages to files, a screen, or even to an E-Mail message.

The real strength of this method is that you don't need a 'debug' version of the code -- all configuration is done externally, which means you can turn logging on for a Production problem, run your test, and turn it off again, and look at the log files off-line.

DBIx::Class for the win.

Actually, Perl has private members, accessor generation and a lot of other features, if using the right module (or one of the many others, TIMTOWTDI ;-).

http://search.cpan.org/dist/RT-Integration-SVN/

Thats OK, we have Storable.

Hear hear! I still can't understand why Perl is downplayed as a language. It has a great set of builtin functions, an incredible community (see CPAN and Perl Monks), can be written in a style that looks and functions exactly like C, and above all, its performance is pretty good.

As noted, it can be used as C on steroids: built-in automatically growing/shrinking arrays, hashes (dictionaries to some), and completely automatic garbage collection. The syntax, being eminently flexible, can be made to look damn similar to C's.

Beyond that, it gives you much more expressive power. In my opinion, in some situations it can be much more meaningful to say something like return unless $t > 0 versus the equivalent if (!($t > 0)) { return; }. Subtle things like that allow code to flow much more freely, and that's barely even scratching the surface.

Perl gives you room to grow well beyond C (without requiring it, of course). Functional programming techniques abound since Perl's array data structure works equally well as a Lisp-like list. It has builtins such as map and grep and a standard bundled module that provides reduce, so virtually any functional programming task can be implemented easily.

With everything it's got going for it, sometimes I'm left scratching my head as to why it's not used more widely. A couple of bad programmers write line noise and suddenly the whole reputation of the language is at stake. A sad thing indeed.