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.
Perl is definitely a good thing(tm), your favorite website depends on it!
I'm not sure what you mean by "real" but if you think OO and Perl don't go together, you're just plain wrong.
"If you think education is expensive, try ignorance" - Derek Bok
Perl was not designed to do what it's now being used for. The result is an awfully designed language made of layers and layers of incoherent stuff. Wouldn't the money be better used on projects that not as many people have heard about but that have a lot of potential if they can be completed?
True warriors use the Klingon Google
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.
who is profiting from the development of perl, and would get money for various reasons if perl6 were finished?
:)
.NET by Everybody Else, and could potentially make a lot of money for people in general if the technology there were applied.
Redhat? Mysql AB? Umm.. OSDN? Hemos is subsidizing everything2 already, maybe he could subsidize a bit of Perl6 as well
Hell, one would think that they could almost go to the bank and get a loan to finish perl 6, and use the expected profits from the O'Reiley Camel Book for Perl 6 as collateral. They will certainly make lots of money off of that, i've looked at the perl 6 apocalypses and there is DEFINITELY going to be NO WAY that you will be able to make sense of it without buying the book.
It's disappointing that the rest of the computer industry isn't jumping on Parrot as a potential competitor to CLR, as a truly great cross-language cross-platform universal bytecode engine.. i really think that would be a huge step toward the overpowering of
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!
You can't compare perl and php like this. perl does much more than provide dynamic content in web pages. I've just written a perl script to migrate 20,000 users from an NT domain to a Windows 2000 active directory. I doubt that PHP could do this. Both perl and php are excellent products. Which one is better? that clearly depends upon the application.
Do we fund Brian Kernighan and Dennis Ritchie? Or Bjarne Stroustroup? No; all three of them are "funded" by having actual jobs, and the task of adding "features" to C and C++ are handled by international or ANSI committees. Is there a fund for Linus or any of the other Linux kernel hackers? No, they all have jobs with actual companies.
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.
It may be possible to take any language that can compile itself and make it do OO; I'm frankly not sure. I'd hate to see what object-oriented FORTRAN looks like.
Finding God in a Dog
Larry, Damian, and Dan
;-)
I've always preferred Larry, his borther Darryl, and his other brother Darryl.
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've been providing streaming MP3 software for about 2 years, and had hoped that my 'tryware' approach would work. It doesn't. I have tens of thousands of users, and I've received thousands of positive emails, but I'd say that less than 0.5% ever gave anything.
You just can't support a full-time effort by relying on generosity. I still offer a free trial, but I now also have commercial versions for sale, and I only wish that I made that move a year ago.
Here's what I do: Bitty Browser & Andromeda
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.
will Larry personally convert all my existing code so it will work under Perl 6?
This is what people fail to realize about Perl 6.
The entire purpose of the current Perl 6 development is to generalize Perl.
In other words, Wall et all saw that Perl was being used for purposes it was never, ever intended for, and are seeking to make a more flexible yet consistent tool, one that can be used for the crazy-ass things people use it for without being stretched to the breaking point.
This is what the money will go toward if you send something to the perl foundation funds. Fixing the mess that perl has become. Wall is very open about this.
Part of this is that the language has become simply huge, but you have to understand that they're expecting third parties-- makers of libraries and development tools-- to offer an environment in which that huge layered monstrosity can be cut down, and you can be left with just the subset of Perl's possibility that is left for you. Think of this like quake 3 and doom 3; they looks beautiful, they aren't very useful all on their own, and they are mostly platforms for other developers to start with so that they can make something insanely great very quickly.
In short, i would say that donating to perl 6 really does help more in the long run-- because instead of directly helping one little projects, you are indirectly helping many, many little projects to reach their goals quicker and better than they could have otherwise. You are donating to something for the little projects to build on.
(P.S.: expect to see some new form of use strict; (one which does strong type checking and lots of other things to let you reign in perl's extreme expressiveness to the point you are always sure what you are doing) become very popular in the enterprise once Perl 6 has settled..)
Basically I'd like to find out what level of contribution it would take to
- Have my name introduced as an operator in the language.
- Make whitespace significant to syntax
- Rename it from Perl to "Carnage4Life: Scripting Edition"
- Add C++ templates to the language.
- Include the fuck() and unfuck() function calls that do exactly that.
I await the answers to these questions with bated breath.For 18 months of Damian and half a year of Dan and Larry... what has been produced? What finished products can we take back to our workplace and use?
Mailing list traffic? Apocalypses/Exegeses? Acme::*? A lot of travel time and expenses? Lectures given in far away cities to a few hundred perl hackers?
Half a design for a language nobody really begged for?
Seriously, when you first read that book (as I have), you first think "Wow, look at these cool hacks Perl can do to simulate OO". However, after you use a language like Python for a while, you see what real OO can do, especially with its recently unified types and metaclasses.
I was a strong Perl programmer for 4 years, but now I use Python, and it'd ridiculous to even try to compare Perl's OO to something like Python's.
actually it probably could but this is surely not one of PHP's stronger points we have code most of our shell scripts in PHP because that is what we mainly do: Code PHP Scripts But as always its often not only choosing the right tool but also knowning the tool. If we end up writing more shell scripts than web scripts we might have to take a closer look at PHP's alternatives (such as Perl)
since they use Perl for their testing framework .. they could step up and donate?
dunno ... maybe they already do ..?
You ask "what's left to do?"
How about a perl processor that handles buffer overflows safely. Not glamorous, but very practical.
Essentially this is the new virtual machine Perl 6 will be targeting (what Perl 6 will be compiled into before it is run.) But Perl will not be the only language that will run on this. People are working on making Python, PHP and even Java run on this same machine. It's about working together people.
Oh, I know it's much more fun to say "nah ne nah nah, my language is better than yours". But the Perl people want to work in an interoperable world where we can all code stuff in whatever language we want and it'll all work together. And this is their effort.
Now if you want to slam this down and winge, then it's up to you and I'm sure I'll waste my time reading your comments. However, if you want to actually do something about this kind of thing, you know where the donate button is.
-- Sorry, I can't think of anything funny to say here.
http://www.activestate.com
http://tinyurl.com/4ny52
$200,000 = total amount raised over 2 years
Damian was given a grant over an 18 month span.
Dan over 6.
Larry over 6.
18 + 6 + 6 = 30
200,000 / 30 = $6,666.67 per programmer month WITHOUT any expenses whatsoever.
even that is 80,000 per year (again with no expenses, individual or organizational), which is not that far off for senior programmers, a lot less in reality, considering they have experience overseeing large software projects.
--- What
I'd been procrastinating this long enough. Thanks for the warning.
My $100.00 contribution just went in a minute ago.
Like the rest of us non-compensated OSS developers :)
This seriously reminds me of PBS pledge-a-thons, where they break in the middle of a program you are actually watching on PBS and say "our pledge goal for this break is 25 new pledges" and they won't re-start the program until they get the 25 pledges. That's the point at which I switch to TLC or The Discovery Channel.
An additude like this is re-writing the social contract perl was distribured on, and it's artistic licence. If people start a campaign like this it will motivate people to say screw perl, I'm going to python or ruby.
It's like saying that everyone who drives by a beautiful piece of public art must now pay for that privledge or the art will be taken down.
--Shemnon
Hello all,
I currently do work for a website that sells Open Source computer hardware and donatates a significant part of the profit to Open Source and Open Source related projects of the user's own choosings. If you'd like to check it out, check out Open Soars.
Thanks,
-Scott
Yes, there is a book about object-oriented perl. The book is very good, too. Damien Conway did a pretty good job; the book is well written and even funny at times. Unfortunately, it is the concept itself which is dreadful. Perl has not been designed as an OO language, and it shows. The typical idea in this book is something on the line of: "{awful tangle of perl concepts and syntax} is nothing but a {OOP concept}, if you think for a moment about it".
:)
I bought the book with my best intentions. I like perl, I use it a lot, and I like the way Conway writes. I really WANTED to add OOP to my perl. I tried, but I found OO perl to be beyond my threshold of self-defense. It is just TOO convoluted.
I recongnize that, on an intellectual level, adding OOP to Perl without breaking anything has been a really remarkable result. But understanding and using it is another matter... If you really want OOP, I suspect you'd better look elsewhere. Java maybe?
Just my little experience
Have 'em apply to the linuxfund. Sure it may not be *all* their funding but it could help...
--Z
Yes, of course. The specification's documented (albeit a bit fuzzily, but we're working on that) in the parrot distribution. There are already several language implementations for Parrot which are included with the kit, and there are other projects (I know of one to port Ruby) in the works to target Parrot.
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
The content of the post that is actually about Perl is also not that insightful. He seems to have completely missed one of the main important things about Perl 6, which is the use of the Parrot VM.
Find free books.
There is an assumption in that message that OOP is the only or best way to make/manage large projects.
While I am not a Perl fan (but I respect personal preferences) there is no fricken evidence that OOP works better for large projects. Ed Yourdon has done surveys, and did not find a higher success rate for OOP.
I keep asking precisely how OO "scales better", and ask for code examples where procedural/relational allegedly falls down, and get nothing except vague mantra about "encapsulation" and "abstraction" that is never translated into black and white benefits in code or human effort metrics (except maybe bad procedural skills on display in the comparison).
It is true that *some* people may "think better" in OOP, but others may think better in Perl or whatever. Modeling one's head and modeling the needs of the external world are not necessarily the same thing. You can argue that OOP better models your *own* head, but don't extrapolate that to external benefits without some open evidence.
oop.ismad.com
Table-ized A.I.
I think this shows Perl doesn't. Any commercial project with anything close to the adoption of Perl would have no trouble paying their top three guys without asking for donations. Maybe Perl operations that actually generate revenue, like ActiveState, based on their work could help.
Needing to beg to fund these guys should cause serious introspection among open-source advocates about sustainable models for open-source development.
Give them enough funds to finish Perl6 - and they'll start Perl7.
Whatever happened to the "make money on support" or "sell T-shirts" strategies that have been touted by the opensource community so often? How come a viable business model cannot be found to support the development of this software?
dot parrot (or .parrot)?
Ok...
unfinished: (adj.)
Besides, .NET is a proper subset of Parrot. The reverse is not true.
They have a job you fool. Hundred of thouthands of developers arround the globe are using their (free) product and they just need a little support to keep it great and evolving.
If you can't find a job then don't blame others. And keep in mind these people can find another job in just milisecond.
unfinished: (adj.)
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.
It's not a business, so of course they don't have a business model. They don't make it for a profit (as is getting more money after paying all salaries and expenses). They just want their salaries paid.
Having said that, commercial (for profit) OSS projects have to find a way that involves NOT controlling the source. There are some examples, but it's easier in a non-OSS for now. But for a small company with little capital, an OSS project has the winning cards.
OSS -> support from the consumers / users.
CSS -> selfsupport from established player (selffunding), support from a fund or from a big company (ie: wants to buy you)
unfinished: (adj.)
Just curious. How much did you fund them last time?
unfinished: (adj.)
It's a valid point. Perl adds an overhead which is hidden and that you come to discover when someone else has to maintain the code.
It's real like it not not. Perl is easy/fast to write and hard/slow to maintain.
unfinished: (adj.)
All you need to fund Open Source Software is to donate it to non profit organizations - ie United Way, Federal or State Governments, or better the EFF - and get them to issue a receipt.
In the hands of an otherwise employed programmer, tax exempt donations can be worth 75% of face value.
Just change the GPL or (Insert favorite open source license here) to include a requirement that non-profit organizations must provide donation receipts in exchange for the use of said software.
This in essense will cause the US government to foot the development - which is exactly waht it should do!
AIL
Under "Re:What's left to do?"
Why the fucken hell was this above marked as "flaimbait"!?!?!?!
Come back here and defend yourself, coward!!!
Hiding implementation is a common theme in software engineering (usually in OOP, but not limited to), and in practice I have outgrown hard-wired simpler structures in need of something more powerful. For example, starting out with a hash (associative array), and then needed more columns later. One could turn the value into a pointer to another array, however, we would then have to change our syntax for any references to the existing value to handle the double array. Thus, we have a "scaling cascade" WRT changes.
Somebody needs to moderate the moderators. They are hit-and-run retards at times.
Table-ized A.I.