@Wilson: I couldn't even begin to write server code, which is why I'd let someone else sit with the hassle of doing so.

This will (unfortunately) only happen if you can hire a team of highly skilled programmers. So unless your budget is huge, you should probably listen to Thrustwolf's advice

Even if you aren't a programmer, you have to acquire an understanding of what's feasible as a hobby-project. Many parts of your project sound incredibly complex -- really cutting-edge stuff. Something only a big company could hope to accomplish.

The last few months to years, the Linux has gotten better and better but the desktop environments have only got worse.

Yes, it's in a bit of a flux right now. It's one of those situations where it has to get worse before it can get better, unfortunately (Gnome 2 was apparently a mess code-wise). But KDE is pretty good now (albeit with a few stability issues), Unity is quite nice for small screens and Cinnamon is looking really promising.

So it's pretty good now and several of the interfaces are moving in the right direction. With Windows you are tied to a single option and that options seems to be going to hell.

It's getting better by the minute; over the last few years the platform has matured incredibly. We have an ongoing explosion in Linux gaming, in large thanks to Ubuntu, Humble Bundle, Kickstarter and soon Steam.

How is it that the software world is getting these huge setbacks in openness and accessibility? Wish there were something we could do to turn it around...

There is! Get people to move to Linux
I have successfully done so with family and friends.

If you're going to do that, go Fedora. A little less bullcrap there than with Ubuntu.

There is generally more software for Debian/Ubuntu-based OSes. Steam will only have official Ubuntu support to begin with.

So I would encourage new users to go with something in the Ubuntu family. The most important thing is to pick the one with the desktop-interface you like the most. If you don't like tablety interfaces then standard Ubuntu may not be for you. There are several good OSes in the Ubuntu family, for example Linux Mint (with Cinnamon), Kubuntu, Ubuntu or Lubuntu.

You are supposed to get some initial bug anyway, even if you know exactly what you are doing.

And assembler is enough for me to do anything

I don't see any value on why I should use this technique
while I can just do the same with pointers

APIs in languages with multiple return values are more intuitive and elegant. Relying on a combination of return values and side-effects is an ugly (but necessary) work-around in C++ that people have learnt to live with. Just as you get other ugly work-arounds in Java.

In that special case it would be nice to have multiple return values. Both I and the creator of Java agree with you there.

I just don't think that the options you have in Java are worse than the options you have in C/C++. In Java you'd return a wrapper object (idiomatic) or pass a wrapper object (C++-inspired). In C/C++ you'd pass a pointer. They're just all bad at it.

You may get some extra overhead in Java, but that's generally the case anyway. In return you get more IDE-magic to make up for it.

I guess you do get some extra overhead if you just want to return a few primitive types. But that can't be very common? Or maybe it is in some areas?

Usually you use other design patterns Java. Where the side-effects don't result in extra return values but rather in state-changes to the object you are calling the method on.

I'm confused. C/C++ don't have multiple return values either, so I'm not sure why you'd prefer them in this case?

If you really want to, you can use the C/C++ style in Java with mutable objects instead of pointers. It's just not very idiomatic.

Code:

boolean raycast(RayCastData dataOut) {
   boolean completed = false;

   // do some stuff
   // ...

   if (completed) {
      dataOut.x = someX;
      dataOut.y = someY;
   }
   return completed;
}

Then you'd just reuse the same RayCastData wrapper class for each call.

But there are other ways to do it, that are more elegant and just as efficient. For example letting the RayCast class (which has the raycast method) hold the extra data after each call.
 

Sorry, I was a bit vague. I meant vectors when I said arrays.

Java doesn't have a C++ style vector as a language primitive. Instead you use classes like ArrayList. Since it's a class you can't use primitive operators on it.

But it would be nice if [] could be added as syntactic sugar for classes that implement a BracketAccess interface. It could just be used as a shorthand for get(int index) and set(int index).

But it wouldn't make sense to just add it to the ArrayList class.

Either way, even if strings are immutable, I still don't see why you can't have [] just to read the letters.

Hmhmhm, it would look a bit strange if you can't use it to set stuff. But I guess they could have added it anyway, but it's not the obvious design choice.

Let's not talk about any languages that don't trust the programmer enough to give them basic operator overloading

God, please, no. It is a well known fact that programmers can't be bloody trusted.

