Funny you should say that:
http://www.java.net/blogs/forax/
At least the experimental jvm has them right now.
Actually that is very cool if kept behind as syntactic sugar.
You know you want for each generators.
And that blog entry proves my point:
[quote]I have always wanted to have generator in Java. After all, Python have this feature, Ruby and C#(*) too.
[/quote]
@Continuations:
First thing I though when I read a summary was … ‘is a GOTO by any other name not just as evil?’.
Pls, stop turning this into C++/C#!
There’s nowt wrong with C#, lad. Well, maybe not completely nowt, but it’s not C++.
In case someone missed the point i was being ironic. I prefer Java to stay within the mutli-threading/imperative programming paradigm.
The biggest stinker in Java is by far generics. I would rather see this fixed to be more intuitive and less restrictive.
And also remove primitives. Everything should be an Object. A good compiler can optimize simple immutable objects to be as fast as primitive objects.
I meant this as an analogy, not literally. Looking at it from a constructive manner (as you stated), Computer languages are formal systems and as they are made more complex, serious design issues are possible, such as undecidabity and ambiguous grammars.
WRT: “Operator overloading”. I explictly stated that “my issue” is with the argument that it leads to bad programming practices. It is impossible for a language design to prevent bad programming. There are reasonable arguments against polymorphic methods (of which operator overloading is simply sugar), but I don’t think this is one of them. If you have a language with method polymorphism, I like operator overloading because a fair amount of my work is mathematical in nature and it’s a nightmare to read/write without. (As an aside, was anyone played around with Fortress?) When the number of operations is small, it doesn’t really matter, when large…it’s a really issue.
Assuming this wasn’t a joke: There are plenty of purely OO (or prototype based) languages available if this is truly what you want. The compilers in current VMs are not great at basic optimizations and transform objects into primatives would not be easy. This is because of the dynamic loading/compiling/linking nature of Java. It would require a good lifetime compiler framework to make feasiable. This suggestion would be an entirely new language…besides Java doesn’t have operator overloading. 
I wouldn’t want primitives to become Objects. That’s why they’re primitives! They’re the tacit admission that somewhere underneath the JVM is a real machine that only understands primitives, and some of us like to be assured that they’ll behave in nice predictable primitive-like ways. The point about Objects is that they’re pointers to other data, and primitives aren’t.
Which sort of leaves us wanting lightweight objects in the language doesn’t it (ie structs). (Not MappedObjects)
Cas 
You already have direct buffers. Why would you need yet another primitive data type and how would this work with generics? Just look at what happens when mixing primitive arrays with generics already.
" The compilers in current VMs are not great at basic optimizations and transform objects into primatives would not be easy. This is because of the dynamic loading/compiling/linking nature of Java. It would require a good lifetime compiler framework to make feasiable. "
Every VM uses primitive data types but these are usually hidden away in VM code and not accessed directly like you do in Java. It’s the compiler and not the VM that does this kind of optimization and decides when it’s safe to convert an object reference to a VM internal data type, but this would only be visible if you looked inside the generated VM code.
arrrg, you’r crazy ! dont do that
[quote]WRT: “Operator overloading”. I explictly stated that “my issue” is with the argument that it leads to bad programming practices. It is impossible for a language design to prevent bad programming. There are reasonable arguments against polymorphic methods (of which operator overloading is simply sugar), but I don’t think this is one of them. If you have a language with method polymorphism, I like operator overloading because a fair amount of my work is mathematical in nature and it’s a nightmare to read/write without. (As an aside, was anyone played around with Fortress?) When the number of operations is small, it doesn’t really matter, when large…it’s a really issue.
[/quote]
operator overloading is nice sometime but I think that it maybe confusing in many many case.
I find pretty nice to use somthing like the following that let me write easy undertadable code :
public Vector add(Vector v)
{
x+=v.x etc...
retur this;
}
public Vector mul(double m)
{
x*=m etc...
retur this;
}
//then you can write things like below wich I found are less confusing, and with one you are not limited by the number of operators :
v.add(v2).mul(v3).div(2).normalize()
you simply have to read from left to right (no operator priority problem)
“Structs” are just Nice Ways of accessing clusters of primitive data types. Look at the complete joke that is Java’s tuple/matrix handling ability, or complex numbers. At least one of those things is something that games programmers could really, really do with in Java because current handling is the opposite of “elegant” and “simple” and “intuitive”.
As for how it works with generics - well, it wouldn’t, just like primitives don’t. But I think generics get abused a little too much anyway. They work fine, they’re not too complicated if you don’t try to over use them, and the new Java 7 syntax for inferring generic type sigs should make them far less verbose.
is just hideous. How about
public operator Vector add(Vector left, Vector right) {
return new Vector(left.x + right.x, left.y + right.y, left.z + right.z);
}
public operator Vector mul(Vector left, Vector right) {
return new Vector(left.x + right.x, left.y + right.y, left.z + right.z);
}
etc.
(v add v2 mul v3 div 2).normalize();
where operator is a new keyword which defines a static method that can take 0, 1, or 2 arguments? You’d them import static Vector.add; as normal.
Cas
and in the samle above you make 4 new, say welcom to the garbage…
[quote=“DzzD,post:51,topic:34557”]
That’s not the point. Besides, 7’s escape analysis should be able to optimize away object allocations in that example.
My 2c on operator overloading; I personally never code outside an intelligent IDE and I’m assuming most of you don’t either. For me, modern programming and the size of applications being developed the past decade would not be possible without these IDEs doing the kind of code analysis they do. Code isn’t simple text anymore. C++ didn’t have intelligent IDEs 20 years ago when operator overloading made people lose their hair. Java on the other hand is being powered by these tools, it’s part of its success. A scary “+” in a .java text file is not so scary and mysterious and error prone in an IDE that has done its analysis and understands what it is. I don’t know, in this context, the arguments against operator overloading sound exaggerated to me.
[quote=“zingbat,post:48,topic:34557”]
The Sun compiler makes no optimizations at all. It leaves them for the JVM to perform at startup and runtime. This allows the optimizations to specifically target the platform it’s running on. I believe the IBM compiler does optimize code, but it’s only small minor stuff.
no it wont because it would result in an “incorrect” code, you call a method and intend it to allocate a new object that will make you initial object not modified, this kind of optimisations cannot be made by escape analysis and even futur one because optimized & unoptimized code should give the exact same result and reaction for any possible case.
you can turn it in any sense but knowing a little what the language do behind will always be necessary, Java is not slow for sure but lot of programs made in Java are (eclipse is one exemple from many others EDIT : or a better exemple : JavaStore wich requiere high end PC to display two Icons… pfff… what a shame…) because lot of Java programmer have ( are formed with ) this view point wich is : I dont have to bother in optimizing my code this is just a stupid old scholl way, and this is just IMO a wrong way, what make the strenght of C/C++ vs Java is just programmer approach because in C you are forced to take care of how your code will be understand by the computer. I did tones of web business application in Java and it is fine to use heavy IDE/Framework for such program because nobody care if they are just damnly slow and if requiered then you just add a new server… but for desktop application having this approach just result in making people think : Java == slow.
for example think about adding String : wich is one overloaded operator in Java
in a critical realtime application, most people dont know that there is an allocation inside s=s1+s2 and you can encouter this kind of problem where people was just lost because of the slowness of their program, changing two line resulting in 100% speed gain when this kind of operation are in a time critical section of the code.
and most people aware of this issue / slowness will just NOT use s=s1+s2 but implements their own or use other String manipulation object
[quote=“DzzD,post:54,topic:34557”]
Well, you’re wrong. Even if we assume that the result of (v add v2 mul v3 div 2).normalize() escapes the current context, with escape analysis only one object would be allocated, instead of 3 or 4. Again, this is beyond the point of whether operator overloading is good or evil. You could write add/mul/div/normalize so that no objects are allocated.
As for string manipulation. First of all, Java compiles string concatenation to StringBuilder (StringBuffer on older versions) allocation, x number of appends, followed by toString(). So, of course you’d use something other than “foo” + “bar”. But why not use operator overloading for StringBuilder’s append (or whatever custom class/method you’re going to use)? 
so let’s try it and compare !
I like how you are faithful
but… anyway let say that god exist and it create the world with some kind of magic stick… (pff something get into me and write the previous sentence, this is not me argg get out !) : abstracting again and again (as adding libraries in the core) will just make java fall into something that I would call “the VisualBasic syndrom”, my point is that there is a limit of complexity/abstraction/help that make people dont use libraries/language features or IDE features or use it very bad in different area : JavaFX / Spring / Hybernate / Eclipse / WebSphere / hundreds of others => all offer thousand of useless features, are hard/impossible to fully use, are memory killer & damnly slow, operator overloading is just similar but in a different computer area (language), Java Generics is one in the language area.
That’s OK for translating byte codes to native code but in this case you are optimizing at an higher level, deciding in what context an immutable object like Integer can be safely replaced by an equivalent primitive data type. This is an obvious optimization in many cases and the compiler should do this automatically.
Well, you’re wrong. The JIT seems to know how to inline methods pretty well, so once it inlined everything into everything, there is a fair chance that even that ‘last’ object does not escape the ‘new’ current context.
DzzD: yes, you are in fact wrong. EA completely removes object allocations like this, except where they are actually required for code correctness, leaving you free to write clean and simple looking code and let the machine do the hard bit of figuring out how to implement it fastest. Which is what Java has been doing all along for us on many other fronts.
It has to be said though that EA is not actually here yet, except in Excelsior JET. BTW has anyone here tried it recently? I used it back in v3.5 days or so and it was utterly, blindingly fast compared to the Sun JREs of the day (2003 or so, 1.4.2)
Cas