
Red Hat's top secret Java Killer/Successor: The Ceylon Project - Garbage
http://blog.talawah.net/2011/04/gavin-king-unviels-red-hats-top-secret.html
======
zacharypinter
It looks like this project is being headed up by Gavin King (of Hibernate
fame). At the risk of being negative:

When it comes to community support, I've found Hibernate to be one of the most
frustrating open source projects to work with. It was comical how often I'd
search the forums, find a person with the exact same question that I had, and
see that Gavin or another project member had replied "you shouldn't want to do
that" instead of actually answering the question.

Also, a couple of my projects were bit pretty hard when they removed a
documented feature (it was in the manual!) in a point release (3.2.2 to 3.2.3,
I believe), where the only workaround ended up requiring a significant
refactor of our code base. The official response (ticket HHH-2667):

> I dont know how many times i need to close cases with almost the same exact
> description.

> This was never supported syntax, and was never supposed to work. It was
> simply a regression that it happened to work (somewhat) in certain releases.

So, even if Ceylon had considerable advantages over Mirah or Scala (which
doesn't seem to be the case), I'd probably avoid it for the above reasons
alone.

------
ianbishop
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.

~~~
6ren
Back-compatibility is what enables old, useful, expensive applications to keep
running. It is what made Microsoft so much money, and Intel so much money. It
is the reason why Java is so universally adopted.

At the same time, back-compatibility is frightfully horrific. I really feel
for the x86 engineers, for one thing.

And it's no protection against a true disruption - I was going to say "such as
webapps and mobile", yet Java is strong on both (server-side and smart-phone).
So it must be doing something right. I think it's that its depth of libraries
(and tools and coders) means that you can fulfill any particular need more
quickly than any other way - which is _the_ application of programming
languages. The depth of libraries is directly supported by back-compatibility
(the old ones still work).

And, in this sense, it just keeps getting better and better.

~~~
rbanffy
The cynical in me attributes this presence of Java in enterprisey applications
to the huge piles of documentation, flows, UML diagrams, the piles of servers,
ESBs and Oracle databases, along with the priesthoods that keep all that in
place and up to date.

Reading that pile of documentation and interviewing the hordes that tend to
the application are much more work than it would take to write a more modern
version of whatever that does with 1000 lines of Perl (or Ruby, or Lisp, or
Python, or Erlang, or Haskell).

It's not as much as Java did something right, but more like we did too much
around it.

Disclaimer: I am currently struggling with a web application that's little
more than a CRUD, but done with what I call "framework bingo" on top of a
complicated network of servers, with dedicated Mule feeding Elastic Search
servers where a simple CRUD (even the one that comes free with Django apps)
feeding a static file system would offer better throughput and easier
troubleshooting than the huge pile we see there.

~~~
6ren
According to Moore ( _Chasm_ guy), new technologies tend to get standardized
on by big organizations. Adopting it in the first place was hard enough, and
they want to put off doing it again for as long as possible. The
infrastructure and dependencies (those _huge piles_ ) are a big part of why
it's hard to change. Some are important and necessary dependencies that are
expensive to change no matter what. I think this is characteristic of the
enterprise.

Back-compatibility facilitates this postponement of change.

I daren't be an apologist for that webapp (esp since I don't know anything
about it and I agree with you anyway), but my inner contrarian pipes up with
Joel's essay on rewrites
(<http://www.joelonsoftware.com/articles/fog0000000069.html>). Though it
sounds like there isn't even a grain of truth with respect to the
architectural decision.

~~~
rbanffy
I believe this specific application can be rewritten in a week or so. If we
factor in all the resources that had been dedicated to making small changes
and the disproportionate amount of effort dedicated to make sure those small
changes didn't break everything else, I'd go with a rewrite even if we kept
the whole damn thing in Java, just with a saner architecture.

------
fleitz
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>(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 training wheels off once they are experienced.

~~~
lsd5you
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
maintainable and quick to write.

To address this strawman directly. The first and last line of the 'dreck' are
the namespace, which is missing in the top function. I think it is entirely
fair to omit namespace and access modifiers. Probably there needs to be <T
extends Summable> or some such (ignoring a number of issues with the approach
here), but then this could be put in the class declaration at the top for
reuse in more than one function. Which would leave

static T Sum(T x, T y) { return x.add(y); }

Which is what it is ...

~~~
danssig
>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.

~~~
bpodgursky
Actually the == comparison is VERY consistent. == will return true only if the
values are identical--in the case of primitives, this means the ints or
doubles are identical, and in the case of objects it means the pointers have
identical values--meaning they point to the exact same object. But this way I
know that if I want to do something like change the way things stored in sets,
I have to modify equals(), since that's what maps and sets use to check
equality.

Strings are only allowed to use + because strings were traditionally seen as
primitive types, rather than the objects they are in Java. It's a small
inconsistency, but more of a concession to existing practice.

I'm not sure what else the "on and on" refers to...

------
puredanger
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.

~~~
nickik
(this is not only about you)

Its funny to me how people often say after 5/10/whatever years of java I
conclude that its limitations are [insert your limitations]

Why the hell did it take you 10 years? If you work with a language for a year
MAX and you can still not creat good abstractions. Why do you stick to it?

The guy that made Ceylon said something like that too.

(Sure your job could be java, but I think most people here do programming in
there freetime as well. Why did you not move to CL, Haskell, ML, python or
something. If more people would have done that these languages would be a lot
better of now)

Edit: An example: Alot of wat you get from clojure you could of gotten from CL
10 years ago. Why didn't more people think of this that way?

At least we can agree on the point that clojure is awesome and that we are
really happy to have scala and clojure today.

~~~
rick_bc
You don't have to be this rude :)

Some people use Java in spite of the language: they just like the vast
libraries.

~~~
nickik
did it have all these libs 10 years ago too?

------
beagle3
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 <boolean t> void myclass() { ... code ...};
      ...
      myclass<3>4>(); /* myclass<false>? or syntax error? */
    

is unique to C++ - but still, all lexing/parsing/syntax highlighting/analysis
of the language is much harder because of this horrible choice.

For heaven's sake, please use {} or [] or some other character which does not
also function as an infix operator.

(Even APL and K, which overload every character in fifty different ways, don't
mix grouping with infix operators)

~~~
fleitz
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?

~~~
beagle3
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?

~~~
fleitz
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.

~~~
kiiski
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.

------
jacques_chester
<curmudgeon>

Assignment using := and string concatenation using adjacency aren't
particularly new.

</curmudgeon>

edit -- further looking through the presentations ...

They seem to have ditched the 'new' keyword, but not gone as far as having
inferred typing which is a pity.

    
    
        Counter c = Counter();
    

would be better as

    
    
        c = Counter();
    

(edit: ignore this, the local keyword apparently triggers type inference).

:= and = are used to distinguish between assignment to mutable and immutable
variables. Is this necessary?

Clever use of syntactic sugar gives it a Lua-like flavour for programmatic
generation of markup / UIs.

Use of & and | symbols gives a clever way to assemble interfaces.

When an object "satisfies" (ie "implements") interfaces, it can combine them
either as intersections (&) or unions (|) of multiple interfaces.

A few nice features imported from functional programming land include
algebraic types and type-safe switches.

A lot of attention paid to the covariance/contravariance tarpit.

~~~
jbellis
TFA suggests "local c = Counter()" is what you are looking for.

~~~
jacques_chester
You're right.

------
krakensden
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).

~~~
shareme
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.

~~~
lsd5you
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.

------
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.

~~~
rwmj
Scala, Clojure and Groovy are certainly not gaining "massive traction". There
are still millions weenies out there turning out new Cobol ^W I mean Java/.Net
applications.

~~~
maayank
I admit I don't have the statistics to back it up, but from my perspective
Scala already gained massive mindshare in the set of programmers who both
already use Java and actually care about new programming features.

Is it already the defacto Blub language? No.

Do I know anyone in my field who isn't at least aware of the proclaimed
advantages of Scala (I'm in industrial computer science research)? Also no.
The first camp follows Oracle/IBM (Microsoft if we are talking .Net shops, not
related here) and they follow the second.

EDIT: also, forget for a second the "mindshare race" bit. Already people are
commenting "why did they do this? it's just like Scala". Now, obviously Scala
and the other JVM languages weren't in the same state two years ago. Maybe
then it was logical to design your own language with then-new language
features and expressibility. But if it wasn't so top secret, people would
notice the duplication of efforts and perhaps merge the two projects when this
was just an idea. Maybe I'm wrong, I admit I haven't had the time yet to
actually see more than several lines of Cylon, but from the comments and the
highlighted features there was some obvious duplicated effort.

~~~
eneveu
I love Scala, but some deem it too "complex". Java's successor needs to be
easy enough to understand for the millions of Java programmers that will have
to learn it. Enterprises want a language any code monkey can write in...

<http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html>

This is where Ceylon / Fantom are interesting: they improve a little on Java,
removing the various language warts, while not being too different.

[http://www.jroller.com/scolebourne/entry/the_next_big_jvm_la...](http://www.jroller.com/scolebourne/entry/the_next_big_jvm_language1)

That being said, I'd love it if Scala were the next Blub language ;)

------
ares2012
If you replace "Java Killer/Successor" with "New Programming Language" I think
the title makes a lot more sense.

~~~
shuaib
I agree there.

For those of us for whom Java never was "alive" (not choosing to program in
it), is it safe to ignore this new language? I would be interested in it more
if they wouldn't pitch it as Java Killer.

------
parbo
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.

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

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

~~~
taotetek
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.

~~~
Sandman
So, you obviously never worked at Twitter, where they moved from Ruby to Java.

~~~
nickik
1\. The only moved the search 2\. A lot of code is in scala not java

~~~
Sandman
1\. I never said they moved the entire code base. What would be the point of
moving the entire code base anyway? The reason why they moved search to Java
is simply because Java scales better than Ruby when faced with heavy traffic.

2\. AFAIK, only the message-queue backend is in Scala?

~~~
nickik
Just wanted to point it out for people who did not know that.

2\. Not sure.

------
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).

~~~
inoop
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 Sun just didn't want to fork the Java language.

~~~
lsd5you
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.

------
narrator
Meh, looks like an ad hoc copy of some C# features. Scala is much cleaner
IMHO.

~~~
Egregore
I think some aspects of Scala make it like Perl, the write only language.

------
keveman
Ceylon looks a lot (if not identical) to Scala. I was trying hard to find a
differentiation, but couldn't.

~~~
Pahalial
I had much the same reaction, but no, this is very odd. Red Hat has no
aversion to contributing to Free Software and possibly forking it to create a
supported branch. Why would they push through with Ceylon rather than do this
with Scala? I must be missing something that is arguably a clear advantage.
I'll blame the QCon presentation refusing to load, but if someone could fill
me in that would be appreciated.

------
pnathan
Another VM language?

Why not pour the effort into Mono or PyPy? Or for the more exotic end,
Nemerle, F#, Rust, Mirah, maybe even trying to make Haskell more practical.

I've gotten a bit jaded, and at this point, there are a ton of new languages
competing. I don't want to pee in anyone's cereal, but the 'next generation'
language might be better found as a 2.0 of an existing effort? Especially if
you're not introducing really new concepts and you're trying to get people to
actually use it.

------
k7d
Imho they have lost to Scala before they even started. And from my experience
with Hibernate, Gavin King used to be this arrogant "you are doing it wrong"
type who never really listened to anybody (or at least he worked hard to
maintain that impression).

------
chrisdew
Why is there no mention of concurrency?

------
atrain34
too little too late gavin/red-hat. which i guess is how the entire java world
operates, so i shouldn't be surprised.

------
al_james
This looks very similar to Scala. Why reinvent the wheel Red Hat?

------
nvictor
the killer bit is

    
    
      :=
    

pascal is 30 something years old...

------
rian
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 plugin my computer has a seizure, hard disk
starts humming, mouse pointer starts spinning, browser becomes unresponsive...

java does exist out there though. ironically enough in controlled server-side
environments for in-house "business" web applications. that one really boggles
me, i'd rather have my face ripped off than write a web app in java. no,
seriously.

let java and the jvm just die, it's bad, it's all bad. the jvm was a bad idea,
it sounds good in theory but C/C++/Python apps are 1000x more widespread than
java apps. isn't distributability the entire POINT of the jvm?? why is it that
java sucks at actually "running everywhere"? keep the intermediate language
private to your language implementation, it serves no actual benefit anywhere
else and you know what else? a "CLR" _isn't_ actually an interesting problem.
it's just a bad abstraction, like everything else in java.

anyway, here you have this guy, gavin king, making all these empty hype-y
hand-wavy claims that java was the first language to perfectly combine static
typing, readable syntax, and lexical scoping (did you run out of bullet
points?) to serve as a host language for large team development and "large-
scale deployments of multi-user applications." give me a break, man. if i ran
my team or deployed my app with java as our host language my job would be
10-100 times more difficult and i would probably be 10e6 more unhappy in my
_actual life_.

then this guy knocks on the lambda calculus. i should have stopped reading
right then and there, obviously he must be a moron. what's next, REs got you
down? if you think the lambda calculus is only used by "theoretical" computer
scientists you should not be coding and you should definitely not be
attempting to write a new language. you're ruining the children, the entire
practice of programming by poisoning our culture with this misinterpretation
of the lambda calculus. for a dude who keeps wanking over "automatic memory-
management" you'd think he'd have some respect for LISP.

did you catch the three bloated slides of "Why we're frustrated?" lol come on,
come on now. stop lying to yourself. you hate java, why are you trying to
replace it with someone so much more complicated and senseless? how do you
expect "business" programmers to understand this:

    
    
      Html hello {
          Head head { title = “Squares”; }
          Body body {
              Div { 
                  cssClass = “greeting”;
                  “Hello” name “!” 
              }        
          }
      }
    

this is actually supposed to be a series of class instantiations. the fact
that "This looks like a typesafe declarative language (for example XML) with
built-in templating. But it’s actually written in a general-purpose language"
is actually a bad thing. don't even _attempt_ to get the json fans on your
side.

look if you're a psycho and want to program like a psycho why don't you just
write a small runtime and a compiler that compiles your code to C (or java
since you like the jvm so much) and be done with it. that's it, a weekend hack
project. with all the tools that exist today for generating compilers, that's
how it _should_ be. let it evolve as you actually use the language. i presume
you are writing this psycho language for an actual project you're working on
right?

after 50 years of high level language implementations the world doesn't have
any more room for a programming language for no end. C, Scheme, Haskell,
Python, Javascript are good enough. it's time to make stuff happen. it's time
to create good AI, it's time to engineer robots, it's not time to add lots of
senseless syntax to java and call that a two-year project.

~~~
wiradikusuma
> can anyone on HN name one single app they use daily that is programmed in
> java

1\. IntelliJ IDEA 2\. Eclipse (and its derivative works) 3\. My bank's
e-portal (ok it sucks, but it's written in Java)

Btw, I'm a Java programmer so my opinion is biased, but I think JVM is
different than Java (programming language). I don't really like Java's
verbosity, but I'm betting big on JVM. Hence I learn Groovy and Scala (both
run on JVM).

~~~
TomasSedovic
Plus pretty much every Android app. That's not JVM, just Java, but still.
Answers the question and nothing to sneeze at either, I would think.

