Wow, how can you seriously plan releases of a programming language out to 2021? That is an eternity in this industry. Even 2015 for JDK 9 seems mighty far off, especially accounting for the usual slippage of release dates with big software projects.
"A plan is useless, but planning is essential" [1]
More true than ever, if you ask me. Sure, you make plans, why wouldn't you? But you also retain the flexibility to adapt the plan as the environment changes. You don't chisel the damn plan into a stack of stone tablets and render it immutable for all time.
I don't see any conflict whatsoever in planning out through 2021. I would say that in doing so, there's an implicit assumption that the plan - especially the farther reaches of it - are subject to change and are based on current best guesses.
[1]: paraphrase of a quote attributed to Dwight Eisenhower, which was probably in turn a paraphrase of another quote. http://en.wikiquote.org/wiki/Dwight_D._Eisenhower
What happened at back-end, like server-side functionality of business apps? They didn't really change and probably won't change for a longer period of time. Even stuff like Hadoop for big data or Groovy for DSLs were built upon the existing JVM.
It's hard to say what devices we'll have in 5 years, or what internet would look like, but i'm pretty sure servers would run good old Java.
I think the point is more that 5+ year planning in the tech industry is simply pointless, not that all technologies will be replaced. Sure, there are some constants. We can all safely predict that in five years we'll still be writing drivers and middleware in C, still be using zlib and libjpeg, etc...
On the other hand, predicting what changes will occur to a legacy enterprise system tend to be much easier.
In the overall scope of things, Java hasn't really changed that much over the past five years. I think that some long-range planning of the kinds of changes they are thinking about actually makes sense. The need for closures, reified generic types, and an improved type system is unlikely to change in the next 5-10 years.
Hadoop become popular for handling big data, but I'm not sure if many are using Groovy for DSL's. The 2 big uses for Groovy in industry seem to be (1) scripting on Grails, and (2) quick standalone scripts for testing or booting Java code. For these it rocks but the stuff added after Groovy 1.0, such as DSL's, isn't really being used much.
Blackberry remains much more relevant than windows phone. You also forgot to mention Bada which also has more share than wp and is growing. I'm not trying to beat up on wp but as it stands reality conflicts significantly with marketing.
Edit: why the down mod? if I'm in error, please point out where.
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?
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.
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...
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...
I've used Ruby for almost as long, and on MRI at least, I can't think of anything as significant. (JRuby FTW)
Think of c#'s evolution. Ruby's. JavaScript's. SQL's. 9 years isn't exactly blazingly aggressive, but in the context of a programming language it's not eyebrow raising either.
I think generally that's a good thing.
I'm no Oracle fanboi, but I bet without the legal and corporate circus, they will iterate faster.
And business planning is always done like this.
If Java no longer remains useful to Oracle expect the same thing what happened to things like flash.
It will be donated to Apache software foundation.
One thing not touched on in the article but would definitely be worth know is if Oracle will start inserting "pay-to-use" features in the language or release a solid JIT compiler and run time companies must pay for in order to use. I know it's been bandied about in the past that Oracle might start restricting access to some language features and with such a long term roadmap, I'm wondering if they're thinking about making some of these selling point features into business revenue features.
(Fuck boxed primitive types. How about generics that weren't designed by drunk retarded monkeys?)
The problem with Java today is how big and bloated it has become while it doesn't solve fundamental problems programmers face. Its growingly becoming impossible to program in Java without an IDE. Only Java ninjas can probably program Java with a Text editor. Its XML mess all over the place.
Now it takes several tens of lines of code to do trivial file operations and other trivial tasks. This problem was long solved with languages like Perl and Python around 20 years back. Its almost two decades and Java still hasn't caught up. There are still no practical lambdas and good functional programming capabilities.
The issue is something like this. By asking everything to become an API of some sort and writing so many method calls both my unit tests and exception handling code bloats like crazy. My eyes cringe every time I open a Java class file and nearly 60% of the code in there is either try/catch statements or some form get/set methods.
The code to boilerplate ratio is too high. And it just doesn't feel like a language that belongs to the 2010's. Java and its community also promotes heavy use of XML's often used as bad replacements for RDBMS, this leads to building of small buggy and wrongly built DSL equivalents of small parts of SQL all the time.
The path from now is not the make the language bloat like crazy and then provide IDE's to handle that. It is to make the language syntax intelligent enough to take care of many problems you have to other wise worry about. If you see the whole concept of Lisp and other extensible languages like Perl are all about. To provide forms of extensibility that solve the code scalability problem.
And lastly and unfortunately the Java market is full of substandard programmers whose life begins and ends inside eclipse.
A manager or a pointy haired boss might prefer Java for hiring cheap programmers and the 'Oracle factor'. But Java is dead for Start up's and other sexy glorious projects.
I stopped using get/set methods years ago in favor of public instance variables. Yeah, I understand the potential problems with kicking encapsulation to the street and into the gutter (I have written several Java books and I have done many projects in Java, so I am not a noob).
I have also started to favor using unchecked exceptions - that also makes code a lot shorter. This is also Controversial.
Its been a long day, I've been working non stop since 6 am this morning(I stay in India, Bangalore) and its 9 in the night now. I've been working on some Java code.
The AbstractSomethingFactoryFactoryFactoryClasses.java have taken a toll on me. I'm yet to rewind from the depth's of piles and piles of try/catch statements and Object.someMethod() methods buried deep in abyss of com.something.somethingElse.somethingInWonderland.whereTheHellAreWe folders.
But I will take your advice seriously though.
EDIT : After reading your bio and looking at your work on your site. I am your new fan :)
Name calling isn't really helpful. I don't like Java either, but there are a lot of very smart people who worked on it, and many of them labored under constraints I do not envy. That's all.
Their fundamental concern is to milk Java as much and as long as they can to drive their sales for Oracle DB and associated business products. And that makes perfect sense too, they are in business to make money anything else and they won't be doing their job properly. Don't you see what has become of Sun Microsystems? They were making awesome stuff by the day for somebody else's profits. Oracle is not going to make the same mistake again.
Java is oracle's strategic investment in using that as a leverage to drive sales else where. And looking at their segment, its mean't mostly for large corporate programmers and not hacker, start ups and alike.
I bet IBM makes sufficient contribution to COBOL still just to keep their mainframe sales alive and not because they want COBOL to be awesome enough to rule the world.
Similarly Oracle's contributions and investments to Java are going to be for driving their sales not for sake of making Java awesome.
But I downvoted you because this has almost nothing to do with ootachi's comment about the realities that the designers of generics had to cope with. You're just regurgitating the same criticisms that has been leveled against Java for years.
>>What choice did they have?
The only choice Oracle has is to invest in Java in areas that is going to help them sell their products.
That is the only choice Oracle has.
ootachi was was referring to the designers of Java generics, who were working sometime before Java 1.5 was released in 2004, long before Oracle bought Sun.