Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  Java vs. C#  (Read 8622 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #30 - Posted 2011-09-26 22:56:20 »

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.

Cas Smiley

Offline Cero
« Reply #31 - Posted 2011-09-26 23:20:39 »

I predict C# to end up like Visual Basic in the next 10 years.

Word!

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #32 - Posted 2011-09-26 23:49:48 »

But ${deity} help us if we're forced to use Javascript everywhere to do client programming.
This is currently my job.

The client is in:
javascript

The server is in:
javascript

All data is in:
JSON
 Emo

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #33 - Posted 2011-09-27 01:16:38 »

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.

弾幕 ☆ @mahonnaiseblog
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #34 - Posted 2011-09-27 10:53:42 »

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.

Cas Smiley

* I wonder how long before Javascript attempts to replace SQL? Hehe.

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #35 - Posted 2011-09-27 14:22:16 »

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
Offline Roquen
« Reply #36 - Posted 2011-09-27 14:26:02 »

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.

@princec - what? No love for Forth and Smalltalk..shame on you. 
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #37 - Posted 2011-09-27 14:32:27 »

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.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #38 - Posted 2011-09-27 14:37:18 »

@Roquen - whoops Smiley 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.

Cas Smiley

Offline Roquen
« Reply #39 - Posted 2011-09-27 15:14:02 »

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).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sproingie

JGO Kernel


Medals: 202



« Reply #40 - Posted 2011-09-27 15:33:14 »

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.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #41 - Posted 2011-09-27 16:00:22 »

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 Wink

Cas Smiley

Offline sproingie

JGO Kernel


Medals: 202



« Reply #42 - Posted 2011-09-27 16:14:55 »

The same arguments have been made against OOP and polymorphism in particular: "It looks like a function call, but you just don't know what it's actually doing!  Madness!"

Whatever.  This particular holy war has no end, so I'll just leave it where it is.  We have lots of language choices on the JVM alone, so it's not like we need a One True Syntax.
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #43 - Posted 2011-09-27 16:51:23 »

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.

Offline JL235

JGO Coder


Medals: 10



« Reply #44 - Posted 2011-09-27 20:30:17 »

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.

Offline jezek2
« Reply #45 - Posted 2011-09-28 06:54:12 »

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.
Offline Gudradain
« Reply #46 - Posted 2011-09-28 11:48:19 »

goto? are you talking about spaghetti code?
Offline Roquen
« Reply #47 - Posted 2011-09-28 13:03:38 »

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 Wink

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).

goto? are you talking about spaghetti code?

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.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #48 - Posted 2011-09-28 13:54:39 »

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

Cas Smiley

Offline sproingie

JGO Kernel


Medals: 202



« Reply #49 - Posted 2011-09-28 14:51:13 »

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.
Offline Chromanoid

Junior Member


Medals: 3



« Reply #50 - Posted 2011-09-28 21:57:06 »

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

Cas Smiley
static imports not enough?
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #51 - Posted 2011-09-28 22:11:18 »

Problem with static-imports if that you don't have infix-notation: dot(a, b) <-> a dot b, and that you don't have operator precendence.

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

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #52 - Posted 2011-09-28 22:24:52 »

It'd be a relatively simple language change I think. Still... hm.

On the subject of imports wouldn't it be nice to alias imports? I think C# has this feature. Some of the extremely daft classnames people choose in external libraries are a right fingerful to type.

Cas Smiley

Offline ra4king

JGO Kernel


Medals: 345
Projects: 3
Exp: 5 years


I'm the King!


« Reply #53 - Posted 2011-09-29 02:43:05 »

Imports? I haven't seen them since I discovered Ctrl+Shift+O on Eclipse :DDD

Offline gouessej
« Reply #54 - Posted 2011-09-29 09:58:16 »

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).

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #55 - Posted 2011-09-29 09:58:35 »

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:

import com.something.longwinded.Util as LWUtil;
import com.someothercompany.library.Util as SOUtil;

again, a trivial syntactic change that'd make my code look lovelier here and there.

Cas Smiley

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #56 - Posted 2011-09-29 09:59:32 »

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.

Cas Smiley

Offline cylab

JGO Ninja


Medals: 49



« Reply #57 - Posted 2011-09-29 12:45:48 »

Just yesterday I used a named outer loop and a break to save me an hour of thinking. It was a good day  Tongue

Mathias - I Know What [you] Did Last Summer!
Offline Roquen
« Reply #58 - Posted 2011-09-29 14:28:34 »

Hey don't get me wrong, I was all for introducing operators to Java Smiley (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.

I never use labelled gotos, I avoid using "break" and "continue". These things are not a part of structured programming.

That's just silly.  If this stems from someones advice...stop listening to them.  Note that 'if' blocks are also structured gotos (method calls, etc. etc.)

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!

Offline gouessej
« Reply #59 - Posted 2011-09-29 17:22:48 »

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.

Pages: 1 [2] 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (24 views)
2014-09-19 03:14:18

Dwinin (39 views)
2014-09-12 09:08:26

Norakomi (68 views)
2014-09-10 13:57:51

TehJavaDev (93 views)
2014-09-10 06:39:09

Tekkerue (47 views)
2014-09-09 02:24:56

mitcheeb (68 views)
2014-09-08 06:06:29

BurntPizza (51 views)
2014-09-07 01:13:42

Longarmx (38 views)
2014-09-07 01:12:14

Longarmx (44 views)
2014-09-07 01:11:22

Longarmx (40 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!