You work directly against objects and I don't see when you'd need multiple return values for that?

ChevyRay posted a perfect example - for something like a raycast, you really want it to return a boolean so you can use it in an if statement like that, and if it returns true, there's a bit of extra information you also want to get back.

That's not a very OOP thing to do. You're calling a function and getting the result back, rather than working against an object that changes its state. In this case it's the right thing to do anyway, and as I said before it would be nice to have multiple return values for it.

But you'd probably just return a RayCallResult object. Which has a method didComplete():boolean and optionally all the other data.

no [] operator for arrays/strings?!

If I understand you correctly you are incorrect. Arrays do indeed have a [] operator:

Code: ("Java")

Object[] array = new Object[5];
array[3] = new Object();

Strings do not, however. This is probably because Strings in Java are immutable (= good design choice imho). If you want a modifiable String-array you can (for example) use one of these:

Code: ("Java")

byte[] bytes = "abc".getBytes();
char[] chars = "cde".toCharArray();

Both me and James Gosling wish he had added multiple return values when he created Java. It is indeed a weakness of the language (and most other C-like languages).

There are several possible ways to design around the one-return-value-problem.
(pointer re-assignment looks absurdly ugly to me, though)


In Java many cases take care of themselves if you write in a good OOP style. You work directly against objects and I don't see when you'd need multiple return values for that?

In the few cases where you actually need multiple return values (some library/server returning multiple results) you can wrap the result in an object created specifically for that. If it's an asynchronous call you can just add a few extra fields to the event class you're using.

To properly learn a new language you have to learn new design patterns and idioms.

What exactly are you trying to do? I may be able to suggest a suitable Java design pattern or two.

Um, yes, I guess. But then it's not your server that's vulnerable, as it's already hacked.

Yes, it can. But how could that lead to DDOS attacks or using user's computers to brute-force admin passwords?

[kamac]

Assuming you are vulnerable to XSS, you open yourself to other means of attack. .. Once you assume data received from the client-side Javascript can be trusted, you a provide an easy vector for the attacker to

1. execute DOS/DDOS attacks,

2. brute-forcing your admin account password using your users' PCs,

You seem to be confusing XSS with server vulnerabilities. Which one are you actually talking about?

Could you elaborate a bit on these two points, please?

1. Why would it be easier to DOS/DDOS if the server trusts data that some source sent?

2. How would the attacker get access to a user's PC, just because the server trusts the data it receives?


kamac: Please note that all the server-attack scenarios presented here are..
1. ..vulnerabilities in the server-side software, not in the actual JavaScript. If the JavaScript doesn't send things to the server you are completely safe from them.
2. ..not generally a problem if you use big, reliable open source software that has been properly designed.
3. ..sort of overly paranoid scenarios. If you don't have anything really sensitive on your server (and do keep backups) you don't have to worry too much.

I'm not interested in winning the debate with J-Snake, as I think he is both delusional and determined to get the final word. But I thought it could be helpful to educate others on this topic. But if my posts aren't of enough general interest I'll just shut up now.

Every software you create can be considered a special case.

I'll rephrase in your terms: there is an infinite number of special cases that can't be proven to be correct/incorrect.

Even if you are only given a single program that you need to verify for correctness it is in some cases impossible to do so (unless our brains are hypercomputers).

This sets the limit for what is theoretically possible to do. Practically speaking, there is no chance in hell that you'll be able to prove formal correctness (complete buglessness) for a decently sized game.

The way you act is like this: You don't know the rules of chess but you simply try to figure them out just by looking at countless plays.

Actually, no. Formal proofs of correctness look at the definition and try to show that the definition is clear in every case and that the implementation correctly follows the definition. It's not the other way around, as you seem to assume. Doing this for an arbitrary program is theoretically impossible (but is possible in many special cases).

On a side note. Chess was actually bugged for a very long time. It wasn't clear when to end a game that looked like a draw if the two players couldn't agree on it. So a game could go on indefinitely or (if playing on time) turn into a game of dexterity and stamina where you had to make your moves as fast as possible until the opponent ran out of time. Different "patches" were used for a long time (some as old as the game), but it wasn't properly standardized. It wasn't until 1992 that we got the current version of the game, with the strict fifty-move rule:
http://en.wikipedia.org/wiki/Fifty-move_rule