Live data from Hacker News

Red Hat's top secret Java Killer/Successor: The Ceylon Project

blog.talawah.net

61–70 of 89 posts

Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project

#61
post #32

Earlier quoted context omitted.

That's true, at some point you grow up and use Java :3

Funny. I've worked at a place that grew up and moved from Java to Ruby, and I've worked at a place that grew up and moved from Java to Python. I've never worked at a place that moved from anything -to- Java, and I've been in the field since 1994.

Troll successful :3

Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project

#62
post #34

so sad. first of all, nothing about java is good. nothing . can anyone on HN name one single app they use daily that is programmed in java? anyone? no! how is it that a language designed from the beginning to be cross platform doesn't have a single mainstream cross platform desktop app? they even couldn't get it to be a platform for web browser plugins, how pathetic is that! and even when it does run as a web browser…

> let java and the jvm just die, it's bad, it's all bad. the jvm was a bad idea

It may be a good idea for you to have reconsider that opinion on the JVM. Java as a language is arguable but JVM is definitely an engineering marvel.

You can look at languages like Clojure, Scala and JRuby on the JVM. It gets you the goodness of JVM plus a great language to use for your app.

Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project

#63
For me, the key question for any new language is: "Does your language help me create better abstractions?" And what I specifically mean by "abstractions" is that I can take a recurring pattern in the code and a) capture the repetition and b) reuse the abstraction representing that repetition and c) doing b is smaller/simpler than the original code

After a decade+ in Java, my conclusion is that Java cannot capture repetition in many common real use cases. The addition of lambdas in jdk 8 will expand the scope of what can be captured but will still not cover control flow use cases.

Even when you can actually capture the abstraction (many common "design patterns" are examples of this), you will find that doing so increases the overall size of the code (you must create new interfaces, factories, etc etc). The downside is that making more general, higher abstraction systems are by definition more complicated in Java.

I want to build large maintainable systems and the ability to create powerful abstractions that simplify my code is essential. I have moved to Clojure which so far has delivered on these needs. I don't know as much Scala but my impression is that it also satisfies these goals. At the very least, I'd say that both Clojure and Scala consider this kind of thing to be in scope as a goal.

It's easy to make a language that is more concise than Java. I think it's harder to satisfy the goals I specified above (which are only indirectly related to conciseness).

I haven't studied Ceylon enough to tell whether it makes progress towards building better abstractions.

Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project

#64
post #15

People, please learn from mistakes of the past. Using less-than and greater-than as template parameters was a horrible idea by Stroustroup, but was copied by Java and C#. Although C# and Java do not suffer from the craziness that is C++, by virtue of requiring a class name, e.g. template void myclass() { ... code ...}; ... myclass 4>(); /* myclass ? or syntax error? */ is unique to C++ - but still, all lexing/parsing…

is this really a big deal? I wrote my share of Java code with generics and the issue never popped up, because generics are way more restricted than c++'s templates. E.g.

   myclass4>  
can only be a syntax error because you can't have a value in there, inly a type name

Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project

#65
post #40
post #36

Earlier quoted context omitted.

I would say some people don't want to get it. There are plenty of toy languages and interactive calculators such as logo and which allow simple definitions of functions similar to the 'ideal' given. However noone would suggest writing complex software using logo. I'm not going to defend every last aspect of Java, but in practice verbosity and readability are not it's biggest issues. In practice Java is pretty maintai…

>but in practice verbosity and readability are not it's biggest issues. Right. It's biggest issue is inconsistency. Int or int? Equals or ==? Why can class String overload the + operator but I can't? On and on. But Java is very verbose. It's not a big issue in practice because we have IDEs that write most of the endless boilerplate for us.

Consistency really isn't that big an issue, the remarked points are really just details. (Of course in Javascript the use of == really is an issue).

The concept of equals is not as pure as it would like to be but it is not clear what can be done about this, since it is very convenient to have and it is not necessarily the case that there should be a universal concept of equality between all objects (although in practice this is only infrequently an issue in well designed code).

Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project

#66

