Red Hat's top secret Java Killer/Successor: The Ceylon Project | Hacker News Reader

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

blog.talawah.net

96 pointsGarbage87 comments

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.

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

>because they wanted to keep the language clean and simple

If this is the goal, I'm afraid they went of course before getting out of the bay. Clean and simple is how I would describe Smalltalk, not Java. And Smalltalk a lot more concise (note: not terse).

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.

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.

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.

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.

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.

But doing that makes sure they can't hurt themselves with a hammer while working!!!

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.

Do that in Java and Haskell (with the same amount of library support) and show me how the java version is simpler. I would really like to see that. (you can take clojure or scala too)

For comparison, I came up with this in C#

  Func<int, int, int> sum = (x, y) => x + y;

I had to specify the type explicitly, could not use 'var' type inference; the error is "Cannot assign lambda expression to an implicitly typed local variable". This is because the lambda could mean more than one kind of thing (delegate, expression tree, Func<>). Yeah, it's c# baggage.

Of course, once the type is known, you could do

  var sum2 = sum;

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

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

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

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

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.

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.

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

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

You don't have to be this rude :)

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

did it have all these libs 10 years ago too?

Why did it take me 10 years? Because I had 10 years less experience 10 years ago. I was a C++ developer with only a couple years of professional programming experience. At that point, Java was the new upstart with the promise of GC and libs that actually worked across platforms. I grew up along with Java and learned a lot along the way. As a professional programmer, I didn't know anyone that used anything but C++ or Java. CL was not a career choice (I'm still hard-pressed to say that it is).

I spent many years building some pretty good production software in Java and it certainly paid my mortgage and let me grow in important ways. I did tinker in the background with Ruby, Erlang, Python, Groovy, etc etc and tried to bring them in as testing tools or whatever when I could. There are still many things I like about Java and working in Java obviously makes your work available to a vast number of programmers.

I feel incredibly lucky that Clojure (and Scala and ...) are possible choices now and that I've managed to get to an experience level where I can make the judgement to recommend it and have an employer listen to me.

I do apologize for not personally making the majority of the industry use Common Lisp 10 years ago. My bad.

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)

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.

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.

The problem is that you often need to decorate a generic parameter with additional information (like its type constraints or variance). If the type parameter doesn't have a singular place where it's "declared", there's no convenience place to do that. In your example, how would you specify that T must implement Summable?

I'm afraid <> is too ingrained at this point to turn around, but seriously; is it such a problem? In C# a template can show up in a class like:

public class Foo<T> { ...

a method like:

public void EatAFoo<T>(...

and usage like:

var f = new Foo<int>();

someObj.EatAFoo<int>(...

I don't see how any of these cases could be confused with a greater than or less than operator. Could you expand on where the problem comes in?

The statement: F(G<A, B>(7)); could be interpreted as a call to F with two arguments, G < A and B > (7). Alternatively, it could be interpreted as a call to F with one argument, which is a call to a generic method G with two type arguments and one regular argument.

See the C# specification section 9.2.3 (grammar ambiguities) for more details: http://www.ecma-international.org/publications/files/ECMA-ST...

> please use {} or []

How about a Pascal-ish:

(List of Integer) l = new List();

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.

   myclass<3>4>

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

Ok. Still, it makes syntax highlighting and everythink lexical so much harder and ambivalent (think a<b<c>> - close paren or right shift?) with no benefit compared to e.g. []

again a syntax error, you can't have generics in an expression in which operators such as > are allowed, the java syntax is really simple and unambiguous to parse.

On the other hand, [] is used for arrays in java so it _would_ conflict with something

See this comment above in this thread: http://news.ycombinator.com/item?id=2442468

It is a semantic error, not a syntax error (in the sense that an annotated grammar CANNOT, without semantic analysis, find that this is an error).

The example given in this comment, F(G<A,B>(7)) is syntactically ambiguous and can only be resolved to either F( (G<A) , (B>(7) ) - a two argument function call, or F( (G<A,B>(7)) ) - a one argument function call - when the types of F, G, A and B are known.

Also, things like F<G<A>> (which are perfectly legal) make lexing very hard - you can't assume '>>' is the shift right token without syntactic (and semantic) analysis. Or, you can decide like early C++ that you must write it F<G<A> > which is confusing.

sorry, but are you sure a C# problem applies to Java?

AFAIK the syntax for passing type arguments to a generic method in the latter would be

   obj.<A,B>G(7)

   F(G<A,B>(7))

is once again unambiguous, at a syntactic level.

It would seem the java designers thought of the issue :)

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.

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

You're right.

Constructors are stupid and violate one of the principle ideas behind OO which is separation of concerns.

What initializes a data structure should not care how the data structure was allocated. It's two functions one () -> T and T -> T allow them to be first class citizens.

If you want to combine them use a static method that simply invokes the initializer after the allocator (which is how it works anyway, and how new is implemented in both Ruby and Obj-C). And it's not like it solves any real problems as it's perfectly alright to have uninitialized and incorrectly initialized objects with current constructors.

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.

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.

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.

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.

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

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

You need to realize that while Scala was in development, there were quite a few languages that were also rapidly gaining in momentum and mind share.

Having said that, while I do see Scala at conferences and in articles, this hardly qualifies as a sign of gaining momentum, and job boards hardly register Scala in the top 50 languages.

It's interesting that you lump .NET in with Java. C# has more in common with Scala in terms of flexibility and expressiveness than it does with Java these days. C# 1.0 was a Java clone, sure, but the language has moved faster than pretty much any language out there since then.

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.

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

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.

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.

And younger than C, C++, Perl, Fortran, Cobol, ...

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

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.

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

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

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?

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

2. Not sure.

Troll successful :3

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

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.

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.

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

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

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

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.

One advantage it has over Scala is that it doesn't do erasure of type parameters. I wonder how this works when it comes to interop with existing Java code though.

The other broad advantage seems to be that it's designed with a bit more restraint than Scala when it comes to the feature-set. Although personally I find all the Haskell-like implicits and the advanced type system stuff in Scala very interesting, I can see how this may end up holding back adoption by Java shops.

So: I'm reservedly interested in it, although does seem a bit vapourware at this stage.

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.

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

Why is there no mention of concurrency?

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

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

the killer bit is

:=

pascal is 30 something years old...

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.

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

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.

minecraft

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

Twitter: http://engineering.twitter.com/2011/04/twitter-search-is-now...

Hadoop

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

Eclipse? NetBeans? SOAPUi...

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

I like some of your flame, and I like the style, but I will reiterate others' disagreement on some points. It's/its? wrong to pillory the JVM along with Java The Language. I hate scala and groovy, but they're/their designers cling to the JVM for very good reasons. Also, "C/C++/Python apps are 1000x more widespread than java apps" is kind of imprecise - why tack Python on the end there? That is like saying Apples and Oranges are more widespread than Bananas. I agree with the overall sentiment, but the parent got a little to firehosey with his rant. I really like the style, I have to say it again. Hacker News really needs more style. Would upvote again.

But we def. do not need yet another Java replacement and its/it's probably a bad sign if they didn't start with a compiler instead of a slide presentation.

Reply on news.ycombinator.com