Why don't they start now and build Java 2.0 from ground up instead of Java 10 for 2017?
That would be way faster and they learned so much by now to make a great successor. Who wants a Java 1.x in 2040?
That would be way faster and they learned so much by now to make a great successor. Who wants a Java 1.x in 2040?
On the contrary, there has been a number of times that I've completely rewritten some code to use a framework or library that was already battle-tested and more fully-featured than the previous effort. I ended up saving myself from writing code that already exists.
At this point oracle can't rewrite Java. If they don't support the current programs, nobody would use it, if they do, they will really be rewriting code that already exists.
The history of the WebKit codebase stretches back as far as Gecko. The earliest KDE HTML work I can definitively establish is in 1997. We got Konquerer in 2000, but Safari didn't emerge until 2003.
5-7 years before something other than IE could again be competitive... Do you really think that disproves Joel's point? I think it may be quite the opposite...
Sometimes full rewrites are necessary and good. The trick is doing it correctly. Rewrites are riskier, more difficult, and require more development resources than greenfield development. More so when you consider that you can't just abandon the old code until the new code is mature and has proven itself.
Most people do rewrites the wrong way, and they get into trouble, but that doesn't mean there isn't a right way. There are many examples of unsuccessful rewrites in history, but also many examples of highly successful ones.
Also, IMO there's no chance of Perl 6 being successful in time (which makes me sad, because 10 years ago or so I was really hopeful about it).
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.
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.
After almost twelve years of rewrite after rewrite after rewrite, it's no wonder people stop caring.
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.
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.
for example: http://www.infoworld.com/search/google?cx=014839440456418836...