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: (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: (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: (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: (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: (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 mainta
Re: (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
Re: (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
Re: (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 l
Re: (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
Re: (Score:3)
In what way is Scala not a super set of Java?
Re: (Score:3)
Re: (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: (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: (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: (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: (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: (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: (Score:3)
If you polish a turd enough, sometimes it can disappear completely...
Re: (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 r
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: (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 a
Re: (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 efficientl
Re: (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: (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: (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 gar
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: (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: (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: (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: (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 :-)
Re: (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: (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: (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: (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: (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 syste
Re: (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: (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 th
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: (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: (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
Re: (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 byt
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: (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: (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: (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. An
Re: (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, IEn
Re: (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 t
Re: (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: (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: (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: (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: (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: (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++, whi
Re: (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: (Score:2)
Java
Re: (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: (Score:3)
You're not pronouncing it properly. Pronounce the two syllables as two words. "Ora Kill", same as Larry Ellison does.
Re: (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 e
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: (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: (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 i