Yes, operator overloading can definately give room for confusing code. I would like it just for my own types (i.e. no changing the behavior of the build in classes), and even then one would have to be very careful when using the feature. Also, JavaDoc would help alot I think. It's not something I miss alot, but something that would be useful sometimes.

You would have to fix Generics to allow primitive types and do away with type erasure. You also would have to worry about extended classes. Overriding the add operator could throw in some odd behavior, and even if you made an exception to prevent overriding those methods you might want to make the entire class final just in case one method relies on another. Then for human compile time checks, you lose the ability to glance at an expression and say "That looks like the method signature of this type of function, therefore its reasonable the code has this type of semantics." I don't want to have to scroll around, check if I'm working with primitives or Objects, find every variable declaration, parse the expression, determine which overloading methods get called, mentally convert from infix notation to postfix notation, double check the meaning of each overloaded method just to make sure their are no quirks in the semantics of that operation, trace through the return values and side effects of each operation, then make a different mental map that's basically the same as the multi-line procedural format.

At the same time you lose the ability to easily make sense of arithmetic expressions. It's faster to look at an expression with familiar order of operations as in ordinary algebra. You could still overload + for concatenating and not lose anything because its obvious, behaves differently, and can't be used with other operators without conversions or parentheses. When it comes to most things, though, the use of operators tell me something useful about how primitives are being used and the use of explicit function calls tells me something useful about the way objects are being used. Mix the two, and certain blocks of code will force you to break your train of thought even if its shorter than the other version in some cases. Think of the line a = b * c; Now you have to figure out if this is a scalar-scalar multiplication, scalar-matrix multiplication, scalar-vector multiplication, matrix-matrix multiplication, vector cross product, vector dot product, or something else entirely. Then a * b may not necessarily even be close to b * a and may be defined in two different places. a = 0 * b[/t] does not necessarily mean a stores something like zero. It wouldn't be too hard, but, as Java is now, you don't currently need to methodically and roboticly parse code or learn how entire libraries work inside and out. It's like untangling headphones. Not impossible, but a huge productivity killer. Although it would be nice to use operator overloading with things similar BigInteger and BigDecimal and more efficient software implementations of types with different levels of precision than built in primitives, its not worth the trade.

quick question, am I the only one around which do not think that type erasure is bad, but quite ellegant.About operator overloading, everybodz here seems it can be bad if others use them but will not if only them use them in their own code. Why not use same Scala function classes in your Java code. One can mix Java with Scala code in the same applications with no problems(little changes to your build configuration) and Scala is an ideall language to build your own Domain Specific Language where you can overload as much you want and what you want.

PS: seems as if java-gaming.org is not banned in china, so I can at least access on of my most visited sites

I think type erasure was a great solution to get something that looked a bit like templates working backwardsly compatible with existing Java bytecode. It has its flaws and foibles but the way I use it it's all good. I especially like the new <> shortcut in Java 8.

Operator overloading I see as necessary (even mandatory) if you are designing new types.

I see that many of the complaints being posted here can be solved by something external to the coding language: Project coordination.

No, seriously, I see this on a daily basis at work, powerful tools have dangerous implications (like a chainsaw), and when you have a room full of chainsaw-wielding maniacs, you need some proper structure if you want to get anything accomplished (And before they start chopping each other down).

Of course, then the question is.... What is the goal of Java? If it is meant to be used exclusively as a high level language, then by all means all these dangerous bits would need to either be locked, or made available through some advanced API (much like JNI).

If, on the other hand, we want to integrate low level capabilities.... Well, you can't make a chainsaw without the saw.

Type erasure only exists because it didn't require changes to the verifier. The sad thing is that the verifier was being changed anyway (and was in the next version of java). Type refinement is very not fun with type erasure...well type erasure adds yet-more boilerplate and hacky work-arounds. What up-side is there (other than it pushed it out the door a little earlier)? I can't think of any.

Operator overloading: Forget everything you think you know if you're opinion comes from C++. Getter/setters are the one most important that java could use and would need to be VM aware (aka not-just sugar). Other stuff is sugar and you can just slap it on top yourself.

(Oh yeah, needs to be VM aware cause it would suck otherwise...simple example changing a public field to a getter/setter. Code using would need to be recompiled with identical source to work...that would be too horrible).

Using getters and setters everywhere is a symptom of not really understanding OOP though. Not that I want to spell it out but: if you're going to all the trouble of hiding the implementation of a class by making all of its member data private, and then expose it all with trivial getters and setters, what exactly have you achieved. Nothing much apart from a lot of typing, and you've also managed to expose the entire internal state of your class as public API which means you can no longer change what's under the hood without breaking everything that uses it.

So for the love of whoever you want to love, keep getters and setters to the bare minimum required for tool interop (eg. Javabeans*)

There's nothing really wrong with type erasure per se -- even Haskell uses erasure -- but the problem is that Java lets you use a raw type with nothing more than a warning. The spec says that a later version of the Java language could remove this ability, but we all know the score: nothing ever gets removed from Java, especially now that a lot of programs have come to depend on this behavior.

Scala works around erasure a lot of the time by generating and passing manifests at compile time, but there are still things manifests can't fix, like overloading or pattern matching on List<Foo> vs List<Bar>.

It does mean you can't do something like implement Multiplyable<Matrix> and Multiplyable<Double> (Big or small 'D' double...) in the same class. (I wish I could think of a better example, but this is the only non-obscure, non-trivial example that comes to mind.)

