Slashdot Mirror
The Perl Foundation Grants Are Running Out
dogma01 writes "It looks like the grants to fund: Larry, Damian, and Dan have pretty much run out. :(" Keeping guys like these working on Perl is definitely a good thing(tm) if you are looking to support the Open Source Community somehow. You can donate here if you are feeling generous.
I am not by any means saying that Perl is dead - indeed, it will be many years before Python is able to offer the versatility and brevity that Perl has provided me with for ages. But the developers need to get off the gravy train and head for greener pastures. The time to leave is now; there is no work left to do.
Just my 2c.
b.
Please do not agree with me. I made no attempt to justify my assertion, therefore it can hardly be construed as valid. If I had started from a general set of core concepts concerning Perl, and built a logical progression from such concepts to my conclusion, then your response may actually have some merit. Unfortunately, I am just bored at work and decided to see who I could piss off.
Apparently, we are both failures, and we should kill ourselves. You go first.
i don't think a port of slashcode would be too bad, in fact it would probably clean it up a lot.
/. admins feel like keeping up with innovation?
perl/mod_perl was fine back in the early slash days. that was about the best there was. now there's a j2ee environment that provides flexability and feature rich components. you can develop to a model much easier. you can also scale a lot better from what i can tell. all software that doesn't get ported eventually gets outdated and rots, why don't the
Without extensively using open source software (specifically including Perl), Google would currently owe M$ a little over $200M in software licensing fees. I hope they can step forward and contribute to the effort like AOL/Netscape does for Mozilla!
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD, erm, Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.
Yet another bozo on the bus of folks who think that Perl is only good for CGI.
IMHO Perl will be quite useful long after the web is as obsolete as Gopher. Perl is not just a language, and it's not just for web content; it's a very general and powerful way for thinking about and solving problems.
Runs its industrial strength ticketing system on Perl.
How hard can it be to call the people who maintain it and ask them for the Perl Foundation to email Ryan Air and the other huge companies that rely on Perl for a relatively small donation?
Have they made these contacts already?
ATH0 Bitcoin: 1DnwFLXczVZV8kLJbMYoheUrpqHesjxrSi
I definitely agree that mod_perl's time has gone (unless you need to get access to Apcahe's internals -- something most people forget mod_perl can do). And anything based on Mason runs a 95% chance of becoming an unholy nightmare. Perl's time has not yet gone. It's too useful for smaller, everyday things like banging out a quick filter/parser or some such. It's even good for the occasional small CGI script, and I've used it for cross-platform scripting with great success. However, I don't think "porting" Slash to anything Java based is the right way to go.
If King Slashdot was asking for votes, I'd vote for PHP. The syntax is very similar to Perl's. This means the developers and maintainers have a greatly reduced learning curve. You could almost literally port Perl code function by function to PHP. At the end, you'd wind up with something that looked very similar to the original Perl, but without all the baggage. PHP is at least as fast as mod_perl, and possibly fater than servlets (it has been in at least two cases I've seen). You wouldn't lose speed if you moved from mod_perl to PHP. The development model is very close to Perl's. If you're used to working with mod_perl stuff under Apache, then you'll immediately take to writing PHP apps. If you've administered mod_perl and Apache, then you already know how to administer PHP. With J2EE you get a whole new set of things to look at.
Anyway, that's my opinion. I've always felt that people should use the right tool for the job, and a part of the "right tool" definition is using what people already know as much as possible (unless it's a learning experience they're after). This is why it's good to know a lot of different technologies: you can apply the right tool at will (shell scripts instead of Perl, Java over Tk, whatever). If the Slash developers don't already know either PHP or Java, then they can most quickly get started with PHP, partially satisfying that "what you know" bit. The curve would be much more steep with Java.
However, the bottom line is that Perl seems to work fine for Slashdot, so likely there's no reason to fix it.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
The thing Wall et al are being paid to do is not that they are "adding features"; they are actually the core people writing the specifications, the interpreter, and the associated tools. Someone has to do that. They also are coordinating the perl volunteer development effort, no small task.
Also note that some of those grants are going to things that benefit the community back-- for example, Damian Conway's grant helped him travel around the country and give talks educating people on perl.
Brian Kerninghan, Dennis Ritchie, Bjarne Stroustroup, James Gosling, and Guido Van Rossen were all lucky in that they found companies (AT&T, AT&T, AT&T, Sun, BeOpen/Zope Corporation) that were willing to pay for them to design the languages and write the compilers. Wall and co. unfortunately just have not found such a sponsor.
So i think it is in everyone's benefit-- seeing as the Perl6 tools, once done, will be included with just about every single commercial UNIX in the universe, and used as the foundation of countless numbers of professional ventures, for example websites-- if the community would pick up the slack and raise some money for them to finish their (important, i think) work.
Do we fund Linus and Alan Cox? No, becuase companies are willing to subsidise them. Does that make their money any less of a charitable donation? I don't think so. If Linus and Alan Cox lost their jobs, would a "fund" arise for them so they could continue to write linux? I think the answer is, hell yes. Some things just need to be done one way or another.
I use Perl all the time to do OO programming, but I wouldn't call Perl's OO techniques wonderful, not by a long shot. Perl has its place. I don't believe that Perl is the best contender out there for web-based things, PHP is far better in many of those areas, but Perl can do many, many things in the console world that PHP can't hope to do (even thru the PHP executable).
... something, anything :)
In the OO world, Perl's implementation is a hack at best. The fact that there are only about a bazillion different ways to define a package ("class" in OO-speak) and to get subroutines and parameters of that package viewable/executable by including scripts makes my point for me. Its great that these different ways exist - they each serve their own purpose, but they don't come close to converging under a wonderful OO techniques umbrella!
What I would really like to see is a good book written for Perl, not that talks about the language features and such, as the Camel book does, but rather about how to effectively use all the modules in CPAN. The number of contributed modules is just enormous and I'm sure I could make use of more of 'em if I had a decent reference book for 'em (I know a few sites exist out there, but I'd really like to see more thoughtful coverage). Maybe identify a few different "major" areas and then get a few Perl gurus together to write a few different volumes
See this module
Perl uses run time polymorphasim, and hence doesn't use a Templating system for code. Or maybe you could just run the C++ code inline
Is something that deletes all your source code and still continues to run it close enough?
Did you laugh? Okay, go donate!
Seriously though, these are all silly examples. Perl's used for a lot of sensible stuff. The biggest mistake most people make is mistaking humour like this for a lack of professionalism
-- Sorry, I can't think of anything funny to say here.
Same here, I been feeling the guilt.
From now on when I bid a project and the project uses Perl I will include a $50.00 surcharge to add to the fund.
who is really going to miss it?
I suspect you have never really used Perl. Maybe had to maintain some newbies code or something like that, but that is extent of your experience with Perl.
Lets look at it this way. I propose that C provides more ways to code illegible than Perl. You can write horrible partitioned code, relying on precedence of operations, use lots of global data, recursively loading include files, using multi deep redirection when not necessary. Perl on the other hand has a some "features" that allow a coder to clarify their work, such as variable interpolation so that string concatentation looks cleaner
$str = "Time is $time in the $day day of the $month month.
vs
str = "Time is " + time + "in the " + day + "day of the " + month + " month".
Or the use of operators such as "unless", "or", "foreach", etc
Or the use of named parameters in function calls
Or the use of symbolic references.
Or use of the comments in reg expression.
I suspect the reg expression are the chief reason for your compliant on "ASCII explosion". Reg expression is a language of its own but knowledge of reg expression is pure power, it is compact expression where a single expression represents pages of code.
IMHO I love the intergral inclusion of reg expressions within the langauge framework. It is one Perl's strength. Without it would just be another "for,if,else,while,goto" language
Besides, .NET is a proper subset of Parrot. The reverse is not true.
Things the size of perl, or python, or ruby, or linux, or apache, take an enourmous amount of work, and the bigger the project gets the more work it takes. The folks doing the majority of the design work are already supported to do it in some way: Matz is paid to work on Ruby, Guido's paid by Zope to work on Python, Linus and many of the Linux folks are paid to do the work they're doing by their employers, and many of the Apache developers are being paid to work on Apache. And for large projects, like perl 5, where the lead is a full volunteer, they couldn't do what they're doing without a huge contribution and sacrifice by family.
We're trying a slightly diffrent approach, with direct grants rather than indirect ones, relying on the community to support us rather than, say, IBM or HP. And we're not asking people who can't make ends meet to donate money, but we are asking that people and companies that use perl to throw some cash into the hat.
It's a pleasant myth that large software projects can be done for free entirely in the spare time of volunteers, but that's never been true. Either companies have paid in one form or another for the work (knowingly or unknowingly) or individuals have sacrificed a lot of their personal lives to make it happen.