The Perl Foundation Grants Are Running Out 235
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.
What's left to do? (Score:2, Interesting)
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.
Re:What's left to do? (Score:5, Interesting)
I take it you've not had a look at the Perl 6 spec [perl.org]. There's a lot of radical new development underfoot. Whether perl needs more features now, given that it is fairly mature is another matter. It seems to do almost everything that people want it to do.
Although, " version 2.0, and I can honestly say that the features added since that time have not made my life any easier. "
How about adding OO? How about special variables gaining names? etc... It's clear that every time perl has been upgraded, it has been of benefit to quite a large chunk of users.
Re:What's left to do? (Score:1)
Yikes! We need FEWER programming envioronments with bolted-on-as-an-afterthought Object Oriented 'features', not more of them.
Re:What's left to do? (Score:5, Insightful)
I have been a Perl guru since version 2.0, and I can honestly say that the features added since that time have not made my life any easier.
You never use references?? If you have no necessity for hash references or list references for complex data structures, then your Perl needs must be pretty low.
Re:What's left to do? (Score:1, Flamebait)
That is what databases are for. Roll-your-own databases have the problem of hard-wiring the implementation into the calling code. If you change the representation, then you have to change all your calls.
A better approach is to hide the collection implementation behind some kind of API so that you can change the representation without recoding everything.
The most common approach is a database or database-like API that stays pretty much the same for multiple implementation engines from hash-like things up to Oracle.
Even if you don't like RDBMS, wrapping collection manipulations to hide implementation is still a good thing (and contrary to popular belief, you don't need OO sh*t for this.)
Re:What's left to do? (Score:2)
That is what databases are for. Roll-your-own databases have the problem of hard-wiring the implementation into the calling code. If you change the representation, then you have to change all your calls.
I think (hope) we're talking about different things. I'm not talking about rolling up a Perl data structure for persistance purposes, I'm talking about internal data structures that can be passed between functions.
Unless you think that instead of passing back a hash reference of data from my subroutine, I should have a temporary table in a database, store the data in the database, read it back in the calling subroutine, and then delete the temporary data! If this is what you're talking about, please check yourself into the nearest mental health facility. :)
Re:What's left to do? (Score:2)
Databases and persistance are not necessarily the same thing.
(* Unless you think that instead of passing back a hash reference of data from my subroutine, I should have a temporary table in a database, store the data in the database, read it back in the calling subroutine, and then delete the temporary data! *)
Some DB protocols allow auto-temporary collections. Besides, sometimes you end up needing to store stuff anyhow. You don't want to have to overhaul your code to switch to a persistence-friendly protocol.
I think you are missing my point. Requirements for collections change (at least in my domain). Thus, one should pick a protocol that can scale from simple to complex without having to rip-out and redo the collection handling code when you move up a step or two.
Perhaps we need to look at a specific example.
Passing a database record-set handle is not really different than passing an array handle anyhow (in a good protocol). Your view that database==disk is not necessary accurate.
Hiding implementation *is* important (Score:2)
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.
Re:What's left to do? (Score:2)
Which is a fantastic idea by the way - just imagine, a simple -> in perl going off and querying the oracle database in the basement. That would rock.
That would indeed rock, which is why Perl already supports it. Review "Tied Variables" [perl.com].
Re:What's left to do? (Score:2)
Java doesn't [sun.com](although the + operator is used to concatenate strings).
I guess you just have a bizarre and rarefied sense of humour.
Re:What's left to do? (Score:2)
1+1... eval ... 3???
Re:What's left to do? (Score:2)
Or, change the syntax so that you don't rely as much on operators. I realize that operators are compact and such, but there are only so many to go around.
But, there are many different ways to approach such API's without making them "wide".
Oracle in your basement? What about MySQL? Or was he just joking?
No More Buffer Overflow Exploits (Score:1)
How about a perl processor that handles buffer overflows safely. Not glamorous, but very practical.
Re:What's left to do? (Score:2)
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.
Not to be argumentative, but brevity is not a concern of Python's. Python is explicitly verbose because it makes the syntax easier to read, understand, and maintain. At least, that's what its proponents [canonical.org] claim.
(FWIW I really like both Python and Perl, and agree with the parent -- Python is very deserving of further investment/attention.)
Re:What's left to do? (Score:2)
Re:What's left to do? (Score:2)
OO in perl is clumsy.
Perl 6 is becoming another C++: still C, and not quite clean OO.
Rather have a properly OO designed language with a small lexical description do the OO job for you. That's what made Smalltalk so cool, and why Python is better than Perl in this regard.
Don't ge me wrong, perl is way cool. And one can program OO in any non OO language... just not legibly. (Add this to perls legibility tract-record and you have a winner!
My 0.01999999R
Re:What's left to do? (Score:1)
The changes to Perl need to be made the same wa Perl came to live...by Larry and other hobby programmers working in their free time to develop something. Don't keep laying a guilt trip on the development community for money when we won't see anything useful for 3+ years.
Not just perl... (Score:5, Funny)
Re:Not just perl... (Score:2, Interesting)
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
I'd port to PHP instead (Score:2, Interesting)
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
Re:I'd port to PHP instead (Score:3, Insightful)
And if the coders have that much time on their hands, they can fire a few people and cut down on the amount of advertising they do to support the staff overhead.
Re:I'd port to PHP instead (Score:2)
Re:I'd port to PHP instead (Score:2)
Having managed a number of technology projects for businesses, I'd be very skeptical of such arguments until presented with concrete examples of where the code base as it stands is causing me to lose potential business. In real life, the conversion costs are huge, and the benefits rarely exist at all. Where they do exist, they tend to be small and hard to capture.
Fund the little but interesting projects (Score:1, Insightful)
Re:Fund the little but interesting projects (Score:5, Insightful)
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 :-)
Re:Fund the little but interesting projects (Score:2, Interesting)
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
Re:Fund the little but interesting projects (Score:2)
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.
Re:Fund the little but interesting projects (Score:2)
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.
Re:Fund the little but interesting projects (Score:2)
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.
Re:Fund the little but interesting projects (Score:2)
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.
Perl 6 (Score:1, Insightful)
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..)
Re:Fund the little but interesting projects (Score:1, Insightful)
Your problem is that you try too hard. Making comments like that doesn't draw many replies. People generally just read it - assuming they browse at -1, which most don't - then think 'what an idiot' and move on. It's simply not worth a reply.
However, I feel it would be helpful to give you some advice on your technique.
If you wish to be a successful troll, study the work of the masters, who will get a trollish comment modded up to +5 and a fistful of bites while leaving it obvious to those with a clue that their comment was just a common troll.
The basic rule is try to fit in. Don't make it obvious. Be subtle. In short, do the complete opposite to what you are trying to do.
It is your lack of subtlety that shows your immaturity. Hopefully one day you will learn.
Isn't there anyone (Score:3, Insightful)
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
Re:Isn't there anyone (Score:1)
And I've just sent $50 towards the foundation. Thanks for putting it into perspective for me.
Help, Google! (Score:5, Interesting)
Re:Help, Google! (Score:1)
Where do you buy MS Perl at?
Re: Perl for windows distributions (Score:1)
http://www.activestate.com
interesting you mention MS (Score:1)
Help US Government! (Score:2, Insightful)
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
Kernighan and Ritchie? (Score:4, Insightful)
Re:Kernighan and Ritchie? (Score:1, Interesting)
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.
Re:Kernighan and Ritchie? (Score:2)
Re:Kernighan and Ritchie? (Score:1)
Re:Kernighan and Ritchie? (Score:3, Insightful)
C++ is such a monstrosity, it's clear that there were too many committees involved.
Is there a fund for Linus or any of the other Linux kernel hackers?
False analogy. People sell Linux distributions, and make money that way. That's why Red Hat can pay Alan Cox a salary. Nobody sells Perl interpreters.
Do we fund Brian Kernighan and Dennis Ritchie? Or Bjarne Stroustroup?
False analogy. Larry Wall wrote an open-source implementation of Perl. K&R and Stroustroup didn't write open-source implementations of C and C++.
The funding model you advocate resulted in badly designed languages(*) that didn't get free implementations until decades later. The funding model Perl is using has resulted in a well designed language that has always been available in free implementations.
*Especially C++, but C too. The fact that something like autoconf is necessary shows that certain aspects of C were really botched.
Re:Kernighan and Ritchie? (Score:2)
They weren't quite *as* open as BSD, but when you paid for UNIX in the Good Old Days, you got the source.
This is actually a VERY apt analogy, especially because it points out something that /.'ers are afraid to admit: Monopolies are good for CS. IBM, AT&T Bell Labs, XEROX PARC were all funded by monopolies. Many of the great innovations came out of these places. Add in universities (which are fairly similar), and that's most of the development in CS right there.
Why? Because those places are *able* to give cushy jobs like this that can fund deveopment of cockamameyed ideas that turn into revolutionary concepts.
Perl 6 is a mistake (Score:2, Interesting)
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 [mozilla.org]. 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 [rubycentral.com] (and not one with loads of irritating whitespace [python.org] 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 [lysator.liu.se] 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 [perl.com]. Does he want Perl 6 to be flex [gnu.org] 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 [goatse.cx]. I'd prefer to use a language [ruby-lang.org] which has always been pure synthesis of science and engineering, not some half-baked imposter [beonex.com].
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.
OOP == Big? (was: Perl 6 is a mistake) (Score:2)
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
Re:OOP == Big? (was: Perl 6 is a mistake) (Score:3, Insightful)
*Small* interface? Bwaaaa haa haaa!
Interfaces can be built just fine without OO.
I will believe the OO hype when I see side-by-side biz app code of OO kicking procedural/relational's butt in code size, change-impact analysis, or whatever good metric you want to use.
(* It's called "refactoring". *)
"Refactoring" is a euphemism for "cleaning up the code because it did not change as easily as the OO brochure promised".
(* design patterns also help. *)
Do you think OO has a monopoly on "patterns"? The p/r versions of GOF patterns are usually far simpler IMO.
(* Where have you been in the last 10 years? *)
Listening to unproven bullshOOt.
oop.ismad.com
Re:OOP == Big? (was: Perl 6 is a mistake) (Score:2)
I disagree. OO *over*-couples data to given behavior; their real-world association is much looser and dynamic than OO doctrine dictates.
(* refactoring address directly the problem of change. *)
That is because refactoring *is* change. My euphemism suggestion still stands.
(* Obviously, if you don't master this technique, by considering which is in most code the singlest most important of aspect designing and coding FIRST - change, then you don't understand anything to the power of OO. *)
I perfectly agree that "being a student of change" is important to good software engineering. I just disagree that OOP is the best way to acheive it. It is a doctrine that *assumes* certain patterns of change, and I simply find these patterns in error (WRT frequency of occurance). OO's approach to change management is simply wrong because it over-emphasizes change patterns that it is good at and ignores those it is not.
OO fans accept the doctrine of what the change patterns are, and just write-off non-fitters of such patterns as "just some refactoring work".
One should observe the patterns of change first, and *then* apply a solution, not the other way around. OO tries to force-fit the two.
Re:OOP == Big? (was: Perl 6 is a mistake) (Score:2)
Okay, I don't do physics for a living. I do custom business applicatioins. Physical applications, such as physics, chemistry, and math may indeed fit OO better because the taxonomies that OO often depends on don't change and morph into irrelavency on the whim of bosses, customers, markets, or politicians; which is common in biz apps. God has not changed the rules of physics in my lifetime.
(* People doing refactoring are the masters of change *)
People doing refactoring are the *victims* of change.
(* Data is accessed behind interface *)
Note that I consider a relational database an *interface* and not an implementation.
(* I don't see how you change less code in procedural code. *)
Procedural/relational code does not make large-scale structural decisions based on the association of data and the actions on that data for the most part. In biz, the "effectors" often change. Further, actions often involve *multiple* entities. A single entity owning any one action is a silly, artificial, and unstable notion in most cases. P/r tends to manage these associations by using local boolean and relational expressions (equations), and not global physical brick-by-brick code structures. Thus, it is more virtual and abstract and relative because it depends on powerful formulas to provide the needed view instead of hand-built code structures. It is like the difference between calculus using equations versus calculus using rectangle approximations under the curve.
(* this is not obvious when you write your own code, but definitly is when you take code from others. *)
Not any OO code I have ever seen. About 1/4 to 1/2 of the interface is reinventing database functions (insert, delete, find, sort, etc.). That means 1/4 to 1/2 of the interface features are not going to be in a p/r equivalent because p/r has factored that into the database interfaces, instead of repeating such operations over and over and over for each and every class.
(* Huh? Which change pattern is assumed? By grouping toghether data and code applied on it, you make least assumptions. *)
Your fallacy is in your very sentence: the assumption that they *should* be tightly grouped together. I question that. It works okay for simple toy textbook examples, but not in the network of the real world interrelations.
Re:Perl 6 is a mistake (Score:3, Informative)
Um, yes it does. For instance:
It also supports mixin inheritence, in case you want some more exotic inheritence hierachies; class mixes in Module, and Array mixes in Enumerable, for instance.
Not my cup of tea..... (Score:2, Funny)
I've always preferred Larry, his borther Darryl, and his other brother Darryl.
Ryan Air: The Low Fairs Airline (Score:5, Interesting)
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?
Remindes me of PBS (Score:1)
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.
Re:Remindes me of PBS (Score:2)
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.
Re:Ryan Air: The Low Fairs Airline (Score:2)
Utter nonsense.
From the Ryanair website investor relations link: Ryanair are thriving [ryanair.com]
"RYANAIR DELIVERS RECORD Q.3 PROFITS DESPITE EFFECTS OF 11TH SEPTEMBER TRAFFIC GROWS BY 30%, PROFI TS RISE BY 35%"
And contacting Ryanair would not be spam. I am talking about making a phonecall to the people who maintain and who wrote the ticketing application. Only ten to fifteen calls like this would do the trick, and solve the current problem for the foundation.
Begging doesn't work (Score:2, Insightful)
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.
Re:Begging doesn't work (Score:1)
If I donate... (Score:4, Funny)
Re:If I donate... (Score:1)
Yes!
Well, almost: a p5 to p6 converter will be available. It's really at the base of perl6 of having an automatic converter for perl5 scripts.
Also, with the perl6 interpreter you will be able to add a "use perl5;" pragma, so you'll only have to add a line to your scripts if you don't want them automatically converted.
Re:If I donate... (Score:2)
One of the express design goals of Perl6 is full backward compatability with Perl5 code.
One of the reasons that Perl6 is happening now is that the technology to do this was proven out over the last few years through the work done on the Perl B::* modules.
What Do We Get If We Donate? (Score:5, Funny)
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.Re:What Do We Get If We Donate? (Score:5, Interesting)
See this module [cpan.org]
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 [cpan.org]
Is something [cpan.org] 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
Re:What Do We Get If We Donate? (Score:2)
Of course, I should really have used Perl's symlink command ;-)
Ask yourself... (Score:2, Insightful)
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?
Re:Ask yourself... (Score:5, Insightful)
Perl6 is arguably more complex than versions 1-5 combined, and yet it is coming along at a faster clip than any of the earlier iterations did -- largely because, yes, people have donated money so that these three very talented language designers can attack the problem more or less full time. It's foolish to expect this generation of Perl, as complex as it is, to come out in 1/4 the time that the most recent versions took. On the contrary, if it takes "only" 5 years, we can be glad that it arrived as soon as it did thanks to the full-time work these guys have been able to put in.
Also, it's worth noting that Perl has always been one of the first "mainstream" languages to bring features from special purpose academic languages to a wider audience, and Perl6 is a strong continuation of this history. Most people are probably unaware of constructs like regular expressions [version??], closures [Perl5], co-routines, currying functions, and continuations [all Perl6], so why would you expect masses of people to be "begging" for them? And yet once these features get implemented in Perl, they've had a tendency to start being demanded in other languages too -- witness Java recently adopting Perl-esque regexes, even as the Perl6 regex design is evolving away from simple pattern matching engine and into a more sophisticated grammar recognizing parser like Parse::RecDescent, lex, or yacc/bison.
So really, this kind of comment is nothing but trollbait, and I'm falling for it. Perl6, even half-fleshed out, is a tremendous leap forward compared to Perl5, and I for one feel lucky to have these guys focusing on it. In spite of your naked assertion at the end there, the RFC process that kicked off Perl6 development -- with well over 300 well thought out documents that took months for Larry to properly analyze -- well proves that people *were* begging for change, and slowly but surely it is happening. I hope that some magician can produce the funds to keep the Perl6 roadshow on the road, because within a couple of years I want to be able to use this wonderful new version of Perl. If the show ends now, it'll be years longer before Perl6 ever sees the light of day...
Re:Ask yourself... (Score:5, Informative)
I'll let Larry and Dan speak for themselves, but as for myself: in the eighteen months I was supported by the Perl community I produced the following...
- Released 55 significant updates to 21 CPAN modules...
...including 16 entirely new modules... ...5 of which were subsequently considered important enough to be included in the Perl 5.8 core distribution;- Wrote four extended documents (Exegeses 2,3,4 and Synopsis 5) explaining the Perl 6 design;
- Wrote a Perl Journal article on the practicalities of porting Perl 5 code to Perl 6;
- Developed a 125 page alternative design for a future Perl (named Perl 5+i), much of which has fed back into the Perl 6 design process;
- Wrote several articles for various Perl community channels like use.perl;
- Added 88 discussion nodes to the Perl Monks website;
- Posted 192 responses to messages posted on the comp.lang.perl.* newsgroups;
- Replied to over 5000 Perl-related email messages;
- Gave 167 hours of presentations on 56 Perl topics in 21 different cities in 9 countries on 4 continents.
These [cpan.org], for a start...- Attribute::Handlers
- Attribute::Handlers::Prospective
- Attribute::Types
- Class::Delegation
- Filter::Simple
- Getopt::Declare
- Hook::LexWrap
- Inline::Files
- Lingua::EN Inflect
- NEXT
- Parse::RecDescent
- Perl6::Currying
- Perl6::Placeholders
- Perl6::Variables
- Regexp::Common
- Switch
- Text::Balanced
- Text::Reform
Yes. That's where the community converses. Yes. Designing Perl 6 was the main job we were asked to do. Sure. Play is where the community coheres. Yes. Too much. 28 weeks apart from my family.But hundreds of extraordinary individuals and organizations [perl-foundation.org] did collectively donate over $210,000 in the last 18 months to ensure that the work we were doing would continue. And donations more than doubled in the second 9 months of fund-raising.
I had always assumed that was because the community approved of what we were doing.
Damian
Re:Ask yourself... (Score:2)
Not Just For Perl Development (Score:4, Insightful)
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.
Re:shouldn't it be called (Score:2)
Ok...
Re:shouldn't it be called (Score:2, Interesting)
Besides, .NET is a proper subset of Parrot. The reverse is not true.
Re:parrotcode question (Score:1)
Money where my mouth is (Score:2)
I'd been procrastinating this long enough. Thanks for the warning.
My $100.00 contribution just went in a minute ago.
Re:Money where my mouth is (Score:3, Interesting)
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.
Re:Money where my mouth is (Score:2)
Guess they'll have to do it for the Love now (Score:1)
Shameless Plug... but related to donations... (Score:1)
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 [opensoars.com].
Thanks,
-Scott
Have 'em apply to linuxfund (Score:1)
--Z
Re:Perl sux0rz (Score:3, Informative)
Perl and OO (Score:3)
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.
Re:Perl and OO (Score:2)
Re:Perl sux0rz (Score:2)
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 [python.org].
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.
Re:Perl sux0rz (Score:1)
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
Hello and I am a troll. (Score:1, Interesting)
Apparently, we are both failures, and we should kill ourselves. You go first.
Re:Donate to PHP (Score:1, Insightful)
Re:Donate to PHP (Score:1)
You're part of the problem (Score:4, Interesting)
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.
Re:You're part of the problem (Score:1)
It can be used as a generic scripting language too. It can be called stand-alone. No web server required.
I'm using it as a code generation engine (generating C++ code from XML metadata).
Re:You're part of the problem (Score:2)
Re:You're part of the problem (Score:2)
I am using it for parsing all emails of a certain domain (an automated email ticketing system. The username is a ticket, not really a username.
Where did you learn math? (Score:2, Insightful)
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.
Re:Where did you learn math? (Score:2)
Re:Where did you learn math? (Score:2)
If being paid directly as a contract, you've got to shrink it by 7% to account for the so-called "employer's share" of Social Security.
Re:Where did you learn math? (Score:2)
Re:So what? (Score:4, Interesting)
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
Re:not a troll (Score:2)
It's real like it not not. Perl is easy/fast to write and hard/slow to maintain.
Re:I'm hard pressed... (Score:2)
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.
Re:I'm hard pressed... (Score:4, Interesting)
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.
Re:If only open-source projects had a business mod (Score:2)
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)
Re:We'll pay twice! (Score:2)