Re: How to wake up the Perl community?

[Anonymous Monk]

Yes we are in trouble, and we have been for a long time now. The only thing is the screaming is reduced. If you were to go back a few years, the "Perl is dead" screaming was a lot louder than it is now. I believe that's because a degree of irrelevance is slowly beginning to take over us. We are getting irrelevant.

There is little point in living in denial.

Though Perl is still by and large a very helpful tool to get things done(of a different kind). Most people don't use it to solve the in-demand problems of our time(Read: Concurrency, Web framework stuff, asynchronous IO, scientific programming, teaching courses etc). People believe regular expressions, file operations are solved problems(And guess what in many ways they are). And your usual Unix glue ammunition comes with every other language these days. To add to other problems, integrating with OS ise a worry of the past. These days running on many VM's is vastly more important than integrating with a OS like Unix.

Apart from general small time scripting work, we are no longer relevant to the larger programming problems of our time. To do anything useful with OO we need something external like Moose, forget that- even to do something as simple as function signatures or say exception handling we need CPAN modules. No sane software shop is going to use a external library to do simple OO, function calls and exception handling. And this doesn't even begin to describe what is wrong with our language.

Yes you can argue that a language like Java needs frameworks to do most work, but hey! they don't need libraries to work with basic syntax. I hope you understand, we are having some very basic problems here.

Talk to p5p guys and they will tell you they have their own pains. They have to maintain backwards compatibility with a code base 25 years old, and a code base maintaining which requires heroic efforts. And beyond all this, adding new syntax sugar makes the TIMTOWDI problem only worse. In short 'we are screwed if we do and screwed if we dont'.

Come to CPAN, a while back it had no competition. Now every other language has their own CPAN. And lets be frank if you really want to find something on CPAN, you are likely to face a problem of plentiful options

We are long past the stage of having to wake up people. We are in a stage where we have to figure out how to slow down being irrelevant, then stop being irrelevant and some how find a way of bringing back lost users.

There have been attempts in the past to make this happen. Chromatic wrote a wonderful book, Stevan little has a new project called 'Moe', Schwern started 'Perl5i'. Pugs, Ponie... Have all been there..

The fundamental problem remains, we haven't solved any basic problems and we have nothing new to offer for years now.

Perl 6 is the only hope. And we must hope they get some production ready stuff out in a year or two. Before you pounce on me and ask what exactly is production ready and how it varies from person to person. I would like to tell you lets not indulge into this semantic play of words. The whole world has a definition for production ready, which is really spec completeness, no dead-on-arrival bugs, a standard library and documentation. You can argue that a beef steak is ready for consumption even when the cow is alive depending on whether a lion or a human eats it- and thereby the beef steak was production ready when the cow was alive. But hey, a person ordering a beef steak at the hotel expects it to be as he eats it at other hotels.

[chromatic]

Perl 6 is the only hope. And we must hope they get some production ready stuff out in a year or two.

If that's true, we should give up, because Perl 6 currently lacks answers even in spec form for "Concurrency, Web framework stuff, asynchronous IO, scientific programming, teaching courses etc", and of the three extant implementations, one has been effectively abandoned for several years, one has been abandoned by its primary author, and the other is in the middle of a rewrite away from a dead platform to another platform.

... and we have nothing new to offer for years now.

I don't know about that. I'd like to have function signatures and a MOP in the core, but the fact that Perl 5 gets Unicode right enough (okay, I'd like a more efficient way to load property tables, but encoding, normalization, and folding just work), that I can use Moose's MOP to make our code simpler and easier to use, and that our tests are efficient and effective lets us get a lot of work done that we'd struggle to do as quickly or correctly in another language.

I can't think of the last time we had a problem with Perl; our problems are "We have more work than people to do it", "Tuning databases for complex data sets is hard", "User data is messy", "Nobody has really solved deployment well yet", and "Our stakeholders don't really know what they want until we show them proofs of concept."

[curiousmonk]

My point was not that we need stuff like Concurrency or an Asynchronous IO in the Perl 6 spec itself(As far as I know they are already a part of the Perl 6 spec). My point was that, for a framework to be written in Perl 6 to do <anything> no one currently considers it to be a stable, feature complete platform. Do we seriously expect somebody even at a Perl heavy shop like Amazon to take Perl 6 and build some API out of it?

Who then in real sense will use Perl 6 to solve some hard pressing problems developers/businesses face now?

You can say that from a certain semantic perspective production readiness is not the same for every one. But in such things, and things like stability- You measure stability by what is needed in the common cases and build it from there. And not for the lowest case.

Besides arguing about such things becomes irritating over a while. Its like what I wrote earlier about the beef steak. Will you at a restaurant accept, if raw uncooked meat is served and the waiter argues its ready for to be eaten from the perspective of a lion? Rather the definition steak as per you will be the most 'common cases' of steak(which is well cooked meat, added the recipe). You might still be OK if it is served without a little mint garnish. But you will at least expect to be cooked.

The need of the hour is to put all the energies in ensuring Rakudo can be spec complete, stable, with libraries and documentation ON ATLEAST ONE VM. Yet how many rewrites have we seen? How many different parallel half done attempts to run it on multiple platforms? How many abandoned projects? Pugs, Rakudo, Niecza, Ponie, Moe? .. and how many more?

As I said before, people might still accept the steak without garnishing. But expect it to be cooked. We need at least one spec complete, no-dead-on-arrival bugs, with libraries and documentation Perl 6 implementation. Frankly no one cares about running Perl 6 to two or more VM's in the very first production release. Every body understands such a demand is unrealistic. We can take all the time in the world to have run on multiple VM's once we do it right and complete on at least one VM. Python/Ruby have all done that. They have one solid complete thing, and then they have PyPy, IronPython etc.

P.S: I created an account just to comment on this site