Well, it's like there is a sweet spot in language complexity, expressiveness, and unknown magic going on behind the scenes, and Java has occupied it quite successfully since around JDK 1.4. Generics were a bit of a mixed blessing as it's now possible to write code that nobody can figure out but it also has a few nice uses. Annotations were handy.

One thing I see in this thread here about C# is that it's "Windows only". It's not at all Windows only. Mono has more or less ensured C#, "the language", is everywhere where Java isn't. .net, on the other hand, is Windows only. Not only that but Microsoft are seemingly deprecating .net in favour of WinRT and Javascript/HTML5 anyway. I predict C# to end up like Visual Basic in the next 10 years. Java however is likely to remain as strong as it ever was through the sheer amount of heavy systems now built on it. But ${deity} help us if we're forced to use Javascript everywhere to do client programming.

I'm fine with JS (I actually do enjoy it a lot), but it doesn't appear to be suitable for larger applications. I wouldn't want to write anything with 10 KLOCs or more, but - to be fair - it's very expressive. You can get a lot done with 10 KLOCs.

What gets me about Javascript is this. It's like one day a small hegemony of browser vendors suddenly decided the entire internet was going to speak in French. You either speak French, or you're out of a job. Now, I have nothing against French at all, and I can even speak French to an extent, but the fact is, my native language is English and I'm about 100x better at it. I don't want to have to speak French. We didn't vote to speak French. But where is the opportunity to protest? How can I say, "No! This will not do?" when the hegemony is not listening?

And now, insiduously, Javascript is finding its way into many bizarre locations like serverside programming*. The same bloody language everywhere. There was a time we could choose what language we wanted to use to tell computers what to do. There were a whole plethora of choices, from machine code and assembler through BASIC, C, C++, Java, C#, Pascal, Oberon, Modula, Prolog, Lisp, Scala, Python, Ruby... and then suddenly, no, the only thing that is supported on the client will be Javascript.

It is suddenly very apparent why the whole compilation phase was so important to everyone. We want to write in the language we want and then deploy binaries which we don't have to look at.

Javascript being the only language has its advantages. Huge companies are throwing massive amounts of resources at it to make it fast. It's gaining on Java fast. In a decade it might be where Java is now.

I realize I ignore the language-design here, but once you have a super fast JsVM, you can start running interpreters / transcoders on it, with great performance.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

From a technical standpoint C# and .NET are superior to Java/JVM. Note that I'm not talking about any specific implementation but the design.

Why? C# is slower, .NET is less cross-platform, why would we consider it is technically superior?

I specifically limited my comment to design and not implemenations to avoid very subjective comparisons. It's superior IMHO because it contains a wealth of commonly needed features which are difficult to impossible to perform in Java. It also makes more nods to the requirements of a back-end than the java does. I'm sure that there are plenty of feature comparisons available so I'm not going to bother making a list. Thinking though the feature set of C#, the main thing "I think" that some java programmers might hate are some of the sugar related features like operator overloading (including get/set).

Quote

The languages which have the most features are not necessarily the best languages in my humble opinion.

I would go a step further and say that they usually suck.

Quote

Look at C++, it has become too complicated, who really knows how to use all kind of pointers? How is able to read any C++ code?

I strongly dislike C++. But its problem isn't the features that it provides, but the syntax by which it provides them.

Javascript being the only language has its advantages. Huge companies are throwing massive amounts of resources at it to make it fast. It's gaining on Java fast. In a decade it might be where Java is now.

I realize I ignore the language-design here, but once you have a super fast JsVM, you can start running interpreters / transcoders on it, with great performance.

true, but it would been nicer if the focus was on some sort of web bytecode instead, thus allowing any languages to be compiled down to it more efficiently. The fear that it would make the web closed (ala unreadable like compiled code) is pretty much irrelevant now since obfuscated javascript is widespread anyway.

@Roquen - whoops Plus a whole load of other languages like Fortran, Algol, PL/1, ADA, COBOL, and so on. Kappa has it right: a universal bytecode is what the browsers should have been supporting all along, and JS should have been compiled into that on the fly and then executed. LLVM looks like it might be the panacea we are looking for as Java bytecode has so massively failed to win the hearts and minds of everyone thanks to Sun/Oracle mismanagement. Google lead the charge with PNaCl. I really do have overoptimistically high hopes for PNaCl. If it would just completely replace Javascript we'd all be winners.

Personally I'd rather see some high level language description (like an abstract sytax tree, or similar) as the transport mechanism which is lowered into LLVM (or similar) at compile time. SO many more things you can do (plus it's smaller).