I have been racking my brains for days trying to think of something I dislike about Java to post on this thread, but I can't think of anything. The language is fine - generics took a bit of getting used to, but they are a great feature. If generics had been built into the language from the outset, they would probably be done differently without some of the limitations mentioned in this thread - but don't forget that many of the early Java features had serious flaws and needed major rebuilding (threading, AWT etc) - so adding generics at a late stage may actually have given us a more mature and workable system.

It would be nice if Java had some built-in vector types to make use of SIMD instructions.

You know, most of these things brought up in this thread are pretty unimportant IMO. I would imagine most of us have used languages with or without operator overloading, lambdas, various kinds of generics, properties vs getters/setters and none of this makes a squat of difference to whether you can produce good code in language X.

The number of people I've seen swear black and blue that you can't use Java because it doesn't have syntactic sugar Y. It's rubbish. For me, the best reason to use Java is that mistakes fail early and verbosely. When I f**k up, it tells me where and why rather than failing silently like Javascript or crashing the machine like C++. As a whole, I like the language features in java but I doubt anyone would leave if some of these decisions were one way rather than another. I don't like operator overloading - I have worked with C++ in large dev teams and as Cas alluded to, that can get painful - but if it were added to the language I'd embrace it the same way I now use generics although I never thought the language needed them, either.

Personally I'm not against annotations having actual semantic meaning (rather than just compiler/documentation guides), but there's some horrific over use out there. But then you can write horrible code if you (ab)use any language feature.

Two things: i can cope with Java cause it allows a team of differently skilled people to work with each other. It has so little syntactic sugar that almost anyone can read and given a little time understand most of the code. There aren't to many ways to severly shoot yourself in the foot either. I could not imagine working on anything > 2k LOC in JS with a team spanning novices coming straight from univ. to seniors.

Also, all the things mentioned here are available in C#. Why aren't we using C# again?

You know, most of these things brought up in this thread are pretty unimportant IMO. I would imagine most of us have used languages with or without operator overloading, lambdas, various kinds of generics, properties vs getters/setters and none of this makes a squat of difference to whether you can produce good code in language X.

The number of people I've seen swear black and blue that you can't use Java because it doesn't have syntactic sugar Y. It's rubbish. For me, the best reason to use Java is that mistakes fail early and verbosely. When I f**k up, it tells me where and why rather than failing silently like Javascript or crashing the machine like C++. As a whole, I like the language features in java but I doubt anyone would leave if some of these decisions were one way rather than another. I don't like operator overloading - I have worked with C++ in large dev teams and as Cas alluded to, that can get painful - but if it were added to the language I'd embrace it the same way I now use generics although I never thought the language needed them, either.

All good points. Often the introduction of new features hinders the ability to create good code and decreases the quality of existing code. Any form of pointers, for example, would instantly eliminate the readability, simplicity, interoperability, stability, security, reliability, portability, and predictability of code - and degrade the usefulness of static analysis and debugging - and nullify the possibility of certain compiler optimizations. Talk about porting a feature from an entirely different language to Java always makes me cringe. Sometimes it is a sign of inexperience. I've seen a lot of people insist on coding in C++ "because it's faster" that do things like use new with every constructor. And on the other hand, some people say things about Java that suggest they know nothing about heap allocation, stack allocation, or garbage collection. Aside: It amuses me to see people C++ programmers casually talk about (quick) sorting strings being significantly slower than sorting other types.

There's a huge difference between languages like C and C++, languages like Java and C#, and languages like Javascript and PHP. C++'s special operators, copy constructors, and heavy use of value type variable assignments makes ordinary coding and working with data structures radically different from Java programming practices. You can't easily integrate every feature from or use the same part of your programming brain in both languages. Users of that final class of languages seem not to notice how strange it is to use regular expressions and built in array functions instead of working with appropriate data types and algorithms.

I don't really agree with the sentiment that things like Generics and properties are purely unnecessary syntax sugar. You can live without them, but Generics is a huge help to write good code faster without sacrificing code quality. Properties are debatable, but very similar to Generics in that respect. It also speeds up coding as a user of third party libraries. I absolutely agree with you on your best reason to use Java. My best reason to use Java is that it makes mistakes easier to find and, more importantly, makes it so much easier to avoid mistakes entirely. There are annoyances in the Java language (enough so that it might be a good idea to reinvent it or invent a new language based on it), but they all can be worked around without sacrificing much and the time it takes is usually tiny compared to the time you save when using Java in large projects or anything involving more than one person's code. It scares me when I hear serious talk about new features from other languages, especially scripting languages.

Once your language is turing-complete, everything is syntax sugar. What I want to see more of in languages is "semantic sugar". When you notice that JDK8 lambdas do local type inference, that definitely fits into the semantic sugar category, and the effects of it will ripple beyond merely more concise code, and toward fundamentally better libraries and/or idioms that use it. When you can express map concisely, it's a quick step to fmap, and just like that, you can wave bye-bye to null. That's the power of semantic sugar.

Yeah, er, it's just that the conceptual leap from lambda to waving goodbye to null is a hard one for us ordinary programmers to grasp after so many years without anything like it. Slowly does it! It'll take a long time to get Java programmers to make the leap from purely imperative programming to functional programming. I know this because of the number of Java programmers I've met who simply cannot write SQL.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org