Hi. > Threads are a debugging and maintenance nightmare. (...) > I recommend against using them for nearly all applications.
You can't resonably expect an app server talking to several databases simultaneously and serving up thousands of clients could do without threads. You also can't reasonably expect that your web app running on that app server could ignore these issues. However, I agree that you should be able to leave most of threads-related issues to a framework, and not do all nitty-gritty housekeeping yourself. I think, however, that a language/platform not providing access to the threading mechanism would be crippled. ASP.Net does try this, and I really dislike what you have to do there. >> performance/memory footprint is problem, I still have to see something like this. However, since there's no widely deployed server-side javascript-based solution around, we can't really know. Java and C#/.Net have very smart optimization mechanisms for app servers, which Javascript couldn't possibly have, due to lack of static typing and proper linking, for instance. I'm pretty sure, however, that once it's a problem, alternative optimizing approaches would evolve. > Type-safe is highly over-rated. You wish! Type safety stems from static typing, and static typing has nothing to do (well, maybe just a little) with mem allocation nowadays. It has to do with the compiler being able to detect heaps of errors way before you even thought about writing a unit test, and with the IDE being able to provide stuff like autocompletion. In large projects, it's a very useful feature. Tell me you never wanted to have proper intellisense in Javascript code. >> and there are no libraries. But there are contribs :) > My biggest problem with JavaScript as a language is its non-standard > prototype-based object model. How so? Javascript's prototype-based model is standard ECMA 626, and has reached version 3. Last time I looked, it was planned that version 4 will be skipped and version 5 will contain some static typing mechanisms, and other features to make it look more like a more traditional OO language. The fact that most OO languages out there use a class-based rather than a prototype-based approach to OO doesn't mean that a prototype-based approach is less worthy. > Personally I think that > javascript is so much used now only because there is no other choice. I don't think so. Especially nowadays flexibility of a language is becoming more and more important. Show me a single language more flexible than Javascript, without the obvious formatting drawbacks of python (no IDE can properly reformat python sources with scrambled indents, whereas Javascript doesn't suffer from this). IMO, once Javascript breaks the browser jail, and interpreters start properly implementing the new ECMA-262 v5 standard, or may be an even newer standard, which adds static typing and linking features to the language, Javascript will become a lot more usable, and will be increasingly used in larger projects. br, flj ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
