Why I prefer JavaScript to C++ and ActionScript when developing 3D code
Posted on:June 20 2012
I'm currently working on the next update for CopperCube. A lot of people are making games and interactive applications with it, so there are now quite a few useful feature requests for making even more stuff possible, and I'm implementing everything which I find makes sense. But I still try to keep the editor simple as it is, in order not to confuse new users. Here's a screen shot of one of the new upcoming features:
Carrying and handling animated weapons (or generally, all objects attached to the player) in the first person shooter mode will be much easier with the next update. Just drag the object to the camera, and most should work automatically. I hope to get the update out soon, but there is still a lot of work to do.
One thing I noticed is that I now tend to work on new features in WebGL mode first. I have Direct3D and OpenGL in C++, Stage3D in Actionscript and WebGL in JavaScript to choose from where I can write in code for CopperCube. And although I am a C++ person (woha, I am writing C++ code now for more than 13 years), I seem to prefer JavaScript because it is possible to make quick changes to the code, and see instantly how it works. I think it speeds up development time for certain features by a factor of at least 2. The problem with compiled languages also is that you have to wait for the sometimes slow compiler to finish, and sometimes, you get distracted during this time. (Honestly, who doesn't surf the web while waiting for the compiler?) :)
One reason obviously is that JavaScript doesn't need that long to compile (if it does at all), just hit F5 in the browser and you see your new code in action. With the powerful debuggers integrated in Chrome, Opera, Firefox and even InternetExplorer, finding bugs is a piece of cake now. The only drawback is the lack of static type checking, but for features as new and updated shaders, tweaks in existing animation code, optimizations of math routines etc, the JavaScript/WebGL combination has become my favourite now.
So if you like playing around with realtime 3D graphics and you never tried out WebGL, I can recommend to have a look at it. It's really fun.
Carrying and handling animated weapons (or generally, all objects attached to the player) in the first person shooter mode will be much easier with the next update. Just drag the object to the camera, and most should work automatically. I hope to get the update out soon, but there is still a lot of work to do.
One thing I noticed is that I now tend to work on new features in WebGL mode first. I have Direct3D and OpenGL in C++, Stage3D in Actionscript and WebGL in JavaScript to choose from where I can write in code for CopperCube. And although I am a C++ person (woha, I am writing C++ code now for more than 13 years), I seem to prefer JavaScript because it is possible to make quick changes to the code, and see instantly how it works. I think it speeds up development time for certain features by a factor of at least 2. The problem with compiled languages also is that you have to wait for the sometimes slow compiler to finish, and sometimes, you get distracted during this time. (Honestly, who doesn't surf the web while waiting for the compiler?) :)
One reason obviously is that JavaScript doesn't need that long to compile (if it does at all), just hit F5 in the browser and you see your new code in action. With the powerful debuggers integrated in Chrome, Opera, Firefox and even InternetExplorer, finding bugs is a piece of cake now. The only drawback is the lack of static type checking, but for features as new and updated shaders, tweaks in existing animation code, optimizations of math routines etc, the JavaScript/WebGL combination has become my favourite now.
So if you like playing around with realtime 3D graphics and you never tried out WebGL, I can recommend to have a look at it. It's really fun.
Comments:
new shaders?
bob9996
Quote2012-06-20 10:27:00
Completely agree in development cycle time being a pain in compiled languages compared to scripts, but type-safety and readability still tips the balance in the other direction for me. I wonder when they are going to come up with a fast typed scripting language. I've also read about blazing fast compilation for Go programs (Google's new language) but I don't know how well suited it is for games.
Luis
Quote2012-06-20 11:07:00
It might be more enjoyable to write code with an untyped language, but large programs built with untyped languages are a nightmare to debug. There is just no way to verify correctness reliably.
Wengfu Zhoudong
Quote2012-06-20 12:44:00
Luis: http://en.wikipedia.org/wiki/Qi_%28programming_language%29
Wengfu: There are no untyped languages in practical use.
As for verifying correctness, it's impractical to verify correctness for almost any non-trivial program, whether the language has a static type system or not. Static type systems make you *think* they verify correctness but in fact they don't. They are like spelling correction, good to have but unsuited for ensuring the correct meaning.
Wengfu: There are no untyped languages in practical use.
As for verifying correctness, it's impractical to verify correctness for almost any non-trivial program, whether the language has a static type system or not. Static type systems make you *think* they verify correctness but in fact they don't. They are like spelling correction, good to have but unsuited for ensuring the correct meaning.
Danny Milosavlje
Quote2012-06-20 15:10:00
Here's another vote for Go. I'm using it for most of my development tasks nowadays (mainly server software).
I'm not quite sure how good the OpenGL bindings are, but might be worth a try.
I'm not quite sure how good the OpenGL bindings are, but might be worth a try.
Sepp
Quote2012-06-20 16:29:00
if you were to use a lisp, you wouldnt even have to restart your program (or refresh, whatever) to see the results. :)
Matthias
Quote2012-06-20 16:48:00
Thanks for the peek at the upcoming weapons handling features, looking forward to the next iteration of CopperCube 3.
dreamcutter
Quote2012-06-21 05:13:00
regarding untyped languages: one might say that there really is no such thing as an untyped language, even JavaScript is not, but rather is dynamically typed. so yes, there are no untyped languages in practical use, because they are of no use.
without all that nitpicking: there are quite a lot dynamically typed languages in use, also for larger projects. code has a tendency to become write-once, never-touch-again, as for any modification ("I really do believe nobody uses this method anymore") there is no static help from a static type system. it really is tedious to make a program typed in a way so correctness can be proven (think about the type of "things smaller than my chosen pivot" in quicksort), it can still be helpful to have some compiler aid you, and in some way it is definitely more than spelling correction. (i particularly dislike the concept of duck typing, as something walking and quacking like a duck may still be some fool pretending, and will neither lay eggs nor taste good when roasted, and you will only find out about that when it's too late...)
without all that nitpicking: there are quite a lot dynamically typed languages in use, also for larger projects. code has a tendency to become write-once, never-touch-again, as for any modification ("I really do believe nobody uses this method anymore") there is no static help from a static type system. it really is tedious to make a program typed in a way so correctness can be proven (think about the type of "things smaller than my chosen pivot" in quicksort), it can still be helpful to have some compiler aid you, and in some way it is definitely more than spelling correction. (i particularly dislike the concept of duck typing, as something walking and quacking like a duck may still be some fool pretending, and will neither lay eggs nor taste good when roasted, and you will only find out about that when it's too late...)
xaos
Quote2012-06-22 10:29:00
C++ compiling is particularly bad, in regards to waiting time. One of the many reasons why I prefer Java and/or C# nowadays. The runtime speed difference doesn't really exist anymore, not unless you are a really hardcore C++ developer who is able to write really (I mean *REALLY*) performance-optimized code. And having a built-in RTTI/reflection system, a debugger that isn't flummoxed by multithreading, and can do proper stacktraces, do their thing, too. Really, for run-of-the-mill application development, I think C++ is a bit of a dinosaur nowadays.
Tazo
Quote2012-06-23 00:39:00
You will fall in love with Dart (google new programming language). AS fast as JS to prototype, static types, and the F5 thingie.
I like that way of programming (remenber me my old MSX BASIC days), but JS is an horrible language compared to Dart or Java (and those are horrible compared to OCAML,... :P)
I like that way of programming (remenber me my old MSX BASIC days), but JS is an horrible language compared to Dart or Java (and those are horrible compared to OCAML,... :P)
ASpanishGuy
Quote2012-06-23 15:23:00
Only Chrome will ever support Dart. No Apple and no Microsoft would support that in a million years. Which makes that programming language a stillbirth, tbh.
Tazo
Quote2012-06-25 17:15:00
Dart reminds me (VBScript IE),
JavaScript rocks, and soon it will be the language number one of programming opensource applications;
JavaScript rocks, and soon it will be the language number one of programming opensource applications;
Xakiru
Quote2012-06-26 13:38:00
Add comment:
|
|
Possible Codes
| Feature | Code |
| Link | [url] www.example.com [/url] |
| Bold | [b]bold text[/b] |
| Quote | [quote]quoted text[/quote] |
| Code | [code]source code[/code] |
Emoticons
 |  |  |  |  |  |  |  |
 |  |  |  |  |