Slashdot Mirror
Red Hat Uncloaks 'Java Killer': the Ceylon Project
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?'"
We already have a Java killer; his name is Larry Ellison.
There's no -1 for "I don't get it."
Two words: Oracle.
What's the second word?
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.
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.
*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. 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().
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.
Caveat Utilitor
I *am* from Ceylon (Sri Lanka) and yes, Ceylon is to tea what Java is to coffee. Both are islands. http://en.wikipedia.org/wiki/Tea_production_in_Sri_Lanka
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.
I absolutely hate Java, and I rather like C++, but I take serious issue with your ignorant, intolerant ranting...
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.