From: Zoran V. <zv...@ar...> - 2006-09-20 07:23:46
|
On 20.09.2006, at 00:04, Andrew Piskorski wrote: > 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? Problem finding people and get them immediately (i.e. as soon as possible) productive when working on our product (based on NS). > >> 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. Well, if you have 10 contendents for the job and 10 of them know PHP and JS and NOBODY knows Tcl and you just spend 5K Euros for ads, you would think different... > > Zoran, if you have contrary experiences or intuition I'm interested in > hearing it, but Yes, Above... > 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.) It's just that we need new people and they need to be pretty quickly productive. We have no time to teach them all the things from ground up. Learning time for Tcl isn't that long but then you get average (or less) code from the newbies. It is much better a person is already fluent in some language you use. He has less new things to learn. > > 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. No customer. Our customers don't know (and don't care) what we use from tools to make the job done. As you are (mostly) not caring what type of clutch or pistons are in your car, as long as it drives. It is the potential collegues who need to continue (or perhaps take over) what we have done until now. I must prepare for this step. > > In other words, do you have some good reason to really use it > seriously at your own company? Yes. > Or are you being paid to provide this > tool to someone else who does? No. > 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. "wherever practical". Well JS will certainly bring nothing new or more "cool" to what we have now. But would allow easier adaption for a newbie. > > 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. Yes. This is exactly true. It would not add anything new. Rather, it would be, most probably, even less functional! It would however lower the acceptance barrier, as people would have _less_ to learn. But, rest assure... I will not dive into that this very moment! There are other (more important) things to do at this point of time. Still, some day or another, I will have to start working on that. BTW, I was thinking about PHP but I've abandon it because of the thread-safety issues (first) and ugliness (second) of the produced code. JS seemes like a good candidate for me. You know, even my girlfriend (she's doing some web-design in her spare time) started to learn JS. This gave me a hint... |