Re: What are Perl 6's killer advantages over Perl 5?
Hi, On Tue, Aug 11, 2015 at 07:12:00AM -0500, Tom Browder wrote: I have seen several lists of new Perl 6 features (versus Perl 5) but they all seem to be lists that intermix features with varying degrees of value to ordinary Perl 5 users. If one wants to sell long-time Perl 5 users (already using the latest Perl 5, Moose, etc.) on the value of Perl 6, what should be on the important feature list? For me, stronger typing, named subroutine arguments, better classes and namespaces, object methods, and eventually better concurrency and compiled program persistence are among goodies long awaited. Thanks. -Tom The reason for my request is to help with a better introduction in my modest draft tutorial on converting Perl 5 to Perl 6 code at the Perl Monastery. I am comfortable with the example code I use there (which is not currently intended to showcase new features), but I am getting several comments on why one should even bother with Perl 6? In talking to Perl 5 people about my Perl 5 to Perl 6 docuentation, trying to get some feedback on it from people who aren't already doing Perl 6, I get this question a lot. So, yes, some kind of document saying these are reasons Perl 6 is actually useful would be very helpful. Just make them look at Perl6 source code. E.g. on rosettacode. Someone who doesn't see how wonderful Perl6 is, is a lost soul anyway. :) - Fagzal
Re: rakudo-current loop 2-3 orders of magnitude slower than perl 5?
Hi, I think featurewise Rakudo is now at a point where it could already be use for some serious work. Surely many things are missing, but (for me) the two most important things - good OOP support and types - are already in. And the syntax is just lovely :) (I think I have a syntax-fetish... :)) However, performance is an issue. I would not mind running into bugs, writing some extra code to work around missing stuff, etc., but right now it is just hard to find any projects (for me - YMMV) where performance would not be a blocker. Right now the only thing I can use Perl6 for is to learn Perl6, and that's a problem, because when I sit in front of a computer, learning is the only thing I do not get paid for :) For a long time, people I talked about Perl6 all feared that it would never be ready. Now concern shifted to will it ever be fast enough? And I think it's not really about Rakudo, but about Parrot. Unfortunately I am not a Rakudo, neither Parrot hacker, but as I understand, there are features in Rakudo which are implemented using only a few lines of code. You cannot gain 100x speed difference optimizing, say 7 lines, so I must assume it really is Parrot which needs a lot of love, and there aren't too many people who can/could hack on Parrot. That sometimes feels scary. I very much agree with Patrick: an order-of-magnitude speed difference compared to Perl5 is kind of the point where many will just stop caring about performance and start using Rakudo/Perl6. Actually I expect a significant increase in the number of new Perl6ers at around 100x slower. (That, and the 10 most important Perl5 CPAN modules ported to Perl6 :)) I think it would be nice to have some sort of a performance-tracking page, with just some very basic Perl5 / Perl6 code and very rough measurements. If noone will do that, I will :) - Fagzal
Re: Perl 6 fundraising and related topics.
[...] To that end, I'm soliciting: (1) your suggestions for preparation, (2) your ideas for proposals, and (3) your reasons why the Perl 6 ecosystem (including Parrot and CPAN6) is one of the world's greatest and and most extremely leveraged causes (technically, economically, and socially). I'll also put whatever fundraising-oriented material I come up with on the Perl 6 wiki, to help and encourage others along similar lines. I'd like to raise the question what to do with the money, assuming that you can acquire some. I see two possible route: 1) Let The Perl Foundation decide what to do with the money advantage: they already have a comitee (is that really an advantage? ;-) disadvantage: they seem to think that Perl 6 on Parrot is _the_ and the only way to go. (There's nothing wrong with rakudo and parrot, but Perl 6 is, by definition, a language. And it should have multiple implementations) Should it really? I mean: is the time right for that now? It's really hard to define what the community wants: noone can speak on behalf of the whole community (and the community has many ideas about things :)) However, and strongly IMHO, what most Perl users want is very simple: to have a not-too-slow Perl6 implementation that runs most of the current Perl6 specification - without too much bugs. Maybe the Perl Foundation got some people who can decide what we need to achieve that - someone must make a decision where the money should go anyway. Surely it is very nice to have many implementations (we have seen how much helpful the Pugs project was to help Perl6, for example), but could that happen (or: be sponsored) *after* we have *one* that is fairly complete?? After some time, one imlementations will emerge and become *the* implementations anyway. What I would like to add is that IMHO this time implementators should be sponsored. That is: those who hack and those who answer their questions on how to hack. :) I also think that different Perl groups all around the world could be responsive. Let's contact the gazillion perl lists and say: ...if you like Perl, please give $10 to the \Let's have Perl6 now!\ foundation! I would, and I will personally send anyone to /dev/null who would not! :) - Fagzal
Re: Perl 6 fundraising and related topics.
[...] Should it really? I mean: is the time right for that now? Let's ask the other way round: Is this the time for only one implementation? And who decides that it's the one based on parrot? What happens if parrot turns out to be a dead end? (very unlikely, but possible). Let's give some $$$ to say 3 implementations, see what they come up in a month. Lets mupltiply their 1/CPU-time with #of tests passed :), and the winner gets the rest of the money. It's really hard to define what the community wants: noone can speak on behalf of the whole community (and the community has many ideas about things :)) However, and strongly IMHO, what most Perl users want is very simple: to have a not-too-slow Perl6 implementation that runs most of the current Perl6 specification - without too much bugs. I also think that many perl people also want a good Perl 6 specification. I agree. On the other hand, I would be very happy if current implementations could pass 25% of the current specification. And different implementations help to explore different part of the specs. That also helps rakudo, if the specs are well covered by other implementations and are therfore much stable and really implementable. How about sponsoring some implementations, but give special attention to the most promising one? If you argue that most people want an implemenation that covers large parts of the specs, the most logical step would be to boost pugs development. It's the most advanced implementation by far. And I do believe that it can be sped up if you really want that. I don't know Haskell and the structure of Pugs so I cannot comment on that - however, I have some doubts. And speed *is* important: I don't think we can expect people to start using Perl6 if it runs even 2x slower than Perl5. If Pugs was really up-to-date (I mean: feature complete), only slow, I would probably use it to learn Perl6, because Perl6 is just lovely. I would not build something on it, though. So where's that pro parrot bias coming from? IMHO people like the idea of Parrot. It just.. makes sense. It's been around for quite a while. There are releases every month or so. There is a mod_parrot. These things. Surely it is very nice to have many implementations (we have seen how much helpful the Pugs project was to help Perl6, for example), but could that happen (or: be sponsored) *after* we have *one* that is fairly complete?? After some time, one imlementations will emerge and become *the* implementations anyway. Oh will it? Just like we have one C implementation? Or one Forth implementation? Or one Lisp implementation? Can we add PHP and Perl5 to the list? ;) What I would like to add is that IMHO this time implementators should be sponsored. That is: those who hack and those who answer their questions on how to hack. :) Aye. And perhaps the ones who write the specs, if they want/need it. I meant that, too. I also think that different Perl groups all around the world could be responsive. Let's contact the gazillion perl lists and say: ...if you like Perl, please give $10 to the \Let's have Perl6 now!\ foundation! I would, and I will personally send anyone to /dev/null who would not! :) I don't know if that's a good idea - sadly many of them have the perception that Perl 6 is vapour ware. I guess I have more trust in people than you do. :) I know that the company I work for would never give a dime to any foundations, but I would. And I *own* that company :) That's because a company is always a business, but a person can be an enthusiast. Anyway: I don't know anything about fundraising, so maybe I shouldn't say a thing... I just say it might worth a try. People would help to convince other people. Once again: I would. My idea would be to ask big companies that use perl (for example amazon) if they would sponsor some of the development. Are there other organisations that routinely sponsor open source software? Can't we just go to Google and say we will use Yahoo if they don't give us some money? :) And if they don't, we tell everyone! ;) How about just looking at the sponsor logo-s on the webpages of different OS conferences? There should be plenty, and could give some ideas. (But there really should be something you can *show* to them. I mean at least *one* webpage on Perl6 which is not outdated :) ) YAPC organizers should have some ideas, too. - Fagzal
Re: Perl 6 fundraising and related topics.
[...] I was there at the workshop too. You cannot count me in into being biased against Perl 6. Only biased that it takes so long :-). I know, and there were some others (like Herbert aka lichtkind, who writes and maintains the German Perl 6 wiki pages) with the same opinions. But the general atmosphere there was rather anti Perl 6, and the recent discussions on the wsinfo mailing lists show that all too clearly. It's really not a surprise. Perl5 is not broken: IMHO many Perl5 programmers just wanted some little (erm...) things like a less hacky OO implementation, better function parameters and types, things like that. Perl6 promised these and much-much more, so people were happy. There were news, ideas, Parrot hacking, etc... and people got bored. Basically nothing happend for *years*. That is: many things happened, there is a nice specification now, brilliant features, etc., you all know - but for Average Perl Joe, there is just nothing there. Average Perl Joe needs this: perl6 hello_world.pl That's why I am rooting for rakudo: there is progress, or so I figure, and I can ln -s rakudo perl6 anytime :) Once you can point people to some targzipped source or an RPM or something like that, and 10 minutes later they can indeed write the above line, they will not be anti-Perl6 anymore. (I mean if they will be anti-Perl6 after that, then we can just close this list and everyone can just go home.) - Fagzal
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Randal L. Schwartz wrote: A == A Pagaltzis [EMAIL PROTECTED] writes: A * Randal L. Schwartz merlyn@stonehenge.com [2006-09-20 19:30]: Fagyal == Fagyal Csongor [EMAIL PROTECTED] writes: yet I never needed those HTML generating methods. You've never made a sticky form then. A False dilemma. You can create sticky forms conveniently without A using CGI.pm’s HTML generation stuff. You can use HTML::Template, A HTML::FillInFrom, HTML::Widget, CGI::FormBuilder… should I go on? A C’mon merlyn, you’ve been around long enough to know about CPAN A and realise that your statement is transparently fallacious. However, HTML::FillInForm, HTML::Widget, CGI::FormBuilder were *not* in core. CGI.pm was. One stop shopping. Easy to describe to people. We need the same thing for Perl6: If you're going to do simple web stuff, please use MUMBLE module. And MUMBLE better have tight integration of param processing and sticky form generation, as well as good header generation for cookies and redirects. In other words, at least two thirds of what CGI.pm does for me now. And MUMBLE better be included *with* Perl6. Without that, people will *hand code* that stuff, and get it wrong, and we'll get the reputation of Perl6 being horrible for the web. I am in favour of different bundles. Then you can, for example yum install perl6-base or yum install perl6-web or yum install perl6-everything You know what I mean. The diff between perl6-base and perl6-web is a bunch of (CPAN6) modules. - Fagzal
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Randal L. Schwartz wrote:
Fagyal == Fagyal Csongor [EMAIL PROTECTED] writes:
Fagyal As a side note I also have to add that I really dislike the
Fagyal html-functions CGI.pm currently has. Creating the representation is
Fagyal the task of the designer, not the programmer. It's almost like echo
Fagyal in PHP :))) I used CGI.pm with simple cgi scripts, with Apache::ASP,
Fagyal mod_perl and FCGI, I used CGI::Cookie, etc. yet I never needed those
Fagyal HTML generating methods. To me, imhoit feels wrong that they are
Fagyal there/imho.
You've never made a sticky form then.
Erm... what makes you think so?
Not with CGI.pm, but I use HTML::FillInForm for the basic cases (which
is simply a per-page config parameter in my framework, and which has the
advantage of using simple HTML markup without any coding), and my own
module (PET::Filter::UtilXmlMap) for more comples cases when forms are
pre-populated from DB. E.g.:
ehtml:bodySelect array=subst.pages name=page selected=QUERY.page /
(Note: this generates [% Util.ehtml.bodySelect('array', subst.pages,
'name', 'page', selected, QUERY.page %] at compile time.)
I think JSP tag libraries had a too strong effect on me :)
- Fagzal
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Ian Langworth wrote:
It sounds like the name of HTTP is more appropriate:
HTTP::Request
...uri, pathinfo, params, method, headers, etc.
HTTP::Request::Session
...adds to HTTP::Request to provide session() method
HTTP::Response
...response code, content, headers, etc.
HTTP::Response::JSON
...extends response.write() to encode JSON
Maybe CGI.pm could adapt these to the CGI environment and ecapsulate
their functionality.
Maybe it's too servlety.
It is :)
It is probably the *proper* way, but definetely not the *efficient* way.
You rarely do real HTTP handling when you use CGI.
A general, simple CGI handling module fits into 200 lines, including
POD. Imagine like
sub parseQueryStupidAndWrong {
my $self = shift;
$ENV{'QUERY_STRING'} || return {};
my @pairs = split(//, $ENV{'QUERY_STRING'});
my %query;
foreach my $pair (@pairs) {
my ($key, $value) = split (/=/, $pair);
$key =~ tr/+/ /;
$key = whatever::url_decode($key);
$value =~ tr/+/ /;
$value = whatever::url_decode($value);
if ($query{$key}) {
$query{$key} .= , $value;
} else {
$query{$key} = $value;
}
}
return \%query;
}
You don't really need more. IMHO a CGI module
parses/preprocesses/decodes/etc. all incoming parameters (POST, GET,
COOKIES), and that's it. It might give some useful other routines (e.g.
url encoding / decoding, various ways to mix GET+POST, set content types
more easily, etc.), but other than that, it should be very lightweight
and easy to use.
- Cs.
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Erm...
Sorry for the bandwith usage again, but what about something like
class CGI
is CGI::Base
does CGI::ParamParser
does CGI::HTML
{ ... }
?
To make CGI.pm kind of backward compatible, but separates the layers.
(Please excuse my bad syntax/semantics.)
- Fagzal
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Juerd wrote: [...] Fagyal Csongor skribis 2006-09-20 15:43 (+0200): Inefficient was probably a bad choice of word. I would rather say: I would not like to see Perl6's CGI.pm as a monster module, which has one part everyone uses, and one hundred other parts that some uses, because I feel those parts should be put into other modules. Perl 6's Web toolkit, even with all these classes, is likely to be much lighter than Perl 5's CGI.pm with :standard. I guess that's one of the reasons we are heading from 5 to 6 :) But note that especially if it is a well designed bundle of classes/roles, you can pick exactly those things that you need, and leave all others out. That's part of the reason why you should separate things. And here is another reason :) [...] If we talk about nicely structured OO, I can see a few ways: - CGI.pm include something like CGI::HTML, to get rid of the HTML generating part, or maybe even separating CGI::HTML and CGI::Request s:g/CGI/Web/, please! mod_perl has nothing to do with CGI (except perhaps for its compatibility syntax), and neither does HTTP::Daemon. We should write generic code, suitable for any implementation. I'm thinking of: Web::Init::CGI # Initializer for CGI requests Web::Init::FastCGI # Initializer for FastCGI requests Web::Init::ModPerl # Initializer for ModPerl requests Web::Request# Request objects Web::Response # Response objects Web::Session# Session objects Web::HTML # HTML generation Web::Util # HTML-entities, URI-encoding, etc Web # utility module that mostly loads other modules Hmmm. A very sound idea. Reorganising the CPAN namespace :) (This CGI/HTTP/LWP/HTML/etc. got a bit confusing as it grew.) I would say, maybe add Web::Tools::* so that others can add various useful (and not that useful) modules without mixing up everything. And maybe expand Web::HTML something like: Web::Markup::HTML Web::Markup::XHTML Web::Markup::WML etc... But that's might as well be too much. So is Web::Init::* class supposed to be selected by Web, and Web::Init(::*) used by e.g. Web::Request Web::Response, so it all becomes transparent? Yes. I'm talking about a web development toolkit, that does at least what CGI.pm did, and not about CGI as a namespace, because I think that's an incredibly bad thing anyway. I absolutely agree. - Fagzal
Perl6 style-guide
Hi, I was wondering if there is (or there should be) a documentation on how to elegantly write Perl6 code. I am afraid that when I will be starting to write Perl6 code, it will be too much Perl5-ish, and I will end up rewriting my code in every 3 months because I hate when my code is not elegant (at least to my own standards). I was wondering that some - maybe @Larry - already have (mosf ot) Perl6 in their heads, so they could create such a document/recommendation before Perl6 gets used widely, and the coding style gets distorted. Or shall we just leave this to the community? Maybe this documentation shouldn't/can't be written yet? Shall we let Perl6-style grow from usage in 1-2 years, and create a guide like this then, when things mature? - Fagzal
Re: the CGI.pm in Perl 6
Randal L. Schwartz wrote: The thing that CGI.pm does is put in one place everything you need for a simple web form. And there's an amazing number of applications for this... putting a contact us page on an otherwise static site comes to mind immediately. Sure, if you're building a complex shopping cart application, you're gonna reach for Jifty or Catalyst, or at least roll your own with Template Toolkit or Mason, and you'd be silly to use either CGI.pm's parsing or HTML generation in those cases. You seem to be forgetting the case in the middle - a small dynamic site. IMHO that is: most sites. My weapons of choice for that are CGI.pm to parse requests and Template Toolkit to stuff the relevant content into templates. That's why I use CGI::Lite - no fancy HTML, only a lightweight module with themost important features. (Gee, I am emitting WML sometimes!) And let me add this as a side note: http://www.w3.org/CGI/ IMHO a module should do what its name stands for. Surely, when I do something with CGI, I also do HTML generation in 99% of the time. But as the matter of fact, I also use DBI in 99% of the time, so why not put DBI into CGI.pm, too? ;) [...] But don't throw out the simplicity of CGI.pm's basic task handling: parsing the incoming parameters (including file upload), and generating sticky forms and other common HTML elements. That's two tasks. It should be two modules. Absolutely. I suppose you could argue that generating FORM tags specifically and all their baggage like INPUTs might fall under its remit (they are, after all, what generates the fancy requests that are CGI's bread and butter), but generating H1 tags is most definitely not anything to do with CGI. Also consider that handling the input part of CGI is very straightforward. No matter what system/language you use, you basically do the same thing (parse/access GET/POST, the ENV variables, etc.) On the other hand, handling the output is much more dubious - besides setting the content type on some other headers, there are dozens of ways to handle/mangle the content you output. Perl5's CGI.pm provides a way, but that is IMHO just a legacy API Perl6 has nothing to do with. Basically everyone who use CGI.pm use -param() - but only a few use -h1(), for example. (IMHO if something beyond CGI input handling must go into CGI.pm, then that is cookie handling - but that's another story.) Just my two cents. - Fagzal
Re: OT: my wiki syntax is better than yours
Hi, I have never understand this my wiki syntax is better than yours thing. It's like my templateing engine is better than yours. I feel like which should have wiki.conf with : ... syntaxhandler = SuperbPerl6Wiki::Syntax::MediaKwikiMikiBiky ... That shall please everyone. :) - Fagzal
Re: Minimum modules for Production?
Hi, However, as has been pointed out regarding MS Word, most users only use a very tiny subset of its functionality. The problem is that the users are using different subsets. I've done huge amounts of HTML parsing and can't recall having used GDBM_File. It all comes to *different* subsets I think if we leave out but one module from CPAN, someone will miss it. However, 98% of all Perl users will be happy with 2% of all (current Perl5) CPAN modules. I wrote a lot of Perl for Unix, VMS and Windows system management, text files processing and connectivity to databases (Oracle and LDAP). I never used an HTML parser and only used LWP once. So for me a stripped down version of Perl with reasonable I/O capabilities (print, open, close, FH) would be just enough and i can settle for an easy-to-install connectivity bundle. Then again, i only represent myself. really_just_imho Some use Perl for biometric, some for converting SVG to PDF, some for creating desktop applications. But that is not typical. System administration and web/net programming covers most of the tasks most Perl users use Perl for. So my list would be something like: - basic protocols, say UDP and TCP (so that you have something to build on) - a little more higher level protocols, say HTTP / HTTPS, POP3, IMAP, SMTP (you want to *send mail*, don't you?) - something LWP-like, so you can handle GET/POST and Cookies - something CGI-like, so that you can url_encode(), $cgi-param(submit) and such - Digest::* Who can live without md5_hex() ? - Crypt::* DES, 3DES, Blowfish, SSL... - Serialize: thaw/freeze (yep, something like Storable) - something like Data::Dumper (to see what you are doing) - a template handler (like TT2 - preferably TT3 or TT6 :)) - XML parsing/generation (we must be serious...) - HTML parsing, I second that (so that you can WWW::Mechanize and HTML::FillInForm and so on...) - command line argument parsing (LongOpt or whatsthename) - DBI - MIME (you want to send mail with attachments, too :)) - some kind of image manipulation, probably using an external library (to populate your TGPs :))) - ImageMagick comes to the mind And for the sake of my open source Perl5 framework, so that I can start thinking about the Perl6 version :), these would make *me* happy : - FastCGI - Config::General - Cache::* /really_just_imho - Fagzal
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Hi, Hi Conrad, I run the grant committee for the Perl Foundation and I sit on the steering committee, so I suppose I can discuss your proposal (there are some other TPF folk here, too, so that's why this is a public email). Also, the following stuff is just off the top of my head and is in no way official. For TPF to handle something like this, we'd have to have some agreement on what the specs are, who would judge whether or not a Wiki met the specs and what to do if there were timing concerns (if we get one Wiki before another even the the later one was sent first, who wins?) Oh my, this is getting complicated :) Also, though I hate to be a spoilsport and bring this up, I'm really not sure what legal issues might be involved with running a contest, either. Would that be considered a form of gambling and possibly be illegal? I don't think so, but I'm not sure. Well, it cannot be gambling. IMHO something constitutes to gambling only if: - the outcome (who wins/loses) is mostly controlled by chance - you have to pay in order to participate Both should hold and none holds. However, there might be taxing issues... In any event, if you can come up with a solid set of contest rules, TPF can consider whether or not we can officially run the contest. It sounds like a nice idea, I just don't know what's involved. i_am_so_bad If I had some mone to spare for a contest like this, I would say: I have the money so I make the rules :) Some might not like that, but it makes things much less complicated. It's Conrad's money and his generous gesture. I would say let him decide who makes the specification and let him name the winner, according to the rules he comes up with. Those who will be unhappy with the result can always STFU, don't they? ;) /i_am_so_bad Of course if the community can make this happen is a nice and controlled way, that would be the best. I just like pragmatism :)) - Fagzal
Re: Simple Print/Say Question
Chris, Strange. I have just tried this using an old version (6.2.3) of Pugs: my (@array) = 1,2,3; print @array[0] ~ | ~ @array[1] ~ | ~ @array[2] ~ \n; It prints 1|2|3 on my terminal. Gabor's join-ed version also works. - Fagzal Oops. That last . is a typo on my part. Sorry about that! It should read, which it does in my code: print @array[0] ~ | ~ @array[1] ~ | ~ @array[2] ~ \n; However, your say join technique does not work. I will keep on it but for now I am off to dinner! Thanks!, Chris On 5/23/06, Gabor Szabo [EMAIL PROTECTED] wrote: On 5/23/06, Chris Yocum [EMAIL PROTECTED] wrote: 1|2|3 I would say something like: print $array[0] . | . $array[1] . | . $array[2] . \n; not the best way but it works. In Perl6 if say something like this: print @array[0] ~ | ~ @array[1] ~ | ~ @array[2] . \n; I get 1 2 3 | | | My question is: why is it doing that or, more to the point, what am I doing wrong? I am not sure, maybe the . before \n cause the problem but why not try this one: my @array = (1, 2, 3); say join |, @array; Gabor
