next »

[Chromanoid]

What is it with Google and bloody Java? They seem to have this one-size-fits-all obsession with it, assuming that everyone is desperate to program in Java and that it's waaaaaay more fun than, oh, say, all other fucking languages.

Not least of all that Javascript, AS3 and Java have completely different optimisation bottlenecks. They are not the fucking same!

Also - I'm pretty sure I saw that lady on the Google Wave team.

Java is a nice language with a small basic set of language features. Many developers can "speak" Java and Java is widely used for server programming. Writing server and client in the same language is very nice especially when developing RIAs. Google comes from the Server world and this is how they enable server developers to easily visit the (RIA) frontend world. I don't see much difference between AS3, JavaScript and Java beside the VM. Google Wave was an ambitious interesting RIA software project - so I think it is a good thing to have her on the PlayN board.

I think Rovio's Angry Birds for Chrome Webstore is made with PlayN. Also see http://www.google.com/events/io/2011/sessions/kick-ass-game-programming-with-google-web-toolkit.html

GWT and PlayN are not the same. My guess is that PlayN is the bastard offspring of GWT looking for wider adoption.

That may be true. However they market PlayN as tool that was used for Chrome Angry Birds: http://lanyrd.com/2011/html5devconf/shxhg/

[_Tommo_]

Did you try Adobe Alchemy for Flash?

I didn't, but maybe Epic Games did try pretty well  
I thought it was some special integration they used, instead is this Alchemy or some future versions of it. Thanks for the link  

[dustin]

It seems kinda like HaXe but i'd have to program in java instead of a ECMA script style language and it can't export to as many places 

[st33d]

I don't see much difference between AS3, JavaScript and Java beside the VM.

I've programmed in all three. For a number of years.

No offence, but I'm getting the feeling you haven't.

[Nix]

interesting

also, what's with Google's love affair with Java

[Chromanoid]

I don't see much difference between AS3, JavaScript and Java beside the VM.

I've programmed in all three. For a number of years.No offence, but I'm getting the feeling you haven't.

I work as a Java programmer and did some contract work in javascript and as3... Maybe I am wrong, but then it would be nice if you could point me to some severe differences that lead to different optimization bottlenecks that are inherent to each language. The only big things I can imagine are the weak type system and prototype-based programming of javascript. I don't see language-wise anything that can be done in Java and not be done in AS3 or javascript in a similar way.
The Java language (and the resulting java vm) is a good common denominator for garbage-collected languages.

[st33d]

Well, let's list some of the differences:

Scope is completely different in Javascript.

Classes don't exist in Javascript, and many insist they shouldn't. You can actually write a classless AS3 program because Javascript is still there under the hood. Most people simply don't realise it.

Objects are dynamic in ECMAScript, as well as Functions. The notion that ECMAScript shouldn't be dynamic is a Java-ism. It's actually the language's most powerful feature.

In Javascript we have the null/undefined issue, in AS3 we don't - but undefined is still there. Java only has null.

Javascript Numbers also optimise differently to Java and AS3.

The Collections object in Java is slow. It's actually faster to sort writing your own algorithm. In AS3 there is no faster method of sorting than Array.sort.

In Java, static methods and variables are faster than those in objects. In AS3, making a variable/function a static member of a class actually makes it slower to access.

Java has access to hardware, ECMAScript languages are strictly sandboxed from hardware.

The last I checked, there is no standard method across browsers of accessing the middle mouse button or detecting multiple mouse buttons being pressed, yet these are available in Java and AS3.

Java's float and double operate at different speeds, ECMAScript only has doubles, thus numerical operations are always slower (except in AS3 which supports ints, but uints strangely are even slower than doubles). Processing was built on using floats instead of doubles, making it faster to draw in than standard Java.

Java, AS3 and Javascript have different floating point rounding errors.

Arrays in Javascript and AS3 are descended from Object, making them dynamic. The closest analogue Java has is ArrayLists, which are more like Vectors in AS3 and still have to be cast when being extracted.

Error handling is of course different in all of the languages.

and so on...


But for some perspective, I write a lot of optimisation heavy code. I recently had users submit levels for one of my games and I was amazed to find that the levels had thousands of objects with ludicrous amounts of action and still no slow down.

If you target a platform specifically, you get gold standard results.

I just don't see the point in writing code that can't be optimised on the three platforms where optimisation is crucial.

