AS3 is compiled using the AS3 compiler while C/C++ is compiled using llvm-gcc which does more aggressive optimizations. Moreover, data twiddling over arrays is faster. You may want to check the link posted by the person above you for more information.
Our school uses a self-signed certificate for the courseware. We won't get freaked out because we're CS students (but it's really, really, REALLY annoying, especially if you access public terminals) but I bet the rest of the student population will.
The most ideal interface would probably be the one in IE7 but personally, I'll go for Opera... it's the least intrusive.
As for hobbyist systems, they (the site owners) usually tell their less-than-techy friends to access their sites which is installed with self-signed certificates... (can be due to various reasons from hosting a Trac+SVN server to HTTP authentication over SSL, etc) aside from waving your hand to get them to visit your site, you also have to play tech support for them to get past the esoteric error message.
As for unprofessional webhosters, they usually hand out shared certs to keep the cost down but of course, they also give you an option to get a personal cert... at a price... it's not very convenient for people living at other parts of the world (particularly in developing countries). You don't want (or do you?) to shut them out from online business opportunities just because all they can afford is a shared cert.
With HTML5, I think it would actually be a bigger programming headache if JavaScript didn't get a makeover anytime soon if it intends to "synergize" with HTML5. I don't want a "JavaScript Framework" implemented on top of the language just to implement rudimentary OOP concepts like inheritance and namespaces. Granted, the current implementation lends itself to a different programming paradigm (which is definityle not the traditional OOP we come to love and hate) but, as I see so far, no mere mortal has yet to uncover a proper paradigm exposed by Logos... I mean... the prototype classes of JavaScript.
Moreover, I believe that having a language makeover is a good way to "re-stabilize" the browser implementations: since the script languags is already a different monster the browsers might as well re-implement their front-end and because users/programmers are now more critical on the implementations as opposed to before, there's a good chance that the browsers would "get it right".
Actually, with templated type parameters (i.e. generics), the 'like' keyword for type constraints (which resembles C++0x concepts), the 'nullable' data types (which resembles the use of pointers in C to an extent) and function bindings, it's starting to look a lot like C++/0x.
If I'm not mistaken, ECMAScript 4 was partially implemented by AS3/Flex (actually, ECMAScript 3 + some features of 4). I've been programming on it for quite a while and I must say that I love it. It provides a near-perfect balance of static types (helpful for auto-completions) and dynamic types (useful for things like webservice invocation).
Now if they would only provide us with operator overloading... (it would make linear algebra oriented calculations simpler). But in any case, I'm already happy enough as it is with better datatyping and traditional classes. The prototype paradigm used in previous Javascript versions doesn't lend itself too well to traditional OOP approaches.
For the record, the Dalvik VM (Google's Java VM) is NOT JIT-ing: http://code.google.com/android/reference/glossary.html
The Dalvik VM is an interpreter-only virtual machine that executes files in the Dalvik Executable (.dex) format Trade-offs? Well, for starters, they don't recommend you to create objects: http://code.google.com/android/toolbox/performance.html
Wait, were're talking about Java here and most of Java programs pretty much abuse the GC. For starters, try to code the Extended GCD/Bezout-Lemma function, or any function which returns more than one trivial value, without allocating any objects at least on the heap. (honestly, this is a bad example, but just to illustrate my point).
Modern CPUs and memory sizes mean that the vast majority of apps can -- and probably should -- be written in interpreted languages.
Anyway, I think a Python API would be cool for phones. For the record, an average phone would have 200 to 400 MHZ and about 64 to 128 RAM (Discounting the slow flash memory). Developers are already thinking of ways to squeeze as much performance out of those devices and here comes an interpreter which hogs a part of the resources (not much, but still significant) and an application which sits on top of the interpreter which hogs MORE resources. Oh, and don't forget the battery too.
Python has its place and it's not for mobile phones IMHO.
But your statement does have validity though, one can look at Mercurial and say that it's faster than svn even though it's written in python. In this case, they made well use of the apis provided by the language (which uses C in the backend) and did the control statement-intensive parts in C (which is what you suggested). But I would like to point out that Mercurial doesn't have a GUI. What does this mean? It makes combining those two languages a LOT EASIER. You need to know the limits of your Python-frontend before porting a chunk of your was-python-frontend code to C/C++ and the syntax difference makes this very hard. However, it's not hard to imagine that someone will do a framework for ths in the long run.
Oh and for the record, studies show that garbage collection reduces performance by as much as 70% when the amount of memory is twice than needed: http://citeseer.ist.psu.edu/hertz05quantifying.html note that these conditions happen very often in embedded development.
I believe Google made a wrong choice using Java only as an API. Sure one can say that many mobile games are written in Java... but how about MANY applications running in Java at the same time? One app takes a long time to load and I can only shiver to think of the loading times of the phone. But I'll give them the benefit of the doubt because they're using their own JVM.
It's not the Havok physics engine itself that made HL2 stand above the rest. In fact, a dozen more companies license this ridiculously expensive engine. However, it is how they utilize the engine that made them stand out.
Many games limit the implementation of the physics engine to how the character will jump, how will the grenade fly, how will the particles of an explosion go and how will the car fly when an explosive is placed under it - of course there are more areas but they are generally limited. HL2 on the other hand, made things a little bit more realistic by implementing the physics engine on every object possible (the environment) and a little bit wackier by implementing a gravity gun.
Slashdot Mirror
So they want games to end like this?
So if you put a couple of those together with a couple of geeks in an enclosed space for a hack-a-thon.... I wonder how long they'll last.
AS3 is compiled using the AS3 compiler while C/C++ is compiled using llvm-gcc which does more aggressive optimizations. Moreover, data twiddling over arrays is faster. You may want to check the link posted by the person above you for more information.
You know what they say: everything could be solved by adding another layer of abstraction...
Oh and coffee too.
Will they also know if the guy just wanked?
Our school uses a self-signed certificate for the courseware. We won't get freaked out because we're CS students (but it's really, really, REALLY annoying, especially if you access public terminals) but I bet the rest of the student population will.
The most ideal interface would probably be the one in IE7 but personally, I'll go for Opera... it's the least intrusive.
As for hobbyist systems, they (the site owners) usually tell their less-than-techy friends to access their sites which is installed with self-signed certificates... (can be due to various reasons from hosting a Trac+SVN server to HTTP authentication over SSL, etc) aside from waving your hand to get them to visit your site, you also have to play tech support for them to get past the esoteric error message.
As for unprofessional webhosters, they usually hand out shared certs to keep the cost down but of course, they also give you an option to get a personal cert... at a price... it's not very convenient for people living at other parts of the world (particularly in developing countries). You don't want (or do you?) to shut them out from online business opportunities just because all they can afford is a shared cert.
With HTML5, I think it would actually be a bigger programming headache if JavaScript didn't get a makeover anytime soon if it intends to "synergize" with HTML5. I don't want a "JavaScript Framework" implemented on top of the language just to implement rudimentary OOP concepts like inheritance and namespaces. Granted, the current implementation lends itself to a different programming paradigm (which is definityle not the traditional OOP we come to love and hate) but, as I see so far, no mere mortal has yet to uncover a proper paradigm exposed by Logos... I mean... the prototype classes of JavaScript.
Moreover, I believe that having a language makeover is a good way to "re-stabilize" the browser implementations: since the script languags is already a different monster the browsers might as well re-implement their front-end and because users/programmers are now more critical on the implementations as opposed to before, there's a good chance that the browsers would "get it right".
Actually, with templated type parameters (i.e. generics), the 'like' keyword for type constraints (which resembles C++0x concepts), the 'nullable' data types (which resembles the use of pointers in C to an extent) and function bindings, it's starting to look a lot like C++/0x.
If I'm not mistaken, ECMAScript 4 was partially implemented by AS3/Flex (actually, ECMAScript 3 + some features of 4). I've been programming on it for quite a while and I must say that I love it. It provides a near-perfect balance of static types (helpful for auto-completions) and dynamic types (useful for things like webservice invocation).
Now if they would only provide us with operator overloading... (it would make linear algebra oriented calculations simpler). But in any case, I'm already happy enough as it is with better datatyping and traditional classes. The prototype paradigm used in previous Javascript versions doesn't lend itself too well to traditional OOP approaches.
She could be charged with felony then...
It's not the Havok physics engine itself that made HL2 stand above the rest. In fact, a dozen more companies license this ridiculously expensive engine. However, it is how they utilize the engine that made them stand out. Many games limit the implementation of the physics engine to how the character will jump, how will the grenade fly, how will the particles of an explosion go and how will the car fly when an explosive is placed under it - of course there are more areas but they are generally limited. HL2 on the other hand, made things a little bit more realistic by implementing the physics engine on every object possible (the environment) and a little bit wackier by implementing a gravity gun.
THAT is precisely why M$ came up with Avalon.