looking forward to the test builds. (btw syntax is not final yet. The syntax was only chosen for demonstration purposes AFAIK.)
invokeLater({setVisible(true)});
comparators, event listeners, forkjoin’s ParrallelArray API, NIO2 Files.walkFileTree visitors… lot of usecases.
There are reasonable arguments for and against pretty much all language design elements. IMHO these issues are (logically) related to Godel’s incompleteness theorem. As someone who works often with programming elements that are algebraic in nature…it drives me crazy when a high level language does not support operator overloading. Most arguments against are related to bad design. However it is impossible for a language to prevent bad design.
return SomeType.sqrt(x.mul(x).add(y.copy().mul(y)));
return sqrt(x*x+y*y);
BUT, I think that designing a computer language that “fits all needs” is impossible (again: Godel). Try reading some of the stuff from Gilad Bracha. This is someone “important” in the design and development of Java…but to read his papers, one might think he was Java’s worst enemy. Which, of course, is far from the truth.
Well, I like the proposal but I think # as a keyword isn’t intuitive. It’s like the foreach loop that uses the : to separate the collection from the local var, this syntax isn’t intuitive for me.
why can’t they just use bloody keywords??? That way at least I can read it out aloud.
Cas 
Oh my…
I’m still trying to get my head around generics. Looking back now, I remember that the java attraction for me (and others) was it’s relative simplicity & ease of use. A few syntax differences and your off. (I used to be a realtime-embedded C guy before then, very procedural stuff so the increased OO was a refreshing change) I’ve been in the java camp for a while now, and it’s frustrating that some of those java7 code snippets look completely foreign to me.
These days, I seem to be wrestling with the new features rather that utilising them.
Maybe it’s time for me to move on to some other language.
Scala
Godel’s Incompleteness Theorem expresses the fact that algebraic systems can reach a point of complexity where there are things that are true in the system that cannot be expressed in the system and there are things that can be expressed in the system that are not true. It is impossible to have a system where all valid strings are true and all truths are valid strings.
This contrasts with Godel’s Completeness Theorem where he demonstrates the completeness of first order logic.
That has NOTHING to do with making a language that “fit’s all needs” as you claim. That is a matter of taste whereas Godel is referring to a property of systems, namely the truthfulness of valid strings in the system.
I have sympathy for what you’re saying. My line with Java has always been that it handles complexity well - you can write large systems with it that are easy to understand. Programming with teams of C++ developers where each one chose a different C++ style to be ‘expressive’ was a damn nightmare. We had islands of programmers who couldn’t understand how the other programmers worked and whos code suffered ‘impedance mismatch’ with their fellows. It’s a crap language for large systems unless you’re managed by a rules Nazi.
All these new features reduce that simplicity. I believe that people who want features like closures should use languages that support them natively (i.e.: cleanly) rather than hacking them on to what used to be a clean language design.
All that said, it doesn’t bother me: I will continue to use Java the way I like.
Same here.
Though I would like operators. But not with symbols, just function names. It is indeed pretty horrible trying to fiddle with vectors and matrices without operators.
Cas
Unfortunately thats also belaying one of the wonderful things about Java, the way that we all use each others code. If some developers start using the new features we all have to live with them, because we want to share code and libraries.
(misuse of) Generics already cripples us in this way. I’ve already started seeing library interfaces with generically used in “clever” (read complex and evil) ways.
Kev
Aye, there’s a definite friction now between people who want shiny buzzword compliant features and those who appreciate java’s clean and minimal syntax. It’s very close to the Perl vs. Python philosophies IMHO.
It certainly seems that since C# appeared there’s some language envy going on which has resulted in Java copying some of C#'s features in a cack-handed way. At least this doesn’t seem to be as edge-case-ridden as generics, but you never know…
IMHO simpliciy make powerness in all computer area : OS, software & ibraries, and of course languages and more … When trying to handle everythink in a single entity all become bug source / slow and more …
cf : javafx, word, windows, eclipse etc…
So, if I understand this correctly, # would basically be an anonymous function, which gets compiled into an anonymous class that only has that function, implementing some interface?
Isn’t this just tacking more fake stuff onto the language that it wasn’t designed for in the first place?
How typically “clever”
Kev
The warning bell is the use of an annotation to change the behaviour of variables outside the scope of the lambda function. That and the use of the # symbol. I mean, really. Tsk.
Cas
I’ve just implemented the derivative example from http://en.wikipedia.org/wiki/First-class_function in Java with anonymous classes, and I’m now prepared to admit that the current syntax is clear and perfect, while adding first class functions would probably make our collective heads asplode.
interface Fun {
public double fun(double v);
}
interface HighFun {
public Fun hiFun(Fun f, double v);
}
public class DerivativeFun {
public static void main(String[] args) {
Fun cos = new HighFun() {
@Override
public Fun hiFun(final Fun f, final double dx) {
return new Fun(){
@Override
public double fun(double x) {
return (f.fun(x+dx) - f.fun(x)) / dx;
}
};
}
}.hiFun(new Fun(){
@Override
public double fun(double v) {
return Math.sin(v);
}
}, 0.000000001);
System.out.println("cos(0) = " + cos.fun(0));
System.out.println("cos(PI/2) = " + cos.fun(Math.PI / 2));
}
}
What a refreshing change from Javascript / Scala / C#.
Now, this is admittedly a contrived example… and far from usable (I leave making it generic as an exercise to the reader ;)). It also doesn’t actually get the closure thing to happen properly, in fact I don’t see how that’s possible in this case without inventing a special double wrapper class and doing the maths on that with special methods or something, since mutating a primitive referred to in several places won’t happen.
Please someone point out what I’m missing here.
What’s clean and minimal about that? Just make functions first class types and they can fit consistently with the rest of the syntax. I admit that the # and use of annotation do smell a bit fishy.
The thing is, it seems simplicity in one dimension frequently entails complexity in another; make an operating system appear* simple to use, you often need to introduce more sophisticated technology to facilitate it.
To make a programming language able to express certain things neatly at a high level, it can serve to complicate the language. Of course great care needs to be taken to prevent this from backfiring… but I don’t think avoiding closures is an example where they’re better off being left out.
IMHO it’s just the nature of progress that we build higher level abstractions, which tends to have the effect of hiding exponentially increasing amounts of complexity. When these levels are hidden behind an abstraction, then there’s the chance of the underlying implementation being improved while the interface remains identical.
Personally, I’d love to see something like LINQ in Java (provided it was well implemented)… but at least I can appreciate that really would complicate the syntax.
If you really want a simple, consistent, syntax… you could always use Lisp (maybe Clojure).
Agree 100%
People have no problems creating complicated overblown designs but create an annon inner class… OMG… this is too much!
Personally I think it is just people wanting to add a new feature every day.
I think Java needs more improvement, but not this way.
Nearly, I think it is less language envy, but more the pressure from the developers.
I can only imagine people complaining ‘well #C allows/did it’. This path leads to what happened with C++.
IIRC even Bloch wrote that he thinks Generics was a bad idea. (from the book ‘Coders at work’ IIRC)
Language Specification should not be a popularity contest.
I also do not like certain stuff, but I accept the design and actually am happy that the Java language is still very clean.
And yes, it is often more code. And?
Also it should be noted that you can make any kind of code ugly and hacked or clean and beautiful.
I wander when someone is going to ask for first class object continuations in Java.
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme-Z-H-15.html#node_chap_13
[quote=“xinaesthetic,post:37,topic:34557”]
I’ve been influenced by functional programming when writing Java for almost a decade now, and I still try to do the occasional Project Euler problem with SML to keep my hand in, so I’m not anti-FP, anti-first-class-functions, etc. However, adding them to Java now is bound to be kludgy. Deciding what should be a first class type is something which should be done when you start designing a language, not after distributing millions of copies with which you need to be backwards-compatible.
To me it makes more sense to negotiate to bring Scala or Clojure in-house and take a .NET-style approach of officially supporting multiple languages which compile to the same bytecode and can easily interact with each other than to try to make one language serve as the jack of all trades.