On Tue, Sep 19, 2006 at 07:05:18PM +0200, Zoran Vasiljevic wrote: > Don't worry. I will not start turning things arround for > integration of the JS into NaviServer. But I will have to > find a mid/long term solution for this.
Solution to what? What problem? > We are now a bunch of Tcl freaks (by "we" I mean people in my > company) and we have pretty much under control. > But if/when we get somebody new on the board, it is more than > certain that he/she knows either PHP or Javascript or both, > to a leeser extent the rest of the scripting languages with > Tcl being pretty much towards the tail of the list. > > In order to make this person immediately productive, a kind-of > "well-known" environment is from benefit. IMNSHO that's silly and probably asking for trouble. If your company HIRES someone that person is going to have to learn the programming languages that are standard and widespread in your company (e.g., Tcl), end of story. If the fact that this new hire "already knows" PHP or JavaScript is somehow important, you probably hired the wrong person. Zoran, if you have contrary experiences or intuition I'm interested in hearing it, but IMO, the only cases where it makes sense for a new hire at a small company to program in a new and different language, are the cases where YOU would have wanted to adopt that language anyway, but simply hadn't had the time or expertise to get around to it yet. (E.g., you believe that language X would be more appropriate for some new project, and lo and behold, the new guy happens to already be an X expert, let's stick him on the new project.) Adding JavaScript to NaviServer sounds like a fairly cool project, and would certainly make a nice hack for your own entertainment or edification. But, as a production worthy tool, I'd guess that sinking time into it is probably a mistake unless you have a clear customer for it. In other words, do you have some good reason to really use it seriously at your own company? Or are you being paid to provide this tool to someone else who does? If so, awesome! But if not, well, if I were in your shoes I'd skip it. Except, note, for the entertainment or self-education cases I mentioned above. (A cool hack is always a good thing, especially as there's always the small chance that someone else will pick it up and run with it.) Personally, my position to any new hire would be (and has been): If using some entirely different programming language or other tool will be particularly valuable in solving the problem, awesome, use it. (And I am curious about this language, teach me more about it please!) But if the new language does not have some special advantage in the problem domain over the languages we already use, then please stick to the ones we already use, wherever practical. That initial rule of thumb will then in practice leads to further derived guidelines, e.g.: No, where possible please don't write misc. utility scripts in Perl or Python, as that's the same problem domain served by Tcl, and we are already very heavy Tcl users. No, unless you have some other good reason, please don't write your misc. math and statistical code in Matlab, as we use R for that. Etc. There are of course many, many other application domains, programming paradigms, and good tools to serve them which I've never used before at all. (Perhaps including Erlang, Prolog, Mozart/Oz, Scheme, E, or even APL.) But unless I'm missing something, adding server-side JavaScript to NaviServer isn't really one of those, it's just a different flavor of the same NaviServer/Tcl stuff we've had all along. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
