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.
Red Hat's top secret Java Killer/Successor: The Ceylon Project
61–70 of 89 posts
Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project
#62so 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…
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
#63After 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
#64People, 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…
myclass4>
can only be a syntax error because you can't have a value in there, inly a type nameRe: Red Hat's top secret Java Killer/Successor: The Ceylon Project
#65Earlier 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.
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
#66For 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…
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
#67Red 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.
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
#68Note 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.
Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project
#69Is 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…
Re: Red Hat's top secret Java Killer/Successor: The Ceylon Project
#70What 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…