the main thing "I think" that some java programmers might hate are some of the sugar related features like operator overloading (including get/set).

I realize I'm in a minority here, but don't lump me in with people who fear and hate operator overloading, and its lack is perhaps the single biggest wart the Java language has. Multiplication on vectors and matrices is multiplication, dammit, and I'm not going to have some hand-wringing dweeb tell me that the proper notation for it is just too powerful for me to be trusted with.

The problem was never that exactly... it was that any Tom Dick or Harry would choose any number of daft co-opted ASCII symbols to do all manner of daft things with all manner of daft objects and the result is... well, C++. You know how that looks.

If vecmath were built in intrinsically into Java (and honestly there's no real reason why complex numbers and tuples/matrices/vecmath couldn't be built in now) they could do some official operator overloading for it and thus solve 95% of everyone's issues over it (like they did with + and String). Let's face it complex numbers and tuples/matrices/vecmath are the only real use cases. Maybe. I'm not a maths nerd

interoperability is currently to difficult. Using language A as DSL for UI, language B for maths and java as system language all running on the same might be interesting but maintaining the interface in a polylingual project is currently a problem.

Doing this on-way is usually not that difficult, e.g generating accessors for OpenCL kernels with jocl or stuff like this. But having groovy, scala and java in the same project is horror.

And now, insiduously, Javascript is finding its way into many bizarre locations like serverside programming*. The same bloody language everywhere. There was a time we could choose what language we wanted to use to tell computers what to do. There were a whole plethora of choices, from machine code and assembler through BASIC, C, C++, Java, C#, Pascal, Oberon, Modula, Prolog, Lisp, Scala, Python, Ruby... and then suddenly, no, the only thing that is supported on the client will be Javascript.

There are compilers available for compiling C#, Java, BASIC, Prolog, Python, Ruby, PHP, Pascal to JavaScript. That is not including languages which only target JS, such as CoffeeScript, OMeta and my own Quby language.

If you leverage Silverlight, then you can even use all the .NET languages in the browser for scripting, with very little hassle. Even the dynamic ones, such as IronPython and IronRuby. You can also do similar with applets, but it typically require several megabytes of .jars, per-language (and all the problems with running applets, such as those freezes).

What is really nice about JS, is that for the most part, it's pretty damn easy to target. Simple things are a direct translation (like 'int i = 5+5' becomes 'var i = 5+5'), whilst high-level abstractions such as closures, generators, Ruby blocks, modules and classes are all trivial to fake.

There are also movements to make this easier, such as Google's recently leaked Dash/Dart project.

What is really nice about JS, is that for the most part, it's pretty damn easy to target. Simple things are a direct translation (like 'int i = 5+5' becomes 'var i = 5+5'), whilst high-level abstractions such as closures, generators, Ruby blocks, modules and classes are all trivial to fake.

Not true, unless you use the same 'generic' number type as JS in your source language. Otherwise for integer types you have to emulate it, sometimes it's just simple usage of AND operator, sometimes complete emulation (longs). Also JS lacks goto which complicates things for control structures as things are not directly convertible to JS control structures (eg. in case of converting from Java bytecode or other intermediate representation). Though there are labeled loops that can be used instead in most cases, but it's not as straightforward as goto.

The problem was never that exactly... it was that any Tom Dick or Harry would choose any number of daft co-opted ASCII symbols to do all manner of daft things with all manner of daft objects and the result is... well, C++. You know how that looks.

My problem with this kind of thinking is: they "already" can write awful code. Nothing you can do will prevent that. Properly used syntax sugar in the vein of operator overloading greatly improves readability and maintainablity. Without it the simplest of equations are near impossible to read. Besides with modern tools like Eclipse an overloaded operator could be decorated differently than the default and a simple cntrl-click takes you to the defining method. So in summary, you penalize everyone without really gaining anything and the "problems" of badly used are no where near as what it used to be (is that overloaded?? Where is it defined?? Arghh!!).

If vecmath were built in intrinsically into Java (and honestly there's no real reason why complex numbers and tuples/matrices/vecmath couldn't be built in now) they could do some official operator overloading for it and thus solve 95% of everyone's issues over it (like they did with + and String). Let's face it complex numbers and tuples/matrices/vecmath are the only real use cases. Maybe. I'm not a maths nerd

Just for game programming I'd have a much longer list. And the problem is that any given implemenation would only statisfy as small percentage of any potential users. Personally I think this would be a worse soultion than not support it at all. But I get annoyed everytime I see a String concat with the plus sign (and it's worse if I'm the one typing it).