Why not just write in C++ instead and target multiple platforms that way.

[eclectocrat]

Isn't Javascript + HTML 5 theoretically much more portable because vendors don't lock it out of their platforms? Does Windows Phone 7 have a native API yet? Sigh. C++ used to be so much more portable...

[Klaim]

I prefer C++ for cross-platform because I don't want to embedd a game in a browser. I always fnid the browser context breaking the immersion.

[Chromanoid]

@st33d: Aren't all those things either irrelevant for optimization, part of the library that comes with the language or consequences of the underlying VM?
And this is where GWT's deferred binding comes into play. It gives you a way to abstract away lowlevel issues and platform differences.

[Klaim]

@st33d: Aren't all those things either irrelevant for optimization, part of the library that comes with the language or consequences of the underlying VM?
And this is where GWT's deferred binding comes into play. It gives you a way to abstract away lowlevel issues and platform differences.

As a standard library is part of the language, AND some of the issues are language issues, not only implementation issues, I would say those are real important differences.

[Chromanoid]

Mmh ok, point taken. However still I think the differences are managable by endavours like HaXe or GWT/PlayN.

[Nix]

Isn't Javascript + HTML 5 theoretically much more portable because vendors don't lock it out of their platforms? Does Windows Phone 7 have a native API yet? Sigh. C++ used to be so much more portable...

The problem is that without a consistent client/run-time, the same code may not run properly on all platforms. At least the Flash Player is the same thing, more or less, on Linux, Windows, and Mac. The same can't be said about the performance and behavior of Safari, Firefox, Chrome, IE, etc (not to mention all the different versions of these browsers).

[Chromanoid]

Isn't Javascript + HTML 5 theoretically much more portable because vendors don't lock it out of their platforms? Does Windows Phone 7 have a native API yet? Sigh. C++ used to be so much more portable...

The problem is that without a consistent client/run-time, the same code may not run properly on all platforms. At least the Flash Player is the same thing, more or less, on Linux, Windows, and Mac. The same can't be said about the performance and behavior of Safari, Firefox, Chrome, IE, etc (not to mention all the different versions of these browsers).

Don't you have the same problems with different devices when programming with C++/OpenGL?

[Nix]

Isn't Javascript + HTML 5 theoretically much more portable because vendors don't lock it out of their platforms? Does Windows Phone 7 have a native API yet? Sigh. C++ used to be so much more portable...

The problem is that without a consistent client/run-time, the same code may not run properly on all platforms. At least the Flash Player is the same thing, more or less, on Linux, Windows, and Mac. The same can't be said about the performance and behavior of Safari, Firefox, Chrome, IE, etc (not to mention all the different versions of these browsers).

Don't you have the same problems with different devices when programming with C++/OpenGL?

Oh yeah. I didn't really read what I was responding to. I was thinking in comparison to Flash or similar platforms.

[Klaim]

Don't you have the same problems with different devices when programming with C++/OpenGL?

It's a bit different : you know that the behaviour will be the same, if it runs on the different targets (meaning not if the target hardware are too differents and the code don't manage thos differences). The main differences between the same C++ code operating on several different targets will be about performance "scale", not language behaviour. Maybe memory access will be a problem on a platform but that will be ovious by profiling or other ways. Compare that by the required knowledge when you have different languages : the platform AND the language can be both sources of problems.

[Chromanoid]

Yeah, I was talking about JavaScript+HTML5 vs C++ or Flash vs C++ on different devices. "Language to language to platform" compilation adds definetly a big layer of complexity. This is why it has to be well made to hide the complexity... At least GWT/Java to javascript works well enough that big companies are using it.
GWT development is IMO really comfortable. Integrating special javascript stuff is pretty easy. I once worked on a chrome addon with GWT, it was really a nice experience.

[Chromanoid]

I am curious about Google's new programming language DART. Since it is a bit like GWT programming in DART for PlayN may be possible in the future...

[st33d]

Yeeeah.

There was an article on Reddit with this guy picking apart Dart...

I would have thought that GWT would have been a better solution as opposed to making a version of Javascript that Javascript programmers will hate.

[Richard Kain]

I'm sticking with HaXe. Despite some of the limitations, I have my haxe applications compiling and running on darn near everything. And what few limitations I have run across are usually more related to SDL.