Java’s concurrency primitives are pretty decent, largely the same thing you get in POSIX, and otherwise lacking things like channels or logic variables. What does make Java awesome is that it gives its primitives precise semantics (especially since the JMM in 1.5) that are guaranteed to work across platforms. That’s the sort of WORA I like in Java – god knows it’s not for the beauty of the cross-platform GUI toolkit 
There are other ways of doing concurrency that offer advantages. But comparatively Java does pretty well in that regard, especially when compared to other mainstream languages.
I, for one, love operator overloading in the kind of calculations typically done in shaders. Not much else, oh, and in String concatenation.
I’m not sure what you mean, the only operator that I say is “bad” is paren since it can change the meaning of unrelated code. Any operator that doesn’t fall into this kind of category is a good candidate as far as I’m concerned. As an example, I sometime think that Mathematica doesn’t support enough operators. Oh and I say that the C++ stream thing is ugly.
What, you don’t love:
HashMap<String, Double> foo;
...
foo["Pi"] = Math.Pi;
Thank you language nannys for giving me the most useless operators possible.
Eeergh, is that going to make it in to Java?
The problem I see with operators is simply being able to read the code aloud in your head. As all of those co-opted ASCII symbols already have pretty much one and only one word to describe them when reading them in your head, trying to make them mean some other word is bound to end in confusion and tears with other developers.
Cas 
Parentheses mean “apply”. It makes perfect sense to define application for more things than just functions that were defined with the built-in syntax. A map is essentially a partial function from its keys to its values, for instance, so I actually find users(“sproingie”) a lot cleaner than users[“sproingie”] for instance, because I don’t have to care whether it’s a function or “indexable object”. That’s the essence of polymorphism right there, and if it’s too “spooky” to make application dispatch on the thing to the left of the parens and not just the things on the right, I don’t really have anything to say other than to demand a more rational basis for objections.
Yes. All Map interfaces auto-magically have overloaded array get & set. In JDK 8, if I’m correct.
Like I said…most people don’t get how evil the lack of operators is until their forced to do without.
sproingie: You’re missing my point. Re-look at my example. If that code segment is written before the matrix had two param paren operator defined, it returns the local function ‘m’. If at some point in the future the matrix class defines an operator that returns the value of the matrix at the position, then the meaning of the code in my example changes. That is very bad design.
Actually, I suspect you’d need to recompile the code in the snippet to get the new behavior, which I suppose is better or worse depending on how you look at it. That’s just how it is when you have multiple namespaces in a language. I would expect a compiler to scream about it, but that’s obviously not going to happen with separate compilation.
::m(a,b) if you really care …
Agreed which is why I wouldn’t mind seeing a vector math library incorporated into the standard library with appropriately overloaded operators. Interestingly String concatenation is actually a pretty poor example of operator overloading because addition is commutable whereas string concatenation isn’t. That said I have gotten so used to it I can live with it (VB uses an ‘&’ operator for string concatenation which is probably a better idea).
Standard vector math library usings structs with SIMD optimizations would give a lot performance for many use cases.
True, but when considering adding features you must contemplate both good and bad usages as in the end, the feature will be measured by them.
As do I, but I know they can be a blessing and a curse and what where such leads to.
Today, with my 20/20 vision, I would be totally against it.
But overrides are not the only problem. Defines were equally good and bad. IIRC the first Game Programming Gems had an example of how defines could basically be used to create a ‘pseudo code’ language for AI.
On the other hand, there are the many ugly examples of defines jungle.
Finally, for a language like C/C++, where the developer is basically free to do what he wants, I have no problems with these features.
But in Java, where we do have a more ‘restrictive codex’, I do not see how it fits.
WRT: Java’s great concurrency support from day one. I’m not getting it. I haven’t read the JVM spec since version 2 was released so maybe I’m forgetting something obvious. All I recall is that reads/writes of 32-bits and less are insured to be atomic (wank, wank) and that a write that occurs at time ‘T’ is insured to be visible to all threads at time > ‘T’ (wank, wank, wank). Every VMM (other than on embedded systems) that I can think of insure both of these…so what am I forgetting? (All the Doug Lea stuff is much later and doesn’t count)
sproingie: Yes indeed the code would need to be recompiled. Why introduce a problematic syntax to start with? Avoid the problem. Do this instead:
user.("FooBar");
m.(0,0);
I’d agree that this isn’t quite as clean, but it’s logically consistent and doesn’t consume any new syntax space.
I strongly disagree with this statement. A language cannot prevent “bad” (in quotes because it’s mostly subjective) usage. It should only consider the usefulness under reasonable usage, if it “fits” from a paradigm perspective, the impact it will have on existing features and if it will make it harder to introduce a more desirable feature in the future due to using up syntactic space. Weigh these against the cost of implementation and decide from there. Joe average and Frank n00b are going to make mistakes, which they will hopefully learn from. Chaz Iuseeveryfeaturecauseitsthere…well nobody can do much about him and he doing just fine making a mess without feature X, so one more won’t hurt.
Why is that? In the context of Java you’d just a few refactor clicks away from ripping it out. But ignoring that, why would you be using poorly design code in the first place? If in a corporate environment this pops up, then the problem isn’t operator overloading but lack of mentoring, code reviews, peer reviews, design specs, coding standards … a.k.a the management chain is dropping the ball.
The stages of operator overloading transcendence:
- I will rage quit if my language gets it.
- OK, in the narrow case of stuff that interests ME, then it’s okay. Everyone else can go !
- OK, I guess that other people actually do have valid usages.
- What? How did I ever live without this.
You moved quickly from stage 1 to 2, so all you need to do to get to stage 3 is realize that a future you might be in the “everyone else” category.
Man, I’d total hate if SIMD ops are exposed WITH operators when structs are rolled out. All the anti-operators kids need a little dosage of their own medicine.
But again, for me operator overloading is a very low priority in Java. I can make all the syntax sugar transforms that I want without official help. Structs (with SIMD and cache hints support), concrete arrays, et al stuff in this vein are way more important.
But really, lambdas? Which we’re getting and you kids are worried about problems stemming from trivial sugar like operators? This is gonna be a much bigger can of “bad coding” worms (Go Chaz! Go!).
Depends what you’re comparing it to I guess, but IIRC C and C++ guarantee neither of those things, which makes it pretty fragile to write robust multi-threaded code (doubly so if you want it cross-platform).
The hardware’s VMM (virtual memory manager) insures. Therefore I get that in asm and all higher level languages.
On which platforms? Because you don’t on ps3, and I’m reasonably sure you can’t guarantee it on desktop platforms too.
SEE: That I specifically stated non-embedded systems.
I am actually at (and always have been) a “stage” that you didn’t mention that consists of the following:
a) I will rage quit if my language gets it.
b) The opinion that operators are part of the definition of the language and should not be redefine-able.
c) The few use cases where it is a good idea should be part of the language definition.
The problem here is the definition of ‘c’. Whom decides for everyone else? Why does some tiny subset of non-primitive types get special treatment? I don’t mind if a language doesn’t support anything other than what’s consistently consider to be primitive. It’s the middle ground position that I can’t stand.
I haven’t made a game in Java for years now. Why did I start using it? It was the first capable programming language I learned. I knew Flash before that point but Flash is obviously limited, and this was back before ActionScript 3. Now why am I no longer really using it? Because Unity is just 100x faster and better for game development than Java is. Getting my visualization of what’s happening all the time, easy changing of parameters etc., and having all the boring stuff (graphics/sound support, physics, scenegraph, blah blah blah) already handled is excellent.
So what do I do? I just write the game, happy days.
That being said, I am now professionally working in C++ and I hate it with a passion. It takes me 10x longer to do anything. I was just trying to do string.split() but instead had to some kind of crazy string iterator and stream outputter and crap.
The big thing for me is that I just want to make my game and I don’t want to worry about performance or anything like that until I have to. And even then I don’t want to worry about it. I even like Javascript pretty well right now, although there is no play button to see my game go.
I will admit, the massive amount of effort I need to put into Java to get my game to actually happen (webstart / applet / whatever) is the number one deterrent for me. In Unity, I press export and I’m on all the platforms I could ever care about.