Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If you are some manager in a big company and looking at the press, there is little distinction. In fact, more stories have been posted about Python 2.x to 3.x conversions (mostly because Perl 6 is not a story). Heck, I would imagine a couple of people on HN have run into the "can't use Python 3 because it isn't compatible with anything"-meme. Carefully considered logical analysis with realistic risk mitigation gets trumped by headlines in ComputerWorld and InfoWorld quite often.

I still have quite a bit of hope for Perl 6. I use Perl 5 as my goto short scripting language. I really want it to work.



You are not getting it, Perl 6 is not designed as a successor to Perl 5 but as a Age proof Perl.

Think of it like pg called a hundred year lisp language. Perl 6 might be the age proof Perl language. When you have such and ambitious goal the time taken is worth to fulfill it. Larry wall figured out quite a while back evolving Perl 5 may fix some warts but it won't solve the larger problem.

The larger problem today is doing language extensibility sane-fully. There are no C based languages that are as much extensible as a Lisp based languages. Perl 6's larger aim is to solve that. While retaining the 'Perl factor'.

Re write is inevitable if you have to solve this problem, no matter what joel says you have to rewrite a few things to fix them. The incremental path is too slow and you will loose out on time while somebody eats your lunch.

Perl 5, Python x.0 and Ruby x.0 series are all great languages but eventually on the very long run they will be plagued with the same technical problem every language runs in to. Providing sane ways of extensibility without bloating too much.

IMO Perl 6 will do well, for the same reasons Lisp has done well.


When you have such and ambitious goal the time taken is worth to fulfill it.

After almost twelve years of rewrite after rewrite after rewrite, it's no wonder people stop caring.


Well, more than anybody else you know it well why most of the failures happened.

But for others. I can understand the obvious disappointment. But Perl 6 is designed such that without many of those failures we couldn't have figured it out earlier what it would take to build Perl 6. Perl 6 has a mutable grammar, which means it should be written in itself. And this created a huge problem, because you don't have ready tools in hand to build such a thing. Many of them had to be built from scratch. And people failed many times exploring strategies doing that. Some people got ill, some people lost jobs, and projects like this which span a lot of time and require volunteer effort without much funding takes toll on people.

In many ways there was a lead, Lisp is so extensible because its written in itself. We really should have understood this from history. But achieving that in a non homoiconic language was difficult and required thinking in direction totally new to C based languages.

But great things have come out of it. Audrey's Pugs taught us so many things. And as she says, the 'Perl 6 on CPAN' thing started long back. Moose has become a very awesome tool for OO programming. Other things borrowed from Perl 6, things like given/when have shown a way to Perl 5 for evolution. Devel::Declare showed a new way to do syntax experiments outside core without using source filters. And many great things have come out of it. Its difficult to imagine how Perl 5 will likely evolve over time.

A few years back none of us could have seen Devel::Declare or even Moose coming. I can only imagine how Perl 5 is going to evolve over time.

Lastly I would say Rome was not built in a day. Perl 6 will take time, but it will come out in some years to come.


Perl 6 is designed such that without many of those failures we couldn't have figured it out earlier what it would take to build Perl 6.

Sure, but those don't account for the past four years of failures. What I see is a pattern of overwhelming desire to throw away code just as it's in danger of becoming useful to actual users.

Phrased from a different angle, the reason we wanted monthly releases was not because monthly releases are interesting in and of themselves, but because they could deliver regular (if incremental) improvements to actual users on a predictable schedule.

Forking Rakudo into an all-but-abandoned master branch and doing monthly releases off of that branch hews to the letter of the idea of monthly releases while violating the spirit of those releases. I understand the reasons why it happened, but that sort of decision has happened often enough in the project that it's a habit--if not culture.


In the context I was talking about it really doesn't matter what I think as I am not a decision maker at some big company. Calling something the N+1 version tends to make people think it is the next version and not a proof of concept. It does matter what is said in the trades these people read:

for example: http://www.infoworld.com/search/google?cx=014839440456418836...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: