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
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!
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.
A tool that is "top-down" spec'ed, analyzed, and designed will be good for exactly what it was defined for. Perl has grown in ways that such a designed language never could.
To me, the true mark of success for a tool is that it gets used for all sorts of things for which it was not designed. In this way, Perl is the biggest success story of all time.
The result is an awfully designed language made of layers and layers of incoherent stuff.
It has been cleaned up, slowly. It has wonderful OO techniques available (although they probably do not appeal to anyone who believes that C++ is "object oriented"). The worst punctuation-based built-ins now have symbolic names. But yes, it is kinda messy, in a way very similar to English.
Well-designed human languages (e.g. Esperanto) don't fare too well in comparison to the ugly mess ones, either :-)
will Larry personally convert all my existing code so it will work under Perl 6?
No, the money would be best spent where it will result in the biggest benefit for the community. Perl has proven to be a very popular and very useful project to a large audience of developers. It has attracted some high-caliber programming talent to work on Perl 6. There are only a handful of other projects out there (Apache, Linux) with the same potential for positive impact on the open source programming world. So, Perl offers a better return on your investment than most of the projects that you could help fund.
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.
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.
$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.
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
I agree, Perl OO is not the same as C++ or Java OO. It does typify TIMTOWTDI. Perl OO's use of Perl's built-in hashes and calling flexibility (especially run-time redirection) is what makes it wonderful; you seem to feel differently.
good book written for Perl about how to effectively use all the modules in CPAN.
CPAN is amazingly useful, and (thank god) stops folks from re-inventing the wheel all day long. It's a core strength of Perl.
Christiansen's _Perl Cookbook_ is a start, especially for the bread-and-butter CPAN stuff. But all the modules in CPAN? That's a lot! There are (at this moment) 3454 such modules! I think it's better to train people to think to themselves Somebody else must've solved this problem before. I'll look in CPAN for the solution and let them do the looking themselves.
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
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.
Rubbish.
Ryan Air have benefitted enormously thanks to Perl, and it would be good of them(reg) to simply say "thank you" to the developers by paying a small amount to aid in the further development of Perl.
Perhaps, the proceeds from one fully booked flight between Paris and London?
If they do not do this, Perl isnt going to be withdrawn as in your example, and because the source is available, someone else can always pick up the task.
Companies give billions away each year to charity. Why not give what is comparitivley an extremely small amount to developers so that the world can run free software?
Free software is as worthy a cause as any to support.
ATH0 Bitcoin: 1DnwFLXczVZV8kLJbMYoheUrpqHesjxrSi
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.
If you've always been wearing the C++ strait jacket, you might not know how much you're missing by not having dynamic class reassignment and dynamic inheritance. Other OO languages (like Smalltalk) have similar dynamic qualities.
It depends on your programming style - you may actually like the restrictive C++ way. I don't. A lot of the things where you have to sweat to make multiple inheritance work in C++ come very naturally in OO Perl.
dot parrot (or .parrot)?
Ok...
unfinished: (adj.)
Besides, .NET is a proper subset of Parrot. The reverse is not true.
C++ has lousy run-time type information. Perl lets you interrogate a class's structure and capabilities at run-time: class name, hierarchical relationships, and method compatibility. (I'm mostly quoting from Conway's book here.)
You're referring to what java calls Introspection/Reflection and I have heard rumors this is in the works for C++ as well.
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.