Starglider wrote:Really, then why are you writing this program in Java? I regularly write high performance algorithmic trading code in C++ (unfortunately, hope to get back to OpenCL soon) and I still prefer doing it in Java.
Because I want to. Basically, I dislike working in Java but it's a skill that's essential to have these days. So this is as good as time as any to get some practice. Especially since the actual code is rather trivial but the GUI is complex so it helps me practice the one part I was newer good at.
Language convenience during initial developmet is only the most important thing if you are lone developer making small programs. For serious enterprise applications, the quality of the runtime and libraries and the robustness and maintainability of the application are far more important.
I am not saying you are wrong but I disagree. Which of the two is a priority depends on what kind of program you are making. You seem to have a background in commercial applications, possibly for large clients. At least I deduced as much from your priorities. You value a system that is easy to maintain and robust so it won't crash or cause unexpected errors. And that is good if your software needs to work like that. But not every software does. Nor does every application value quality over speed of development.
Say you aren't making software for a bank but a video game. Suddenly making stuff work quickly and easily becomes a much higher priority than making it maintainable or crash free. Because you can expect people to pay for your stuff even if it's buggy as long as it's done in time for the next big sales season.
I like C# for writing toy programs but the VM is nowhere near as good as Hotspot or Zing : the question of 'would you attempt to write an eTrading app in C#' comes up regularly in City of London pubs and the answer is a resounding 'no'.
That goes for anything with a VM, C#, Java or what ever else might exist that I have not heard off. VM's are just inherently slower and less stable than native code. But people do still write a lot of code for them for a reason. And that reason is that not every piece of software is meant to be a super secure bank account application. Some times you just want to write a minecraft.
but operator overloading in particular inevitably results in unmaintainable messes.
Honestly I feel that you are both right and wrong here. Operator overloading is not inherently bad. And I shall now demonstrate it.
How is my_object_1 += my_object_2 any less readable or maintainable than my_object_1.add(my_object_2)?
It isn't. Not in the slightest.
The real problem is people who would use either of those for applications where they does not belong. If your class is not a structure that can be reasonably seen as a mathematical variable you have no place using either and should instead use separate modification functions for each of its variables. But you can't cure stupid by taking away our tools. You can't even make it harder for them to be stupid.
On the other hand if you are working on mathematical problems such as computing geometry than it makes sense to have access to mathematical operators. And if you do not, than having to write functions for every single one of those (Add(), Subtract(), Multipy()...) becomes tedious at best and copy paste work at worst.
Take for example a project I was working on in my free time last year. I was working on (still am but paused due to other stuff to do) a sprite based graphics engine. Just fooling around to see how far I could take it. And part of that was a class for handling angle conversions. I have this class prosaically called Angle which contains the angle value and encapsulates a whole bunch of various calculation methods both standard mathematical (Sin, Cos, conversions etc.) and based on my own specific needs (like direction in my coordinate system). And for that class it made perfect sense to have the entire range of mathematical operators. After all, I was constantly handling those angles and calculating everything through them. So why should I write something like Angle_1.add(Angle_2) when i can write Angle_1 += Angle_2? It's just stupid.
The point of this? Tools are not inherently bad. Stupid people are bad. And the logic of tying our hands and taking away our tools because of the stupid programers out there is at best annoying and at worst harmful because we are distracting everyone from the real problem which is bad programers.
Terralthra wrote:Likewise, I've never seen a problem that could be "solved" by multiple inheritance that couldn't be more effectively solved by single inheritance and proper use of interface classes. In general, multiple inheritance is a massive headache and requires someone looking at your code to hold an inordinate amount of state in their head to understand what any small piece of it is doing. That's the exact opposite of what you want.
I actually have run into situations where multiple inheritance would have been useful in the same project I mentioned above. It was not a strait up case of it being necessary but it would have saved me a lot of duplicating code.
Basically, imagine a situation where you want to separate out a certain functionality (like say collision or movement) into its own class because you know said functionality will only have a single implementation ever and more importmantly because you have some external system to keep track of everything and run the place (like my main timer). So you have one class which is for movement and one for collision damage. Now say you want to have three objects on the screen. A space fighter, a projectile and a wall.
The space fighter only inherits from the movement class. Since it is not a ramming weapon and does no damage on collision.
The wall only inherits the collision damage class because it's a fixed projectile that stands in your way and hurts you if you touch it.
But the projectile needs to inherit both. It needs to move and do damage when it hits something.
In my case, the issue was massively more complicated but it boiled down to this. Now you can do it through interfaces and resign your self to having copy paste duplicate code implementing the same thing in every inherited class. You can also do it by having a single joined class and than hacking it so that the fighter does 0 damage and wall has 0 movement. Or you can start from scratch.
But the question is not what you can but what you should be allowed to do. And there is no logical reason why I should not be allowed to do something that is useful just so as to protect me from misusing it. By that logic we might as well ban automobiles because, as useful as they are people abuse them to street race.
