Red Hat Uncloaks 'Java Killer': the Ceylon Project 623
talawahdotnet writes "Gavin King of Red Hat/Hibernate/Seam fame recently unveiled the top secret project that he has been working on over the past two years, a new language and SDK designed to replace Java in the enterprise. The project came out of hiding without much fanfare or publicity at QCon Beijing in a keynote titled 'The Ceylon Project — the next generation of Java language?'"
Ceylon? (Score:3, Funny)
Am I the only one who read, "Cylon"?
Do they have a plan?
Re:Ceylon? (Score:4, Funny)
Am I the only one who read, "Cylon"?
Do they have a plan?
The 'Cylon' project requires a meta-cognitive processor, not a VM.
Although, I had a similar experience reading about the 'Dalvik' VM... Wha... the DALEK VM?
Finally, it's Red Hat. They have no Plan. The One True God has no frakking patience for RHEL (and neither do I).
Re:Ceylon? (Score:4, Funny)
Am I the only one who read, "Cylon"?
You are not the only one. My first thought was, "I hope they hire Tricia Helfer to advertise this."
steveha
Obligatory (Score:3)
Do they have a plan?
1. Create awesome programming language that kills Java
2. ???
3. Profit
Re:Ceylon? (Score:3)
They do, but they'll never reveal it, and hope that we forget about it two or three years down the road.
Re:Ceylon? (Score:5, Interesting)
Re:Ceylon? (Score:5, Funny)
Re:Ceylon? (Score:3)
Which means it's doomed from the start, no way programmers would choose tea over coffee - not nearly enough caffeine...
Re:Ceylon? (Score:5, Funny)
Am I the only one who read, "Cylon"? Do they have a plan?
No, it's a by-your-command line language. Totally open ended.
Re:Ceylon? (Score:4, Insightful)
If he approached it the same way he did Seam (several different abstraction layers to the point where you're writing and digging through XML and annotations 50% of the time) the answer is simply "NO".
Something to watch (Score:2)
Sounds attractive but very ambitious.
Re:Something to watch (Score:5, Interesting)
Re:Something to watch (Score:3, Insightful)
The selling point to the enterprise is the JDK. If it was all about a better language that develops quicker they could have gone for Ruby years ago. In particular once sun brought JRuby in-house. The issue at hand is the Enterprise wants the bloatware in the J2EE SDK. Those classes and libraries represent a lot of work a developer doesn't have to figure out themselves.
Re:Something to watch (Score:3, Insightful)
What? Those classes represent a lot of work the developer absolutely has to figure out themselves. Nobody just looks at J2EE and goes, "hey, that makes sense." J2EE costs time and money, it doesn't save time and money.
Re:Something to watch (Score:5, Insightful)
Yes, but it also means you don't have to figure out how to persist your objects to your database, how to transfer them seamlessly from one box to another in a load balanced environment, how to manage the lifetime of per-user and per-session objects, how to set up your system to locate the URLs of your web services, how to send messages from one object to another on a remote machine, how to store your resources so that they can be altered without recompilation, and many other things...
Sure, J2EE takes a while to learn. But it provides a whole load of features that would take a lot longer to write if you had to do them from scratch.
Re:Something to watch (Score:3)
J2EE costs time and money, it doesn't save time and money.
Every language costs time and money to learn. In Java's case it's not the language so much as all the technologies that are built with it. That, in a nutshell is why any replacement for Java has to be as close to 100% compatible as possible. You literally want to be able to sit a Java developer of any competence in front of MiracleJ or whatever the language is called and for them to not notice much difference. It should feel comfortable, familiar. It should build the mass of code they likely have to maintain.
As time progresses of course, you can wean them off the horrible crud / boilerplate they're used to and show them all the shortcuts, notations & new features that cut down the code they have to write. Much in the same way as happened in C to C++ migration. C++ was seen as C but better (yes I know there are very slight differences) so virtually every developer migrated across in due course. It should feel so natural to migrate that you have to have very explicit and esoteric reasons for staying put.
Re:Something to watch (Score:3)
So let me get this straight. It's better for someone to take, for example, C, or Ruby, or PHP and implement roll their own implementations of:
1. Thread pool management
2. Load balancing and fail-over
3. Session replication
4. Distributed transaction management
5. Naming directory
6. EIS connection management
7. Pluggable authentication and authorization
8. HTTP request parsing and invocation
9. Tags and markup for data binding / AJAX support
10. UI component model
11. Logging
12. Web service management and deployment (including WSDL generation and publishing)
13. XML binding (marshaling and unmarshaling)
14. And so forth and so on
Now in this scenario the implementations will likely:
1. Only implement the functionality that is (perceived to be) needed
2. Will not be tested
3. Will not have the benefit of community scrutiny, certification, or knowledge
4. Will not be immediately understood by any developer other than the author(s) regardless of how much experience they have
Yes, you have to invest to learn JEE.
Yes JEE deals with complex issues and as a result is difficult to understand.
However, having invested that time, anyone who knows it in one place knows it everywhere. That is what saves time and money -- being able to hire someone who already knows JEE and have them hit the ground running.
Further, having a prescribed solution for many common problems allows developers to focus on the business needs, not the boilerplate.
Anyone who does not appreciate what JEE brings to the table is not a serious enterprise developer.
Re:Something to watch (Score:3)
Well, I tried a lot of the things you mention. However
I'm not really sure why you mix languages and technologies in you sentence that have nothing in common with each other and a few of them are even JVM languages (which means they need J2EE support anyway).
As I pointed out most people don't actually use J2EE in the way it was originally conceived.
Most people use a Tomcat, Spring and Hibernate, thats it. If you want to have an app server (JBoss etc.), you should have a reason for it.
For me it is absolutely no difference in what environment I debugging, first of all debugging takes perhaps %1 of my development time. I don't debug framework code, unless I'm sure the bug is there. Second we mainly have test cases on use case level, if I need to debug something I start that "Test" in debug mode.
Regarding deploying, I cant see any significant difference between deploying a PHP Application under Zend or a few *.war/*.jar files under Tomcat.
Well, frankly your post looks like if you just have put lots of buzzwords and frameworks/languages into one long sentence. ... don't get your point ... dead end why should I use that?
C# -- does not run everywhere, mediocre support regarding equivalents of J2EE
PHP -- half interpreted, not really compiled, flawed runtime library
Ruby -- just not my taste language wise, but also reinvention of lots J2EE features, basically useless without RAILS
Python -- just a language
Clojure -- runs on the JVM and is a Lisp dialect
Smalltalk -- again only a language, as soon as you wan't to do big scale stuff you also need frameworks
Haskell -- a language, what support does it have for scaling large applications I don't know
CakePHP -- obviously for PHP
Zend Framework -- PHP
GWT -- pretty useless without J2EE behind it, so what is your point?
Cappucino -- looks promising on the client side, that leaves again open the server side
Zope -- is a python framework/runtime engine, it is difficult to scale
ASP MVC -- a MS technology like C#
Grok -- based on Zope if I'm not mistaken
Rails -- well, based on Ruby, see above - basically only really useful for simple DB and page driven web applications
Sinatra -- again a Ruby web framework
I doubt idiots with fat wallets demand J2EE. Most of the time they demand:
* Java
* has to fit into our backend infra structure
* has to access our databases
* new databases (for this application) should run on the same software
* has to scale
* my own programmers need to maintain it (hence the requirements above)
* needs to be open so future extensions / services can interoperate with it
Anyway, the main critics about J2EE comes from the time when it was "invented" ... it has evolved considerably since then.
Usually you have only a little effort when you set up the project for the first time. As soon as you start working on it you mainly program POJOs, easy to test with unit tests, and the interaction among them via the frameworks are easy to test with scenario driven tests. If you have to debug, you lack experience (or someone in your team who is responsible for the fact that you have to debug). Keep in mind: with hot code replacement most developers program in the running environment in debug mode anyway (that excludes me, as I prefer to "clean room" develop my code and think while I work and see if the test runs).
So, how would I develop a huge new application?
GWT for the frontend, development of server components in Scala and Java, glueing it together and giving functionality close to the front end with Groovy. Testing with JMeter (backend Services) and Selenium (Web Pages) and JUnit for low level stuff if needed, backend access likely directly on the DB with iBatis, or via dedicated backend services which are best accessed via REST.
Small scale applications: GWT for client, hibernate/iBatis services as GWT server components. The only J2EE you need here is a tomcat (or similar) an
Re:Something to watch (Score:3, Interesting)
Oracle have threatened to sue anyone and their aunt Mildred if they step out of line on the Java standard or violate any Java-related patent. Apache needs a JVM-type system to run Tomcat and Debian will supply patentware over their collective dead bodies (once an open-source license for dead bodies is agreed upon). Red Hat knows this. Red Hat also knows that commercial vendors like Adobe (Cold Fusion runs on JRun, a servlet engine) like Java because nothing makes for bigger profits than free. Patent-based lock-ins don't usually mean free. Sun killed JScript, sure, but we're talking proprietary extensions and a platform-specific compiler designed by Microsoft for the sole purpose of killing Java. It was a digital gunfight and it's not surprising Sun used the guns it had.
Oracle, on the other hand, already uses proprietary extensions (they bought JRockit and it has all kinds of weird stuff), platform-specific compilers (you'll notice real-time Java isn't available for that many OS') and proprietary implementations (JDK7 doesn't include some of Oracle's accelerations to JDK6). Language dilution - and the inevitable long-term death of Java as a result - isn't an issue for them. They're not using patents to protect Java, but to protect a virtual monopoly.
Re:Something to watch (Score:3)
Sounds attractive but very ambitious.
Let's not forget that Microsoft has thrown its weight behind the .NET platform which is arguably superior to Java in many (but not all) ways and they still haven't even dented the popularity of Java.
Part of the issue is that Java just works. It may be verbose, horribly broken in some respects but it still works. The only way you're going to wean people of vanilla Java is to produce a Java++, something which compiles syntactically correct Java with no modifications, supports all existing Java libs with no modifications, but offers some rich extensions that reduce the amount of crud / boiler plate developers have to write and hopefully eliminate a bunch of potential bugs too.
No language which is not a superset of Java really stands a chance. People promoting Scala, Google Go, Ruby or similar are pissing into the wind on this matter. It has to be a superset, or close to one of what already exists. Arguably even Groovy isn't close enough. I hope Red Hat take this on board and look at the limited success that other Java wannabes have enjoyed so far.
Aside from the language aspect I think Apache & Google would be the natural partners to promote this language. I don't know how that sits with Red Hat but really there needs to be a consortium of heavy weights to promote mind share amongst developers and popularise a migration. I expect most Java developers would be happy for walk away from Oracle / Suns pathetic stewardship if there were something better and compatible to go to.
Re:Something to watch (Score:3)
In what way is Scala not a super set of Java?
Re:Something to watch (Score:3)
Re:Something to watch (Score:3)
What in god's name makes you think we want the legions of mindless Java programmers to join us?
Because Scala, JRuby, Groovy, Clojure ... (Score:3, Insightful)
aren't enough (damn subject would have dropped the 'h' and that would have made me cry).
We need yet another JVM language to 'kill' Java. Epic. Brilliant.
The other languages were developed much more openly, not dropped like an MS product. Get real, Red Hat.
Re:Because Scala, JRuby, Groovy, Clojure ... (Score:3)
In all honesty, all the projects that you've listed make their stated goal to be less "enterprise" than Java in overall feel. Whereas here the authors specifically say that they want to kinda get to where Java would have been, if it were designed from scratch today rather than in early 1990s.
Re:Because Scala, JRuby, Groovy, Clojure ... (Score:4, Insightful)
here the authors specifically say that they want to kinda get to where Java would have been, if it were designed from scratch today rather than in early 1990s.
Um, then they would have it natively support the entire Unicode repertoire rather than remaining in the 16 bit trap that Java fell to along with other platforms of that time.
Re:Because Scala, JRuby, Groovy, Clojure ... (Score:3)
Java has been using UTF-16 (which "supports the entire Unicode repertoire") for ages. If you access individual chars in a string, you've got to handle surrogate pairs on your own, sure, but why do you even do that? Stock string methods can handle it all just fine.
Re:Because Scala, JRuby, Groovy, Clojure ... (Score:4, Informative)
In this case, yes. Just like UTF-16, UTF-8 can encode any Unicode character up to 31 bits (U+7FFFFFFF). Since both are variable-length encodings, UTF-16 is no simpler to work with. UTF-8 has the additional advantages of being identical to ASCII for the first 128 codepoints, using a single byte order vs. big-endian/little-endian UTF-16, not embedding NUL characters, generally taking less space, not being confused for UCS-2, etc.
See also: advantages of UTF-8 compared to UTF-16 [wikipedia.org]
Re:Because Scala, JRuby, Groovy, Clojure ... (Score:4, Insightful)
I have an issue with people throwing away the excellent JVM just to use a new language.
Right at the top of The Friendly Article, for which a link has been conveniently provided: "It is built to run on the JVM".
so much effort has gone into making it portable, secure and reliable, why re-invent that.
Because of the patents held by Oracle? It's still up in the air as to whether or not those patents mean anything, but if they do, then we may be forced to reinvent it.
No need to duplicate work (Score:5, Funny)
We already have a Java killer; his name is Larry Ellison.
Re:No need to duplicate work (Score:5, Funny)
One Rich Asshole Called Larry Ellison.
Poetic.
Re:No need to duplicate work (Score:3)
One Rich Asshole Called Larry Ellison.
Poetic.
Someone should mod this up.
I would but Larry Ellison won't let me...
Java killer? (Score:5, Insightful)
A "Java killer" that relies on the JVM to run sounds like it's in for an uphill battle.
Writing an SDK from scratch in a homebrewed language that does everything the Java SDK does? Well, good luck anyway.
Re:Java killer? (Score:3)
Writing an SDK from scratch in a homebrewed language that does everything the Java SDK does? Well, good luck anyway.
why not ? if enough people decide it is a good idea and participate, it may take much shorter than you can imagine.
the open source community now knows open source effort works. linux prevailed, firefox prevailed. people have self esteem and faith now, and know the ways to make it work. now, they will make work, whatever they decide to make it work.
Re:Java killer? (Score:5, Insightful)
if enough people decide it is a good idea and participate, it may take much shorter than you can imagine.
Designing and implementing a new programming language that's intended as a direct challenge to Java... by committee... using a distributed development model... "much shorter than I can imagine"? Have you followed the history of Java at all? Or of any language?
linux prevailed, firefox prevailed.
And both were written in a language people already knew.
Re:Java killer? (Score:3)
now, not only we are mature, but also we have endless number of tools to facilitate distributed development.
yes, indeed, with the variables given, one thing that is certain is that it would be much shorter than before, to develop an entire language, using the distributed development model now.
Re:Java killer? (Score:5, Insightful)
There's some truth to that, but it also reminds me a bit of my eight-year-old neice talking about how different everything is now compared to way back when she was seven. :)
Starting to show indications of maturity yes. Achieved maturity -- not quite yet I think.
Re:Java killer? (Score:3)
If you polish a turd enough, sometimes it can disappear completely...
Re:Java killer? (Score:2, Interesting)
The problem is this doesn't "throw out the things that are flawed in the original java" - quit the contary.
(and TFA loses additional points for using Microsoft's smart quotes as demonstrated above)
Any experienced c++ programmer will tell you that "classes if necessary, but not necessarily classes" is the way to go. Class explosion is not pretty, and makes for over-complex stupid implementations.
Oh look, someone revived the Clipper dBASE compiler / Pascal syntax.
If you REALLY want to fix it, add the things that are missing:
Kill off interfaces (even James Gosling admits that they were probably a mistake), add multiple inheritance.
A c/c++ style macro compiler and #include system
Re:Java killer? (Score:5, Insightful)
When trying to design a new, clean, high-level programming language, I probably wouldn't pay much attention to C++ rules of thumb.
Making everything behave like an object can make things much cleaner. It all depends on how exactly this is done, but a lot of complexity in Java comes from the fact that primitive types behave differently. C# did a bit better, but there's still the value-vs-class distinction which can trip you up in subtle ways.
Re:Java killer? (Score:3)
Making everything behave like an object can make things much cleaner
In a perfect world probably. But have you considered that there's a reason why primitive types are left as primitives even in C# (which had the opportunity to correct the mistakes Java made).
Primitives are kept because they are fast, and objects are blinking slow. You don't notice this when you use a relatively few objects, even then because they contain primitives themselves. Turn those into nested object hierarcies (as you'd get if even an int was an object) and your app'd run slower than 1.0 Java in an interpreter on a 200Mhz machine!
that's the main reason, there's also another case that objects everywhere don;t necessarily make for maintainable programs, in theory yes, but in practice call stacks like spaghetti is seen too often.
If you want to clean things up, then altering the concept of an object is probably what's needed - you want to separate data from functionality, so your data can be small and tight; then you need a nice way to associate methods with the data. Classes do it at the moment in a particular way, but there's no reason why the compiler cannot do it a different way under the covers.
Re:Java killer? (Score:3)
I'm not suggesting that primitive types be implemented using the mechanics of regular objects. I'm just saying that they could be made to appear to the programmer like regular objects. Combined with certain restrictions (e.g. no extending from primitives) and some compiler tricks, this can be made to work efficiently. The fact that Java's primitive types are all immutable makes this even easier -- immutable objects are very well-behaved.
And sure, your performance might suffer if you're not careful, but I don't think that's necessarily worse than having to force people to deal with the primitive/object difference even when they don't particularly care. It's kind of like the autoboxing situation today. If you're not careful you could end up with a bunch of unwanted boxing/unboxing operations. So when I need to be careful, I am. But when I just want to get something done, it's way easier to just let the autoboxing happen.
Re:Java killer? (Score:3)
It's amazing that Scala manages to be blazingly fast, then, given that it's primitives are all classes. Maybe you should tell them that they;re obviously doing it wrong.
Re:Java killer? (Score:3, Insightful)
Maybe I'm stupid, but how does having everything behave like an object preclude operator overloading, multiple inheritance, or a preprocessor?
Re:Java killer? (Score:5, Insightful)
1. GC implementation is not a language feature, it's a runtime feature. This has nothing to do with Java as a language. Furthermore, any sufficiently complex C++ program implements some form of (at least) semi-automated garbage collection; even if it's just reference-counting smart pointers. You apparently have no experience writing real software.
2. Really though, are you seriously arguing against non-deterministic GC because you think every program in the universe should be "well-behaved" and "provable" (on your own terms)? We might as well toss out, gee, I dunno, almost every modern language under the sun while we're at it. I think I can count on one hand the number of languages in regular, widespread use today whose standard runtimes leave memory management exclusively up to the programmer.
3. If you're really going to go down the "provable" road, you'd better throw away your C++ compiler too. Without referential transparency, C++ is practically useless as a language that facilitates "well-behaved" and "provable" code. Haskell for you.
4. "Class explosion?" This sounds like a term that would be used by a C programmer who writes C code inside of C++ classes, but who doesn't actually design object-oriented programs. "Classes if necessary, but not necessarily classes" would be exactly the kind of tripe I would absolutely never expect an experienced C++ programmer to say.
5. Meta-language (preprocessor/macros) is not language. Similar to point #1 in that it has nothing to do with the language itself. You could build a simple preprocessor for Java code if you felt so inclined (there are a small number out there already). It's a separate tool though. #define is not part of the C++ language in any way. It's part of the CPP language.
6. Kill off interfaces? No. What? I see problems with interfaces, but as a general idea they are not something to be killed off. Rather, I'd like to see the adoption of a more flexible "interface" system much like Go's. And multiple inheritance doesn't even make sense unless you like your objects to be schizophrenic, but please see point #4. The part about not understanding OOP.
7. Finally, you're cutting into a language like Java, while strongly defending an equally flawed language like C++. From your ranting it seems as though you don't understand either one (or many other languages, for that matter) well enough to comment on them. Yet here you are, vomiting invective upon the weary masses of Slashdot.
8. *Smack* Now go read something and stop face-rolling your keyboard. Thanks.
Oh and on-topic. Ceylon sounds interesting. I'll play with it. "Killing" Java will require billions of dollars though.
Re:Java killer? (Score:4, Informative)
Sheesh, obviously I hit a sore spot :-)
Finalizers are a language feature. The fact that a finalizer is not guaranteed to ever run, not when your class does the java equivalent of c++ "out of scope" (no valid references left to it), or even on program termination, is a language flaw. The runtime just surfaces, or exposes, that flaw.
Would multi-threading real-time data servers that never kill off a thread from their thread pool between startup and shutdown months later while serving a thousand requests a second (because they never lose a byte of memory) qualify as "sufficiently complex"? No reference counting needed - just well-behaved code, and contracts between the loadable modules and the server as to who owns what memory.
It's called the "Dear Abby" school of memory management. If you pick it up, put it back when you're finished. If you give it to someone, either make sure that they know that they're expected to put it back when finished, or make explicit arrangements for them to return it to you so you can put it back.
It's not that hard to get right if such an obvious dummy as I can do it, right?
Finalizers in java can end up being just so much dead code, even on runs on the same machine. That's the sort of non-deterministic behaviour, where the code says one thing, but the behavior is "undefined" even between runs, that cries out for fixing. That's not "arbitrary" - that's a bug.
Every non-trivial c++ program contains a fair chunk c code inside classes. All those flow control statements ... for(), if(), else, switch(), break;, continue; they're all c, not c++. Same with all the non-overloaded operators. You can't write a c++ program without using some c code. Here's a hint - look at the declaration for main().
"Classes if necessary, but not necessarily classes" is a rule of thumb a lot of us use; in my case, it's because, before java was ever even a gleam in JG's eye, I tried the "make everything a class" idiom, and ran into the same class explosion problem everyone does. Some people think that a proliferation of classes shows how great they are at coding. I don't. Classes, like everything else, are just semantic tools for managing complexity. Nothing more. Anyone who invests them with more meaning than that doesn't understand what's actually going on behind the scenes - your classes aren't real "objects" - just a series of bytes handily organized to do the job.
The pre-processor is an integral part of every c implementation, always has been. And what is this CPP you speak of? The c pre-proces
Re:Java killer? (Score:3)
"Classes if necessary, but not necessarily classes" would be exactly the kind of tripe I would absolutely never expect an experienced C++ programmer to say.
This particular argument can be bolstered by looking at either Python or D. It can improve many programs.
Also, "garbage collection" shouldn't be purely a run-time feature. In a proper language you design the language differently when garbage collection is present than when it isn't. Clearly, however, one should be ABLE to request that an object be garbage collected at a particular point. But it should be a request, not an order, in case there are still references to it dangling around somewhere. (Actually, that would really be a request that garbage collection be initiated immediately, since you need to check all pointers anyway.)
Also, pointers should be separate from arithmetic values. It should be impossible to convert from an arithmetic value to a pointer (though not necessarily conversely). This greatly simplifies garbage collection.
The compiler should be smart enough to handle basic classes (int, etc. should be classes, with normal class syntax except that literals exist) with special consideration an convert them into things that the CPU can directly handle. But in the language they should be classes (except for the special literal syntax). Thus a string is a class although a literal string might be written "a string". And literals can use standard class notation, thus 1.add(3) which is what 1 + 3 would be sugar for.
The major flaw *I* find with Java is the incredible mess it makes of I/O (but some people seem to like it). A less basic flaw is the mess it made of generics. I understand that this was to maintain compatibility with older code, but it's not worth it. A different answer should have been found. I guess it's a matter of taste, but I really dislike the classes wrapped around classes wrapped around classes kind of syntax that Java promotes. (It's not inherent in the language, but in the esthetics of the library designers.) I can see the utility, but it's really ugly, and a different approach should have been found. But that might have required either multiple inheritance or mixins.
Re:Java killer? (Score:4, Insightful)
It's been ages since I worked with Java, but even if I hadn't been hearing for years how far Java's come since the bad old days, I'd feel compelled to call you on some of this bullshit...
A note before I start: I mostly work on video games, and I use a mix of C++ (engine), C# (custom build tools, editors, etc), various scripting languages (Lua, Python, etc: some embedded in the engine, others for automating aspects of the build). I've also written the odd business app in C# and, way back when, Delphi.
it just results in having to write a bunch more classes because the language is lacking in basic flexibility
On the contrary, one often wants simple values to behave like objects, such as when one wishes to declare groups of arbitrary values for serialization or the like. Having the compiler or runtime autogenerate an object version of your value types and provide a simple syntax for converting between the two forms is a huge time saver and spares one from writing a lot of tedious code.
it just results in having to write a bunch more classes because the language is lacking in basic flexibility
It also lacks the diamond problem. I mean, yeah, a competent programmer can work around that, sure. A competent programmer can also structure his code such that it doesn't require MI, without needlessly complicating anything.
no preprocessor
Nothing stops you from using C's (or any other) preprocessor with Java (or any other compiler that takes text files as input). That's where C++'s preprocessor (which most good C++ programmers recommend avoiding) came from, you know. Actually, in the bad old days, C++ itself was a preprocessor...
because the programmer "can't be trusted."
Because a programmer writing business apps has more interesting things to think about than making sure that his colleague remembers that foo() returns an object out of a memory pool which shouldn't be deleted or referenced beyond the end of the current transaction, whereas bar()'s return needs to be freed by returning it to a free list, and whether he can afford to pay the extra allocations and cache misses necessitated by returning shared_ptr wrappers that remember that for his colleague, or whether it's time to sit down and write two whole new pointer-wrapping classes (and if those wrappers use a reference count, should we put it in the object or allocate that from some special pool...), or whether he should return raw pointers and make a note to spend a few minutes during every future code review checking that they're not being misused...
Wait, where did shared_ptr come from? Why am I thinking of writing classes to wrap pointers? I just want to return a dynamically allocated object! What happened to not writing extra classes?
Throw in a non-deterministic garbage collector
The GC is, like all other software, entirely deterministic - in exactly the same way that malloc/free and new/delete's continue to behave deterministially when the heap becomes fragmented. The phrase you're looking for is "as strictly defined as my arbitrarily chosen reference point". Millisecond stalls at unspecified intervals to transparently collect garbage are entirely within the definition of well-behaved for a very large class of software.
At least in c++, you're guaranteed that when the stack frame is popped as your object goes out of scope, your destructor is called immediately.
And a language in which 95% of objects don't hold non-garbage-collected resources doesn't need destructors, let alone deterministic ones. The other 5% have a method called something synonymous with "close" on them, and competent programmers remember to call those functions, just as you remember to call (or write/use a class which will call) delete or free on the 95% of objects whic
Re:Java killer? (Score:3)
Jesus wept. You're seriously just saying that Java would be better if it was C++?
I've programmed professionally for both of those languages for a number of years. Java became wildly successful mainly because it was an alternative to steaming piles of shite like C++. I have no doubt that Java will be superseded eventually - perhaps by Scala - but definitely not by going back to C++.
Re:Java killer? (Score:5, Insightful)
*citation needed*
Everything I've seen from Gosling says that pure interfaces are the way to go- even to the extent of getting rid of regular inheritance; see these quips [blogspot.com]. I don't think anybody who's seriously looking at language design thinks C++- style multiple inheritance is a good idea. Nor does anyone want to resurrect the braindead C preprocessor way of dealing with things.
And what's so bad about :=? The fact that some outmoded languages used it doesn't make it a bad idea. Most of us are familiar with its use as a definition or assignment, and avoiding confusions between = and == could be a plus, especially if (as he seems to propose) the latter is extended to replace use of .equals().
Re:Java killer? (Score:3)
This is a case of "we don't trust the programmer to get it right", same as the lack of multiple inheritance and the stupidity of interfaces as a work-around.
Re:Java killer? (Score:5, Insightful)
Anyone who wants Java to allow overloading of == clearly has never had to deal with C# code (C# allows overloading).
The fundamental problem is that people don't understand Java semantics. In Java, equality testing is consistent and efficient: for reference types (everything except primitives), == always means reference equality. And .equals() always means value equality.
Comparing strings with == sometimes works because the runtime allocates string constants from a pool. So ("A" == "A") evaluates to true because they reference the same object. But ("A" == new String("A")) evaluates to false.
The key here is that object variables in Java are *always* references. That's why any object reference can be null, and it's why you can't compare them with ==.
The problem with overloading is that it's not consistent. Some C# objects overload ==, some don't. There's also ".Equals()", which always checks for value equality. There's also the static method Object.ReferenceEquals(), which always checks for reference equality.
So you end up with this trap where you either end up using Equals() all the time (as you do in Java), or you have some code that uses Equals() and some code that uses ==. Which doesn't make sense.
Java is about consistency and predictability. Having operators do different things in different contexts results in neither.
Re:Java killer? (Score:3)
Java vastly simplifies a whole ton of conventions by making every object variable a reference.
Everything in Java is passed by value. And every object variable is a reference.
The value of Java is that the designers know how to say "no". Adding more features to a language dramatically increases the chances that code will do something unknown or unexpected. No language is free from that sort of mistake, but Java is significantly more consistent and predictable than most languages.
Re:Java killer? (Score:3)
Those two statements are mutually exclusive :-)
Objects are passed by reference, which means that NOT everything is passed by value. Only the reference to the object is passed by value :-)
Both the garbage collector and finalizers are unpredictable. You are never guaranteed as to when the garbage collector is run, and finalizers thus may not be called until your program terminates - and in fact finalizers may never be called.
This is one of the reasons why, even after so many years of saying that they'd come out with a jvm that can handle multiple programs at once, they haven't - it's been totally abandoned [oracle.com] because the jvm needs to terminate so the OS can reclaim resources that the jvm failed to release because the gc and finalizers are both broken.
Now, in c or c++, the startup library is tiny - around 3k. It sets up the memory arena, the program environment variables, a bit of housekeeping, then jumps to main. The startup library for your java program is the entire jvm instance that has to be loaded into memory. This is not a fixable problem.
Re:Java killer? (Score:3)
Re:Java killer? (Score:4, Insightful)
Operator overloading, like many C++ features, is great until you have to code with other people.
Re:lvalue on the right (Score:3)
You're not always comparing with a constant; far safer is to wrap the variables with accessor methods, so you get a break if you try
if (objectA.getX() = objectB.getX())
It might be a bit more effort to type up, but it catches a bunch of easy gotchas.
Re:lvalue on the right (Score:3)
Oh wow, are you serious? If this is the kind of verbosity that Java requires, I am definitely not sad to not be a Java developer. Guess the toy dynamic languages (Python, etc) have spoiled me.
Re:lvalue on the right (Score:4, Interesting)
You have obviously never been on a *huge* software development project. The reason you use accessors and mutators (getters & setters) is so you can change the underlying representation without breaking all the uses in you million lines of code.I've had to make changes to underlying representation without breaking th client contract (signature). This is why such practices are used (plus, these methods are auto-generated by most tools anyway).
Well, in Ruby (which is a fully OOPL) getters and setters are used too, but the language syntax allows you to define methods such as 'property' and 'property=' so that setters and getters look exactly like direct access, and much less verbose than the dreadful getPropX() and setPropX() methods you usually have in Java or C++.
Re:lvalue on the right (Score:3)
Or maybe you should use a compiler that warns when "=" is used in a conditional expression, and compile with "warnings as errors".
Re:Java killer? (Score:3)
If you REALLY want to fix it, add the things that are missing:
Kill off interfaces (even James Gosling admits that they were probably a mistake), add multiple inheritance.
They didn't do that, but they did allow to provide concrete methods with bodies in interfaces, which makes them much more like mixins. This actually takes away most of the problems, since you're only restricted to classes for when you need state, and multiple inheritance for state is almost always a bad idea (in C++ as well). The reason why Java interfaces feel so limited in comparison is because they don't contain any code, thus artificially limiting code reuse.
A c/c++ style macro compiler and #include system
Gods, no. If you suggest adding a macro system to the language, at least point to Lisp as the inspiration, not the braindead fuckup that is C/C++ preprocessor. I mean, seriously - the wretched thing that is the latter does not even use the same tokenization rules as the language itself - how much do you have to smoke to design that?
Re:Java killer? (Score:3)
Oh look, someone revived the Clipper dBASE compiler / Pascal syntax.
This is called the becomes operator. I think it was introduced by Dykstra, a well-known computer science professor. The idea is that it is mathematical more correct than the equals (=) operator, as you can do: x := 3;
x := 4;
Personally, it's not my favourite (I prefer =), but I do think that it leads to less if(a = b) { ... } mistakes than using the = and == operators from the C language
Re:Java killer? (Score:3, Insightful)
The LAST people in the world I would ask for advice on programming language design would be people who think that C++ is a good language. That's like asking the blind for help with the colour scheme for your house.
Consistency is good which is why everything being an object is good. You can treat 'primitives' as being classes in terms of the language design while still implementing them as primitives in VM/byte code for optimisation purposes. Special cases / Corner cases are bad.
Multiple inheritance is the devil's spawn. The diamond pattern deserves it's own special level in hell. Interfaces are better - may I point out that Smalltalk used single inheritance with interfaces - so Java is much MORE traditionally OO in that regard than C++... but I digress. Mixins/traits are a much better solution still and are, I believe, the only solution a sane OO language designer should use these days.
Re:Java killer? (Score:5, Insightful)
why not ? if enough people decide it is a good idea and participate, it may take much shorter than you can imagine
I don't think you grasp how much Java stuff is out there already, even open source, and how many years it took to produce.
Open source isn't like a magical brownie cobbler that fixes your shoes in the night if you leave him a little saucer of milk. Sometimes it duplicates its effort, so to speak, for no good reason but I wouldn't bet on it on a massive scale any more than I'd bet on winning the lottery, except someone actually does typically win the lottery.
Re:Java killer? (Score:3)
Open source isn't like a magical brownie cobbler that fixes your shoes in the night if you leave him a little saucer of milk.
Yeah, that would be bizarre, rather than cathedral, I guess. The church frowns on the wee folk.
Re:Java killer? (Score:5, Insightful)
A new language that relies on an x86 processor to run sounds like it's in for an uphill battle....
There's no reason not to use the JVM. It's a highly optimized, widely distributed virtual machine (just like x86 processors are highly optimized, widely distributed actual machines).
Now Java as a language... leaves something to be desired.
Re:Java killer? (Score:3)
Python is slower because it's a highly dynamic, interpreted language, and it's interpreter has also gotten a lot less attention than Java's compiler. Java is a compiled, much less dynamic language.
If by "compiled language," you mean that the first step in running a program is transforming source code into some other form, then both Python and Java are compiled languages (as are the vast majority of commonly-used language implementations). Both Java and Python implementations use compilers that transform source code into intermediate forms (byte code). In both cases, very little run-time optimization can be done at that level AFAIK.
The use of compilation is not truly a property of a language, but of an implementation of a language. For example, in addition to the official implementations, there are implementations of both Java and Python that transform source code into native machine code ahead of time, bypassing any byte code.
When talking about compilers, you also have to be careful about which compilers you're talking about. Most implementations of Java use a JIT compiler which transforms Java byte code into native machine language at run time. The official implementation of Python (CPython) does not have a JIT compiler, but there are several projects which add a JIT to CPython, including Unladen Swallow [google.com] and Psyco [sourceforge.net].
I want to be extremely clear that I was not comparing the maximum execution speed of equivalent Python and Java programs, since Python will probably never rival Java in that way. I was talking about the suitability of the JVM for executing programs written in languages that are very different from Java, such as Python. Jython [jython.org] is an implementation of Python that does just that, but has only recently caught up to regular CPython's performance, even though it benefits from the JVM's JIT compiler.
As much work is being put into increasing performance of CPython, I think PyPy [pypy.org] is much more interesting. Though PyPy is written in Python and a subset of Python called RPython, it can execute Python around three times faster than regular CPython or Jython.
You're right, a regular JVM might not do such a hot job of working through all the code generated by something like Python, but it could be used effectively with a language that is less annoying than Java while still being fairly static.
I doubt Ceylon is going to be a language I'd be much interested in. Python + Cython + C is a pretty potent combination for pretty much everything. It might be good for some things though.
I haven't tried Cython yet, but it sounds very interesting and I'll definitely try it when it seems appropriate. However, if just increasing performance is a goal, simply using PyPy might be just as good as Cython if examples like this [wordpress.com] are to be believed.
Re:Java killer? (Score:3)
In standard usage, saying X is a Y language refers to the canonical implementation of X. So Python is an interpreted language means CPython is interpreted, and doesn't refer to any of the experimental JIT versions.The Python that everyone actually uses is an interpreter that works with an intermediate bytecode representation. The Java everyone has uses a just in time compiler. The difference is kind of hazy sometimes, but there is enough of one to talk meaningfully about Python being interpreted and Java being compiled. (http://en.wikipedia.org/wiki/Interpreter_(computing))
I say that in "standard usage," a compiled [about.com] language [dsbscience.com] is one whose implementation produces an executable, native code file. By that definition, Java is not a compiled language (unless you use GCJ or another non-canonical native code compiler). Which standard are you using?
If you want to say that an "interpreted language" is distinct from a "compiled language," where does that leave Java? Most implementations involve both compilers and interpreters. The most commonly used implementations currently use Java byte code interpreters, with JIT compilers that generate native code from some of the byte code. They are completely functional with the JIT turned off, but can't do anything without their interpreters. While it is useful to describe a language implementation as using a JIT compiler, to simply call it a "compiled language" is not, since an increasingly overwhelming majority of source code is compiled at some point.
Since you mention "canonical implementation," what is the canonical implementation of Java? Is it whatever you can download from Oracle [java.com] at the moment, OpenJDK [java.net], IcedTea [wikipedia.org], whatever comes with your OS, or something else? The early releases of Java from Sun did not have a JIT compiler. Did Java suddenly transform from being an "interpreted language" to a "compiled language" when Sun started including the HotSpot JIT compiler?
Don't forget to read to the bottom of that PyPy blog article. PyPy is certainly an impressive tool, but you can get a big improvement with something like Cython that lets you give the translator hints. The actual benchmarks:
CPython: 59.593 s
PyPy: 8.947 s
Cython: 3.5 s after adding a few types
Adding a few types in Cython means statically typing a few heavily used variables. His other (approx. 26 s) result with Cython I can only assume involved just Cythoning his straight Python code, which isn't really what Cython is supposed to do. The beautiful part of Cython is that you CAN give it straight Python code, or straight C code, or anything you want in between.
Yes, Cython clearly does have great advantages in speed over pure Python code and I shouldn't have implied that it didn't. I certainly will consider using it if I find some Python code that's running too slowly. However, that blog post also didn't compare an implementation in RPython, PyPy's Python-like language which also executes much faster than full Python.
Re:Java killer? (Score:5, Interesting)
Reinventing the VM is a waste of time. And there are tons of languages to choose from for those VMs. So I don't quite see the point of this. The slides appear to be slashdotted, and just from the post's talking points... yawn.
* "nobody" here should be read as "very few", i.e., mostly people who write JIT compilers and not people who write enterprise code.
Re:Java killer? (Score:5, Insightful)
C# started out essentially the same as Java. But at this point it's way better.
Re:Java killer? (Score:3)
Having a VM that's not at the mercy of Oracle would, to my mind, be a huge plus. But Oracle's war against Google shows just how fraught with risk that could be.
Re:Java killer? (Score:5, Insightful)
My favorite part about the post is that he points to C# as an example of a "good" language, as if C# and Java were not essentially the same language.
They aren't. C# 1.0 was essentially Java with syntactic sugar, yes (properties, events, delegates, enums, varargs, ...), but syntactic sugar can make a lot of difference in practice for readable and understandable code. It also had some nice parts such as unsigned types, stack-allocated user-defined value types, and raw pointers - all that mostly useful for efficient interop with C libraries, but it's a surprisingly common scenario even today.
C# 2.0 added iterators (what Python calls "generators" - functions that produce a lazy sequence of values using some nice syntactic sugar), fully typesafe generics (no type erasure), and, most importantly, full-featured closures. A minor addition were nullable value types (unlike Java, you use strongly typed box types like Integer for the same, C# nullable value types are not boxed and therefore do not require heap allocation).
C# 3.0 added type inference for local variables, array literals, and closure return/parameter types; and sequence comprehensions (rebranded as "LINQ"). Minor additions were tuple-like anonymous types - "new { foo = 1, bar = 2 }"; and array-like literals for arbitrary collection types - "new List<int> { 1, 2, 3 }".
C# 4.0 added "dynamic" type, which is essentially opt-in duck typing. Another big addition is covariance and contravariance for generic type parameters - making e.g. "IEnumerable<Object> objects = new List<string>()" valid. Minor additions are optional method arguments, and named (what Python/Ruby calls "keyword") arguments when calling methods.
For comparison, in the same time period, Java has added a half-hearted generics implementation, enums, and vararg methods.
So, no, they're not the same language anymore.
Re:Java killer? (Score:3)
Deep down Java is just Simula with a few keywords replaced.
Ultimately, of course, deep down everything is either Algol-60, FORTRAN or Lisp.
The point is that idiomatic C# today looks very unlike idiomatic Java, due to the presence of major game-changing features such as concise closures. That's what matters.
the ability to only "run on a windows platform".
apt-get install mono
Re:Java killer? (Score:3)
Language features alone don't decide such things, yes. But when language features are sufficiently big that they change how libraries are written (examples: closures, attributes/decorators, LINQ), then the difference in libraries can certainly be a major factor in choosing a platform. ASP.NET MVC is infinitely nicer than old WebForms not just because it builds around a saner concept, but because it heavily uses what the language has to offer to allow for concise yet readable code with minimal time waste. Another similar example for another language is Rails, where a lot of flexibility and convenience of the framework stems directly from the power of the underlying language
As for syntactic sugar - the difference between "foo.getLength(foo.setLength() + 1)" and "foo.Length += 1" is minor, but it is there, and it all adds up.
Re:Java killer? (Score:3)
This will not compile, because IEnumerable does not have Add, nor any other method that would do the same. It's exactly like Iterable in Java.
Note that it is illegal to write:
For precisely the reasons that you have stated. Which is to say, IEnumerable<T> is covariant in T, while IList<T> is invariant in T.
The way it's implemented is that, when you declare an interface, you can decorate type parameters with "in" and "out":
If a type parameter is declared as "out", it is covariant. This means that within the interface, it can only be used in "output position" (i.e. as method result type, but never as argument type). Consequently, you cannot spell out the signature of any method that would mutate, like Add (without explicit, runtime-checked casts). Therefore, it is always typesafe to treat IEnumerator<Derived> as IEnumerator<Base> for any Base from which Derived inherits.
There's also "in", which indicates contravariance - the exact reverse of the above. A write stream would be contravariant:
T in IList is necessarily neither "in" nor "out", because it has both "Add(T)" and "T operator[]" - and so T is used in both input and output positions.
Note that this is also the exact same scheme that is proposed for Ceylon in the linked slides, down to keywords used.
Re:Java killer? (Score:3)
Despite the supposed language shortcomings of Java (often criticised by those writing smaller programs or who don't realise that features like 'operator overloading' were deliberately omitted as practical experience showed them to be problematic) the language isn't that bad (especially if you have a large team of people with differing skill levels working on a projetc). The real clincher is that the Java libraries (including 3rd-party) and library portability make Java without peer. This is why Java is still King of the Hill in the Enterprise, and likely to stay there for the foreseable future.
Re:Java killer? (Score:3, Insightful)
What the fuck is "enterprise code"? I've heard this phrase used in so much marketing, but what the hell is it supposed to mean?
Horribly bloated code written by mouth breathers who can't grasp any other language than one which doesn't hold their hand the entire way through. Oh and you usually have to throw in a couple of frameworks and then add additional frameworks on top of other frameworks to manage your other frameworks in the process of designing "enterprise" software.
Re:Java killer? (Score:3)
JRuby is one of the fastest Ruby implementations. Scala is very very fast. Closure is a very fast and increasingly popular Lisp. It seems like plenty of people are getting other languages implemented efficiently on the JVM.
Re:Java killer? (Score:3)
JVM bytecode and Java's language syntax are two very different things.
Pointless (Score:4, Insightful)
They are proposing a new language, with new syntax, requiring new libraries... that runs on the JVM.
Since Oracle owns the JVM and is trying to find ways to extract money from it, a new language that requires the JVM seems pointless.
If you just want better syntax, why not use one of the existing JVM languages such as Scala?
If you are pioneering a completely new language, why not pioneer a new virtual machine, and lawyer up and make sure Oracle doesn't have any grounds to sue you?
steveha
Still stuck without rich types (Score:3)
As long as it runs on the JVM, it's still stuck without support for unsigned data types. Not interested.
hmm. (Score:5, Insightful)
1. Put these guys, Walter Bright, and a few other folks (Alexandrescu? a couple of the best folks from the Java and C# camps?) in a building.
2. Lock the doors from the outside and guard the building until they've come up with the One True C++ Successor (both compilable to native code and a good target for a JIT) and the basic design for its standard library.
3. Profit^H^H^H^H^H^H End the ridiculous situation we have where systems-level programming is held back by 40-year-old braindead technologies like the C preprocessor while the dominant business programming languages are controlled by corporations with terrible track records.
Missing feature in Java: Copy on write (Score:5, Insightful)
My number 1 missing feature in Java is the ability to set object references to be 'copy on write'.
I'm doing numerical/scientific programming. Say I have an object which contains an array, and a 'get' function to return that array. Currently I have two choices: I can return a pointer to my object's array, or make a copy of the array and return that.
Returning a pointer is very fast, but now my class is at the mercy of callers which might write into my array. Returning a copy is safe, but so long as the callers behave themselves and don't try to write to it, is a waste of time and memory. If I could return a "copy-on-write-reference" to my array, I'd get the best of both worlds.
Any reference reached via a copy-on-write-reference would also need to be copy-on-write. If you make copy-on-write a qualifier on a variable, this could be all enforced by the compiler.
Are there any languages which do something like this?
you can do Copy on write in c++ (Score:3)
My number 1 missing feature in Java is the ability to set object references to be 'copy on write'.
I'm doing numerical/scientific programming. Say I have an object which contains an array, and a 'get' function to return that array. Currently I have two choices: I can return a pointer to my object's array, or make a copy of the array and return that.
Returning a pointer is very fast, but now my class is at the mercy of callers which might write into my array. Returning a copy is safe, but so long as the callers behave themselves and don't try to write to it, is a waste of time and memory. If I could return a "copy-on-write-reference" to my array, I'd get the best of both worlds.
Any reference reached via a copy-on-write-reference would also need to be copy-on-write. If you make copy-on-write a qualifier on a variable, this could be all enforced by the compiler.
Are there any languages which do something like this?
You don't need the compiler to know about copy-on-write. To write a generic copy-on-write pointer class it is enough to have a compiler that knows about const-ness, as well as operator overloading that also allows overloading pointer operations (dereference..). Both features are available in C++, and in fact some implementations of STL string have used copy-on-write. Like reference-counting, performance becomes horrible with multiple threads because of the extra locks that are then needed.
Re:Missing feature in Java: Copy on write (Score:3)
Some C++ STL String implementations used CoW, they've all dumped them - in the end the cost of memory copying was smaller than the (rather huge) penalty for making sure it worked correctly in a multi-threaded, thread safe environment.
Turns out its quite hard to do fast CoW if you have to lock the contents before writing to it.
Gratuitous differences (Score:3)
Why is that language designers feel they must come up with gratuitous differences to differentiate their babies?
I'm talking about where keywords are used in the same (or much the same) way, but they've come up with something different after spending some time with a thesaurus:
E.g., instead of Java "implements" for interfaces, you get "satisfies".
abstract is replaced by "formal"
"actual" means "override"?
"public" -> "shared" : what's the value-add?
"var" -> "local" : var types much easier.
Unleash the recruiters (Score:3)
Great, I expect a email from a recruiter tomorrow wanting someone with 10 years of production Ceylon experience.
Yes, but...probably no (Score:4, Interesting)
Java needs to be replaced. I have taught Java for years, because many colleges think it is a good first language to learn. Only recently have I actually attempted to develop commercial quality applications in it. Frankly, Java sucks big green ones. Generic types (with type-erasure) are a total hack, denying the running code valuable information. Abstract classes are only half-implemented, since you cannot have abstract static methods (e.g., factory methods). Meta-programming in Java is extremely limited - Reflection covers a few aspects, but even these are very awkward to use. Exception handling is awkward, there is no multiple inheritance, not all types are objects - hacked with boxing and unboxing. And so on, and so forth, and so on...
The chances of this language going anywhere are small. Anyone who has enjoyed studying compilers has written (or at least imagined) their own language. Creating new languages is fun, lots of people do it, and mostly - even if they are good - the languages disappear down a deep, dark hole. Success for a language requires a lot of support from many different parts of the IT community: lots of libraries, job prospects, more libraries, books, courses, real world applications, and did I mention code libraries? There are zillions of languages out there, many of them better than Java. Unfortunately, none of them to date have gotten the necessary support. What are the chances that this language will be different?
Re:Yes, but...probably no (Score:3)
You keep slapping on new features every time someone has a slight issue with the language and you end up with C++. Don't know what you think is awkward about Java exceptions and multiple inheritance was yanked from the spec for very sound reasons (ask a gray-haired C++ coder why). Java makes compromises (like primitives not being first class objects), but at least they were done with forethought.
Re:Yes, but...probably no (Score:3)
Many of the "improvements" to Java were done without the thought necessary to make them work right, such as the Generics capability.
However, I disagree about the problem of abstract static methods. I have come to dislike static methods and would prefer to see their use limited *further*, since much of the absolutely terrible code I've had to deal with over the years has been a result of the (ab)use of static methods.
Many colleges teach Java as a good first language, as the perceived alternative is C++, which is a terrible first language for anyone. Java's not a good first language, but it's by no means the worst.
Java Generics are indeed a total hack, which is a result of trying to cram features into a language without thinking through the consequences. Generics were the cool thing, therefore, to remain relevant, Java must have Generics... and thus we get this festering sore on the language.
I do not agree with the analysis for abstract static methods. In the Java object model, the concept makes no sense (unlike, say, Smalltalk), and, indeed, is arguably worse than useless. A great deal of the terrible code that I've run across over the years has been a direct result of programmers favoring static methods with only the shakiest of justifications.
It's true that meta-programming is awkward, but in the languages where it isn't, and is heavily used, I fail to see a significant improvement in code readability or maintainability. It allows for clever techniques that can be extremely difficult to debug, much less understand from reading the source code. Awkwardness in this domain is a disincentive, which is arguably a good thing.
Exception handling is awkward... and arguably more informative than in any other language in common use. Some languages allow the exception handler to "fix" the problem and resume, which is amazing and powerful and wonderful... until you discover a programmer who uses this capability for mixins and flow control, making the code virtually impossible to follow.
But then, I'm one of those throwbacks who consider having to use a debugger to develop or read code to be a bad thing. Code is a form of literature, not a performance art.
Multiple inheritance is an abomination.
Not all types being object is a wart, and not a significant one. Autoboxing is a hack that's worse than the flaw it attempts to hide.
Java is a language full of flaws, but when one tries to envision a replacement language, one needs to consider not its flaws, but what it did *right*, and /why/ that design decision was right for the language. (I assert that what's "right" may be different in the context of a different language; "these are my favorite things" is a poor way to assert what's right.)
In my opinion, some of the things Java did that was right was:
1) It ran on several platforms. MSWindows was the dominant desktop environment, and it sucked, and sucked hard. The more useful systems (Solaris and Linux at first) were far nicer for developers, but those systems weren't what the users and managers were using. Java could be developed on the hippie's Linux box, tested on the corporate Solaris server, and demonstrated to the manager on his MSWindows desktop.
That's a huge win. Nobody feels that the language chosen is being used to force someone else's environment on everyone else.
2) It supported concurrent programming out of the box. Most of the time, in most of the code, there's not a need to handle threaded or concurrent code. But in that window where it is useful to separate tasks into concurrent threads of execution -- such as keeping the database-access code out of the GUI drawing thread -- it's made vastly simpler in Java.
And given that MSWindows at the time had a laughable concurrency model, Java's ability to bring this sort of concurrency to Java was *very* attractive. You didn't have to rewrite the algorithms developed on a UNIX-type machine to handle the broken MSWindows environment, which ties into
Re:C#/Mono similar? (Score:2, Insightful)
If C# didn't kill Java, I don't see how anything else is going to.
Re:C#/Mono similar? (Score:5, Funny)
Two words: Oracle.
What's the second word?
Re:C#/Mono similar? (Score:2)
Java
Re:C#/Mono similar? (Score:3, Funny)
"FuckingBullshitAss Oracle" is implied whenever somebody says "Oracle".
Re:C#/Mono similar? (Score:5, Funny)
Two words:
Oracle.
What's the second word?
Lawyers.
Re:C#/Mono similar? (Score:3)
You're not pronouncing it properly. Pronounce the two syllables as two words. "Ora Kill", same as Larry Ellison does.
Re:C#/Mono similar? (Score:3)
That's because that's not the main trap that Mono represents.
Microsoft tolerates Mono because it's a clone of a Microsoft technology. They haven't tried to stop Wine, either. Microsoft knows what most of the useful idiots who support the use of Mono appear not to have realized: if your business is in any way, shape, or form built on Microsoft technologies, you will face extreme pressure from all sides to move to a full Microsoft stack.
The patent angle will only ever be used if it looks like Mono is causing important customers to migrate away from Windows. But that isn't happening.
Re:Another One! Just what we need (Score:4, Funny)
Don't forget all the other important languages!
* brainfuck
* whitespace
* piet
* INTERCAL
* false
* befunge
* malbolge
and, of course (last but not least!)
* LOLCODE
Re:I like not equals assignment operators (Score:3)
Considering how all programming languages that use := are hated with a passion, I would say that a swastika would make a better assignment operator by now.
Re:Sounds like a more verbose C# (Score:3)
There are many language features that have been available for ages, especially in various Lisps. The problem is always getting those features into mainstream. Arguably, closures only got there with JavaScript, and even then it took a while for people to actually notice they're there. The first mainstream language which not only had them, but actively advertised it, with standard library build largely around the concept, was Ruby.
(One could argue that in both cases it was rather Smalltalk, but I think that it is a matter of debate whether it was sufficiently mainstream. There's certainly no doubt with JavaScript.)