Same thing. There's nothing wrong with gotos. There are code sequences (like interpretors and stream processing) which are greatly hindered by a lack of a goto statement. Keep in mind that break and continue are simply structured gotos.

I have no real problem with a high level language leaving out goto -- I guess even I have a "nanny state" attitude toward some language features. Heck, Scala doesn't even have break/continue in loops (but it has delimited continuations, so you could implement them pretty trivially).

The real problem is, javascript is increasingly being used as something it was never intended to be: a compiler target. The lack of an unconditional jump makes it a fairly awkward target, though that's hardly the only thing. Personally I'd rather see a more appropriate compiler target, along the lines of PNaCl, rather than trying to shoehorn everything into a hacked up high level language.

Same thing. There's nothing wrong with gotos. There are code sequences (like interpretors and stream processing) which are greatly hindered by a lack of a goto statement. Keep in mind that break and continue are simply structured gotos.

I never use labelled gotos, I avoid using "break" and "continue". These things are not a part of structured programming. Maybe you feel comfortable with them but they aren't necessary (it had been proven about thirty years ago).

Occasionally there are some time-saving things I'd like to do which just involving one set of source code referring to certain things with a consistent name. Or more usually it's when two identical classes have the same name and I end up having to fully.qualify.the.whole.name.all.over which looks hideous. Wouldn't it be nice to:

Same thing. There's nothing wrong with gotos. There are code sequences (like interpretors and stream processing) which are greatly hindered by a lack of a goto statement. Keep in mind that break and continue are simply structured gotos.

I never use labelled gotos, I avoid using "break" and "continue". These things are not a part of structured programming. Maybe you feel comfortable with them but they aren't necessary (it had been proven about thirty years ago).

They're part of my structured programming.. and they're really easy to understand. It's just how C style code looks. Or really we might as well be using Oberon or Modula or something.

Hey don't get me wrong, I was all for introducing operators to Java (Just using legal method names rather than crazy symbols. Eg. public static operator dot(a, b) ... a dot b kinda thing)

Stop! Stop! You're killing me! a dot b. Change that to a dot: b and you have Smalltalk. Seriously I don't think introducing a whole new sytatic style would be a good idea and IHMO the readablity isn't really improved.

I have no real problem with a high level language leaving out goto -- I guess even I have a "nanny state" attitude toward some language features.

Let me clarify. I'm not claiming that HL languages should include an unstructured goto statement. (Although very very handy for high performance state machine like processing) My issue is with the argument that it (or any other feature) should be excluded because some people would write bad code with it. That battle is lost the instance you decide to create a language. Stuff like: It's too marginal to be worthwhile, it complicates basic blocks and therefore the backend, it syntatically doesn't fit or even I don't want it. These are all reasonable arguments.

Maybe you feel comfortable with them but they aren't necessary (it had been proven about thirty years ago).

In 1936 Turing described the operations "required" for any computer algorithm to be able to run. A goto (or equivalent) is required. So, from Turing everything beyond a minimal set of ops which are Turing complete is unnecessary...and pretty much describes virtually all features of any high-level language.

I'd guess that you're refering to Edsger Dijkstra's paper from 1968 titled "Go To Statement Considered Harmful". The argument is against the excessive usage of goto's that was happening at the time and that programming languages needed move toward a structured style (a.k.a convert unstructured gotos into structured ones)

Not using unstructure gotos (when available) I can almost understand...attempting to avoid structured versions is crazy man, crazy!

In 1936 Turing described the operations "required" for any computer algorithm to be able to run. A goto (or equivalent) is required. So, from Turing everything beyond a minimal set of ops which are Turing complete is unnecessary...and pretty much describes virtually all features of any high-level language.

I'd guess that you're refering to Edsger Dijkstra's paper from 1968 titled "Go To Statement Considered Harmful". The argument is against the excessive usage of goto's that was happening at the time and that programming languages needed move toward a structured style (a.k.a convert unstructured gotos into structured ones)

Not using unstructure gotos (when available) I can almost understand...attempting to avoid structured versions is crazy man, crazy!

Yes I was refering to this paper. The use of labels, "break" and "continue" is forbidden in some kinds of programs, especially in safe softwares (softwares critical for human beings, used in airplanes, during operations in hospitals, etc...). Programs written without these things are easier to prove, they are closer to their mathematical equivalents, I can easily find the entry and the exit of the methods.

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