Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.talawah.net

Post reply on HN
Print view View original

21–30 of 89 posts

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

#21

Post by beagle3 »

fleitz wrote: post #18
beagle3 wrote: 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…

I suggest the ' operator as in let sum (x:'T) (y:'T) = x + y I have no idea why you even have to specify that a method is generic shouldn't it be generic by inference?

If quotes are used for grouping characters (as they are in C, Java, C#, Python etc.) then this is just as bad as using . How can you tell if it is a character literal or a type?

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

#23

Post by lsd5you »

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 deficit in terms of making java more expressive and convenient. Other things such as higher order functions (would require an extension of the type system) raise issues that make the benefits less clear cut.

* my view on immutability is that it should be possible to 'bake' a class or an interface. So it can be manipulated before being made immutable.

(Apparently something like this is possible in Java 6 using annotations and compiler plugin extensions, but apparently it is not straight forwards to get working with IDEs (and as such, given the importance of IDEs one may as well change language).

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

#24

Post by fleitz »

beagle3 wrote: post #21
fleitz wrote: post #18

Earlier quoted context omitted.

I suggest the ' operator as in let sum (x:'T) (y:'T) = x + y I have no idea why you even have to specify that a method is generic shouldn't it be generic by inference?

If quotes are used for grouping characters (as they are in C, Java, C#, Python etc.) then this is just as bad as using . How can you tell if it is a character literal or a type?

I have no idea but F# does exactly that.

I'm guessing that it uses a context sensitive grammar that doesn't allow you to use string literals for variable names.

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

#26

Post by maayank »

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.

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

#27

Post by perlgeek »

parbo wrote: post #9

The article says it draws inspiration from younger languages, and mentions Python as an example. This is false, Python is four years older than Java.

I'm not a python programmer, but I still get the impression that python in younger in spirit than java :-)

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

#28

Post by inoop »

ianbishop wrote: post #8

I find it entertaining that Java's apparent successor will be, in many ways, a copy-cat of modern C#. It wasn't long ago that C# was created in Java's image. If this language is not continually enhanced, then it will fall behind. Java has always had trouble with this because of committees and fear of actually saying "no" (real deprecation). I swear "it'll be in Java 7" has nearly become a tag-line this year.

The Java people have always been very reluctant to add new features because they wanted to keep the language clean and simple, a design choice that personally I think is superior to 'rich' grammars like that of C++, Python, and C#. How many people really know and use 100% of the C++ syntax these days? Many companies actively enforce a strict subset of the language, and who even cares about C++0x? In my humble opinion C# pretty much jumped the shark when they started adding things like partial classes.

There's lots of things wrong with Java, but I think a worthy successor should at least keep that 'less is more' mentality.

If you want a feature-rich Java though, you can always try the KSL: http://openjdk.java.net/groups/compiler/ksl.html

edit: by the way, I'm not saying Java > Python, just that I prefer clean languages. Just wanted to get that out of the way before I get flamed to death :3

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

#29

Post by tezza »

fleitz wrote: 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…

Your example is a tad too simplistic.

Literally everyone would just write z = x + y; inline

Why parameterize needlessly?

If you're saying that list comprehensions are clearer in functional form, I would suggest a more appropriate comparison.

How about:

* drawing some text on a bitmap in lines

* building a list of nodes and doing a Minimal-Spanning-Tree

I don't think they'd be much clearer.

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

#30

Post by kiiski »

fleitz wrote: post #24
beagle3 wrote: post #21

Earlier quoted context omitted.

If quotes are used for grouping characters (as they are in C, Java, C#, Python etc.) then this is just as bad as using . How can you tell if it is a character literal or a type?

I have no idea but F# does exactly that. I'm guessing that it uses a context sensitive grammar that doesn't allow you to use string literals for variable names.

Maybe, but the problem was that "all lexing/parsing/syntax highlighting/analysis of the language is much harder because of this horrible choice". Using quotes doesn't really fix that.
Post reply on HN