For me, the key question for any new language is: "Does your language help me create better abstractions?" And what I specifically mean by "abstractions" is that I can take a recurring pattern in the code and a) capture the repetition and b) reuse the abstraction representing that repetition and c) doing b is smaller/simpler than the original code After a decade+ in Java, my conclusion is that Java cannot capture rep…

Mostly agree with you, from what I understand about Ceylon it doesn't satisfy this need.

For me it's look like groovy, more a syntax cleanup than a new language.

And as far as I know Scala, it enable to create 'better' abstraction like you are doing in Clojure (great language too from what I used).

Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project

#67
post #14

Red Hat has put a lot of work into gcj, and was responsible for making Eclipse run on it. They've done a bunch of work on Iced Tea. They also have a bunch of Java applications they maintain/sell support for (JBoss is the big one). If this is actually a company priority (and not a side project), it could be a Big Deal(TM).

No, not big deal..the big changer in enterprise was and still is Groovy as it sues the same exact syntax as java..while adding stuff java lacks..anything that suggests learning a while different syntax and language on top of it will be a hard sell to any enterprise.

Have you even ever used Groovy? It is not the exact same syntax at all. It is merely similar and there are plenty of ways of writing valid java which is not valid groovy. Not to mention groovy has all sorts of corner cases, terrible efficiency and is not statically type checked ... and I like it (for some things).

Discussion of Java here seem to attract the most fatuous comments (at least to my mind) which seem to be little more than echos of things that people have read somewhere. If you have an opinion on something but no in depth experience, at least have the decency to profer the opinion tentatively and with appropriate qualifications.

Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project

#68
post #26

Note to future corporate overlords: if you are going to develop a possible successor to a wildly used programming framework, don't do it in secret for two years while other efforts (Scala, Clojure, Groovy) are gaining massive traction and are ever evolving due to public interest.

Sorry I have been coding for 7+ years both in Java and C# but I never seen Scala and Clojure being actually used in all the companies I have been - fortune 500 Tech companies. But when I told them about Red Hat's Ceylon Project they were interested to know about this.

Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project

#69
post #36
post #17

Is it 'easy to read' as in let sum x y = x + y Or 'easy to read' as in public final class Summer { public static T Sum (T x, T y) { return x.add(y); } } Because I don't think that dreck in the bottom is 'readable', it's like giving construction workers a Fischer Price My First Hammer and expecting them to be able to build a house with it. If you're going to make a language like Java at least let programmers take the…

I would say some people don't want to get it. There are plenty of toy languages and interactive calculators such as logo and which allow simple definitions of functions similar to the 'ideal' given. However noone would suggest writing complex software using logo. I'm not going to defend every last aspect of Java, but in practice verbosity and readability are not it's biggest issues. In practice Java is pretty maintai…

Java is quick to write because of the excellent IDEs out there. Typing out the full structure of a simple pojo by oneself makes one wonder why.

Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project

#70
post #31
post #23

What I never understood was why backwards compatability was not overcome by simply changing the file suffix. A second fixed up version (something like Ceylon) could be mixed in with old Java code. Just change the suffix to .java2 to signify a class using the new language spec. In my opinion basic type inference, name parameters, better support for immutability* and multiline strings represent the majority of the defi…

Backwards compatibility was never a technical problem, the JVM can support heterogeneous programs written in multiple languages out of the box. As long as it all compiles down to class files everything can interoperate seamlessly. Strong-typed alternatives to Java have existed for ages, such as Nice, KSL, and Scala, so if you want you can take your pick in mix it in with Java code right now. As far as I understand it…

I understand this, but my point is this. They add features to java e.g. generics and all the tools (IDEs) have to make adjustments to catch up. It seems to me that similarly sized adjustments could be made to support a newer cleaner version of Java (i.e. strictly better, just the low hanging improvements - really just syntactic sugar). The only additional change would be the introduction of a new file suffix, or even a version before the package declaration. The impact on the tool chain/developer adoption would be the same. This is not true for Scala and so on since here the departure is so great that the IDE support needs to be rewritten.
Post reply on HN