- JS is a single threaded language - threads are a debugging nightmare
True, so how does one cope with the implicit parallelism GUIs in general push into the users hand, the implicit parallelism a web server has to have by dealing with multiple connections, the implicit parallelism an MVC model with a middle layer (yes, I actually read that article and its predecessors) exposes? The world is parallel and programming languages/frameworks/systems are generally badly equipped to deal with parallelism in general.
It was a relief for me when I hit twisted many years ago, not because of it being a huge and complicated beast, but because of the most beautifully implemented concept of a deferred programming style which is the foundation of twisted.
For a short and sweet intro see http://krondo.com/blog/?p=1778 if you want to dig a little deeper http://twistedmatrix.com/documents/current/core/howto/defer.htmlAfter all I've done with using deferreds in programming for the last few years I can only say that I couldn't have done it with any other language/framework/system in existence.
So, for me it's not a matter of choosing the 'right' programming language/system/framework it's a matter of what concepts are implemented in those elements. And this is the promising part of node.js, that it was influenced by and carries such concepts perhaps a little further.
So, what am I missing from node.js?- clean Windows support (if one wants to live off writing software one cannot ignore Windows as deployment platform)
- way too complex addon writing (me having quite some code which can and will not be transported into other languages)
- much more clarity in expressing /forcing?) parallel concepts like deferred chaining, deferred action lists
- banning synchronous calls altogether - more protocol implementationsFor me it's observing node.js from the sidelines, but up till now it's not yet fit to take over from twisted/nevow
Werner On 02.08.2010 22:44, Petr Kobalíček wrote:
Hi Derrell, On Mon, Aug 2, 2010 at 9:28 PM, Derrell Lipman <[email protected] <mailto:[email protected]>> wrote: On Mon, Aug 2, 2010 at 14:58, Petr Kobalíček <[email protected] <mailto:[email protected]>> wrote: Hi, do you think that javascript is a good language to use it on server-side? For me it's worst language I ever worked with, but there is no other I can use to write multibrowser web-pages / web-apps. Different strokes for different folks. Having used many languages over the past 1/4 century, JavaScript is currently my favorite of any I've ever used. It's my opinion, not common truth. Javascript is singlethreaded language, Good. Threads are a debugging and maintenance nightmare. Been there, done that. I recommend against using them for nearly all applications. (They do have appropriate uses; I just feel they're way overused when it is inappropriate, and many developers who attempt to use them don't have the skill set to do so properly.) There are better mechanisms to use in most cases: heavy-weight processes if they're not fired up too frequently; an event loop (often a great solution); etc. I'm talking about the design of language. It's always good if you have choice than if you don't. It's more easier if language allows you to do things. performance/memory footprint is problem, Performance, possibly. With the latest JIT JavaScript interpreters, I'm not even sure if that's much of an issue any longer. Memory footprint is not an issue in anything but embedded systems (memory is practically free, and computers come with lots of it), and even in the embedded environment I'd have to do some experimenting to see whether the memory footprint really greatly exceeds (or exceeds to an untenable extent) the footprint of a compiled application. I understand x86/x64 assembler very much and I can say that no jit can generate code that is similar to C/C++ (the most efficient languages when it comes to performance). I have no problem with this, because C++ compiler spend much more time when compiling code to machine. My problem here is that Java or .NET compilers can create much better jit-code than javascript without extra cost - type information is known, class memory structure and members are known - there is not guess whether type is int, string or class, the compiler simply knows all types except type-casted objects. Currently javascript jit compilers are doing extra work to guess correct type, they are patching code, tracing code - the design of language seems to be more complicated than type-safe ones. Also javascript has no byte-code standardization, so it's nearly impossible to precompile some code and just import it by virtual-machine. There is also no language keyword to do it (because it was never designed to do so). it's not type-safe Type-safe is highly over-rated. Types were necessary in early compiled languages in order to tell the compiler how to allocate memory. Types do allow hints to be given to the developer when something bad is assigned, but I think the flexibility of, for example, storing numbers in some elements of an array and strings or even object references in other elements far outweigh the benefits of rigid types. Type-safety build into language itself has its benefits. Look at actionscript for example, you have choice to use static types or dynamic ones. The minor side effect is that when you add type-info to your code it should be more efficient and compiler can tell you basic mistakes. This is impossible with javascript. and there are no libraries. That will likely change soon. In the interim, as with PHP, C libraries can likely be linked in to provide external functionality. I understand this, but since there is no standardization in javascript how to do it and there are more interpreters you can use on the server there can be situation that your library has no bindings for you. With PHP/Python/Java you have usually luck or these tools are written in a language itself. Personally I can't understand why to use qooxdoo on server side, what you gain? Using oo model, My biggest problem with JavaScript as a language is its non-standard prototype-based object model. qooxdoo has pretty much fixed that, giving it a similar object model to other current and common languages. Question is, is problem solved in right place? Adding type-safety and standard class system into language will solve this problem for all code, not just your code. Qooxdoo is its own world, you can't rewrite all javascript code to use qooxdoo object model. Using dom or widgets, what is it good for? Nothing. They likely have nothing to do with server-side JavaScript programming. Some node.js users are using jquery for example, so I asked;) I respect your opinion, and I believe it's a fairly common opinion. I also see an evolution to a different (better, IMO) paradigm for many applications, and JavaScript on the server is part of that evolution. I respect your opinion too and I have no problem with that! I have some experiences in programming languages/compilers and I think that javascript is not goodly designed language for larger/complex projects. There are missing many things available in other languages. Personally I think that javascript is so much used now only because there is no other choice. I think that javascript on the server-side is good for educational/fan purposes, it's simply amazing how you can do with open-source (connecting various tools together), but for me it's not serious server technology. Derrell ------------------------------------------------------------------------------ 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] <mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ 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
<<attachment: werner.vcf>>
------------------------------------------------------------------------------ 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
