Re: With the Macrame macro system, Perl may now be a Lisp.
--- Guy Hulbert [EMAIL PROTECTED] wrote: On Fri, 2007-12-07 at 15:26 -0600, Jonathan Rockway wrote: BTW, I like the term failed experiment. Isn't everything a failed experiment? Should we remove CGI.pm from the CPAN because CGI.pm-style code is a failed experiment in writing web applications? Academic thinking again. CGI is highly successful. It's highly successful in the way that COBOL* is highly successful: for a while it was the main game in town and if you wanted to play, that's what you played. Now that CGI.pm is old and outdated (even Lincoln Stein has admitted that he'd write it differently today), we're largely stuck with it for legacy issues. Inertia is not the same thing success. Cheers, Ovid * I'm an ex-COBOL programmer and I know exactly what I'm talking about here. -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: With the Macrame macro system, Perl may now be a Lisp.
On Sat, 2007-12-08 at 00:30 +0100, A. Pagaltzis wrote: * Guy Hulbert [EMAIL PROTECTED] [2007-12-07 21:50]: CPAN is also littered with failed experiments. So is the fossil record. Good thing nature didn’t quit experimenting a billion years ago. Note that I understand your concern. But, I see two possible I am unconcerned. I just adjust my behaviour to deal with it. It's just a PITA when looking to see if something has been done before. outcomes: Macrame fizzles out, without getting much use; -- --gh
Naming convention for thin wrappers around C libfoo.so ?
If there's a libfoo.so and I want to create a perl module/distribution that's just a very thin wrapper around libfoo, what should I call it? LibFoo Lib::Foo Lib::foo Lib::libfoo libfoo SomeCategory::Libfoo ??? Tim.
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, Dec 07, 2007 at 03:45:26PM -0500, Guy Hulbert wrote: On Fri, 2007-12-07 at 14:28 -0600, Jonathan Rockway wrote: On Fri, 2007-12-07 at 10:44 -0800, Bill Ward wrote: Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. Hi. Nobody cares about your opinion on this matter. Many perl5 I do. I do, so that's at least 3 people. experiments have been quite successful; for example, Moose. macros? Don't use 'em. Don't like people using macros in CPAN modules? Don't use 'em. Trying to control what other people think and do will get you nothing except flames. I think you could be a bit more charitable in your interpretation of Bill's opinions. He certainly didn't manage to control you very well. Because perl modules can install their own dependencies, his concern is other people affecting *his* choices. One particular problem can be that if something you use adds a dependency on something else you weren't previously using, so you can reach the situation where upgrading to fix a bug will also bring in something new that you didn't want (for valid local policy reasons). Nicholas Clark
Re: With the Macrame macro system, Perl may now be a Lisp.
On Dec 6, 2007 7:22 PM, Eric Wilhelm [EMAIL PROTECTED] wrote: # from Bill Ward # on Thursday 06 December 2007 16:23: Cute experiment, but I REALLY hope nobody tries releasing useful modules to CPAN that depend on this... Cute comment, but I really hope nobody puts any stock in it. What skin is it off of your nose if a useful module uses something you're afraid of? Sorry to be snarky. What I was getting at was that I need to support Perl modules in a production environment, and experiments like this may be academically interesting but introduce levels of instability and inefficiency that are not consistent with that environment. If modules that we need to use are based on it, then I have a difficult decision as to whether the module is wotrh that risk just so Perl can be written in a more Lisp-like manner. Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. And from a Perl advocacy perspective, instead of making Perl more attractive to the hordes of Lisp programmers out there, I think we should be more interested in making Perl 5 attractive for real world uses.
Re: With the Macrame macro system, Perl may now be a Lisp.
On Dec 7, 2007, at 5:30 PM, A. Pagaltzis wrote: * Guy Hulbert [EMAIL PROTECTED] [2007-12-07 21:50]: CPAN is also littered with failed experiments. So is the fossil record. Good thing nature didn’t quit experimenting a billion years ago. mantra CPAN thrives because of the unfettered uploading of shit, not in spite of it. /mantra xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: With the Macrame macro system, Perl may now be a Lisp.
* Guy Hulbert [EMAIL PROTECTED] [2007-12-07 21:50]:
CPAN is also littered with failed experiments.
So is the fossil record. Good thing nature didn’t quit
experimenting a billion years ago.
Note that I understand your concern. But, I see two possible
outcomes: Macrame fizzles out, without getting much use; in the
grand scheme of things this is the most likely. In that case it
doesn’t matter whether it’s problematic or not. Or it takes off
unexpectedly, resulting in lots of people beating on it and
ironing out the worst kinks. In that case you can probably have
more confidence in it.
Most of the modules that give me the heebie jeebies just never
took off; I never had to install IO::All or Spiffy, say. So I
don’t worry, and neither should you.
--
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hack;
#Aristotle Pagaltzis // http://plasmasturm.org/
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, 2007-12-07 at 20:54 +, Nicholas Clark wrote: One particular problem can be that if something you use adds a dependency on something else you weren't previously using, so you can reach the situation where upgrading to fix a bug will also bring in something new that you didn't want (for valid local policy reasons). All I'm saying is that you can't control what other people do. People experimenting with Perl 5 aren't going to stop simply because someone on the mailing list says it might make his job harder. If dependencies are a big problem for your business, learn to fix the CPAN modules, or don't depend on them at all. I get upset when arguing about this because I have never had a problem, and I depend on a metric fuckton of CPAN modules. (I'm sure a nit has come up from time to time, but I just send a patch to the author and it's fixed forever.) BTW, I like the term failed experiment. Isn't everything a failed experiment? Should we remove CGI.pm from the CPAN because CGI.pm-style code is a failed experiment in writing web applications? Should we all stop using emacs because elisp's lack of static scope is a failed experiment? Should we forget about java because single inheritance is a failed experiment? Should we stop using Perl because TMTOWTDI is a failed experiment? To be clear, my point is that everyone thinks differently. What you consider failure many consider success. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: With the Macrame macro system, Perl may now be a Lisp.
On Dec 6, 2007, at 20:30, David Nicol wrote: I'm sort of stuck on how much records of line numbers of expanded rewrites to keep and how to encode them into the filename portion of the #line comment. In practice, debugging macros is maddening if you can't locate where the macro is being used and where it was defined. Sometimes the macro definition is at fault, and sometimes it's being used incorrectly. Filter::Template (source code filter for macros) does it this way: # line $line_number template $name (defined in $template_file at line $template_def_line) invoked from $filename Every line of the expanded template is preceded by a # line $invocation_line entry, which ensures that a warn() or die() messages are nice, but totally mucks with Perl's debugger. The problem there is that Perl stores the source code as an array using line numbers as offsets. Only the last line at a particular line number will display in the debugger. Around the time I wrote this, I kinda wished for non-integer line numbers. A 10-line expansion could have line numbers 14.1 through 14.10, with the original invocation as a comment on 14.0. -- Rocco Caputo - [EMAIL PROTECTED]
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, 2007-12-07 at 10:44 -0800, Bill Ward wrote: On Dec 6, 2007 7:22 PM, Eric Wilhelm [EMAIL PROTECTED] wrote: # from Bill Ward # on Thursday 06 December 2007 16:23: Cute experiment, but I REALLY hope nobody tries releasing useful modules to CPAN that depend on this... Cute comment, but I really hope nobody puts any stock in it. What skin is it off of your nose if a useful module uses something you're afraid of? Sorry to be snarky. What I was getting at was that I need to support Perl modules in a production environment, and experiments like this How do you support Perl modules in a production environment ? My preference is to not allow developers near the production servers and my clients (in theory) make the developers test the code on the staging server. Any modules available system wide, I build individually (or get from the o/s - debian). I try to avoid CPAN because of automatic dependency import. may be academically interesting but introduce levels of instability and inefficiency that are not consistent with that environment. If modules that we need to use are based on it, then I have a difficult decision as to whether the module is wotrh that risk just so Perl can be written in a more Lisp-like manner. Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. And from a Perl advocacy perspective, instead of TMTOWTDI. You are way way too late for this. making Perl more attractive to the hordes of Lisp programmers out there, I think we should be more interested in making Perl 5 attractive for real world uses. I'm switching to python wherever practical. DRY is much less chaotic. -- --gh
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, 2007-12-07 at 14:28 -0600, Jonathan Rockway wrote: On Fri, 2007-12-07 at 10:44 -0800, Bill Ward wrote: Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. Hi. Nobody cares about your opinion on this matter. Many perl5 I do. experiments have been quite successful; for example, Moose. CPAN is also littered with failed experiments. The great thing about Perl is you can choose what to use. Don't like True but it is also a weakness in some environments. macros? Don't use 'em. Don't like people using macros in CPAN modules? Don't use 'em. Trying to control what other people think and do will get you nothing except flames. I think you could be a bit more charitable in your interpretation of Bill's opinions. He certainly didn't manage to control you very well. Because perl modules can install their own dependencies, his concern is other people affecting *his* choices. Regards, Jonathan Rockway -- --gh
Re: With the Macrame macro system, Perl may now be a Lisp.
On Fri, 2007-12-07 at 10:44 -0800, Bill Ward wrote: Experimenting with the language itself should be reserved for new development such as Perl 6, not for trying to add yet more layers on top of Perl 5. Hi. Nobody cares about your opinion on this matter. Many perl5 experiments have been quite successful; for example, Moose. The great thing about Perl is you can choose what to use. Don't like macros? Don't use 'em. Don't like people using macros in CPAN modules? Don't use 'em. Trying to control what other people think and do will get you nothing except flames. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: [Request] File::Wordlist
humm... seems like we could/should make a module request list?
On 12/6/07, Chris Dolan [EMAIL PROTECTED] wrote:
Dear really-really-lazyweb,
Would someone please create a CPAN module that finds a wordlist on
the local computer in a cross-platform friendly manner, a la
File::HomeDir? For typical unix systems, that would be:
sub find_wordlist {
return '/usr/share/dict/words';
}
But it could be smarter and look for, say, /usr/share/dict/scrabble-
english first. For Windows, maybe it would look for MS Office or
OpenOffice files first.
For extra points, it could even parse those files if their not just
word + newline. For double extra points, it could download
additional dictionaries from the web (ispell, etc).
TIA,
Chris ;-)
References:
http://www.nntp.perl.org/group/perl.fwp/2007/12/msg4038.html
http://en.wikipedia.org/wiki/Words_(Unix)
http://packages.debian.org/sarge/all/scrabble/filelist
http://packages.ubuntu.com/dapper/virtual/wordlist
http://fmg-www.cs.ucla.edu/geoff/ispell-dictionaries.html
http://www.gutenberg.org/etext/3201
Paths:
/usr/dict/words
/usr/share/dict/*
/Applications/Firefox.app/Contents/MacOS/dictionaries/en-US.dic
/Library/Dictionaries/New\ Oxford\ American\ Dictionary.dict/
Contents/dict_body
/sw/share/aspell/*
--
benh~
