Menu
▾
▴
naviserver-devel
|
From: Zoran V. <zv...@ar...> - 2006-09-17 17:37:47
|
Hi ! Following a recent discussion on the sister-project, I just wanted to check what would you think about integrating javascript as an alternate language to Tcl ? I'm long time user of Tcl (over 12 years) and I still preffer it to any other scripting language, buI I see that most of the younger people are actually already fluent in javascript whereas they are not fluent in (mostly even do not know about) Tcl. This is at the moment not an issue for us but it may be one in the future.... I do not know what would need to be done and to what extent a "foreign" language could/should be integrated in the server; I just wanted to hear what people would think about this. Cheers, Zoran |
|
From: Vlad S. <vl...@cr...> - 2006-09-17 18:12:30
|
Creating it as a module similar to php is possible, pretty easy, but integrating into the core may not be without re-designing it. May be creating virtual interpreter in the core and then have different plugins for real languages but this is a lot of work. Zoran Vasiljevic wrote: > Hi ! > > Following a recent discussion on the sister-project, I just wanted > to check what would you think about integrating javascript as an > alternate language to Tcl ? > > I'm long time user of Tcl (over 12 years) and I still preffer it > to any other scripting language, buI I see that most of the > younger people are actually already fluent in javascript > whereas they are not fluent in (mostly even do not know about) Tcl. > > This is at the moment not an issue for us but it may be one in the > future.... > > I do not know what would need to be done and to what extent a > "foreign" language could/should be integrated in the server; > I just wanted to hear what people would think about this. > > Cheers, > Zoran > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Mike <nee...@gm...> - 2006-09-17 18:44:26
|
On 9/17/06, Zoran Vasiljevic <zv...@ar...> wrote: > Following a recent discussion on the sister-project, I just wanted > to check what would you think about integrating javascript as an > alternate language to Tcl ? > > I'm long time user of Tcl (over 12 years) and I still preffer it > to any other scripting language, buI I see that most of the > younger people are actually already fluent in javascript > whereas they are not fluent in (mostly even do not know about) Tcl. > > This is at the moment not an issue for us but it may be one in the > future.... > > I do not know what would need to be done and to what extent a > "foreign" language could/should be integrated in the server; > I just wanted to hear what people would think about this. Vote: -1 Explanation: waste of time Of the vast sea of scripting languages out there, I am most fluent in Tcl and Javascript. I consider both very good languages (with Tcl having a slight edge). If NaviServer's underlying language was JavaScript - I wouldn't complain. But it isn't. It's Tcl. In the end, a programming language is just a tool. Unless it's absolutely horrendous (e.g. php or csh) there's no real reason to switch other than a time-consuming exercise. Adding more language bindings is just going add complexity and require more maintenance, take developer time, and have very few benefits. If someone is serious about using a tool, they will learn the language - and Tcl is not a bad language to learn. That's purely language-specific. Now, for the Javascript technical part. Tcl is deeply rooted in NaviServer code - trying to stick another language's interface in is just not going to be an easy task. Furthermore, there is no "one good and supported" Javascript interpreter. Most of them have problems - the the "more maintained" ones having more problems and bloat than the less maintained ones (double-edged sword). If you really insist on going down this path, my recommendation would be to look at the Tcl binding that was created for BrowseX... Alas, that interpreter falls into the "less maintained" category. |
|
From: Zoran V. <zv...@ar...> - 2006-09-19 17:05:25
|
On 17.09.2006, at 20:44, Mike wrote: > Vote: -1 > Explanation: waste of time Allirght. Although I would not strictly categorize this as waste of time... 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. 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. Cheers Zoran |
|
From: Andrew P. <at...@pi...> - 2006-09-19 22:04:37
|
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 <at...@pi...> http://www.piskorski.com/ |
|
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... |
|
From: Andrew P. <at...@pi...> - 2006-09-20 10:17:04
|
On Wed, Sep 20, 2006 at 09:23:35AM +0200, Zoran Vasiljevic wrote: > 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... Why is that a problem? Are candidates losing interest in your company because of some sort of stigma associated with Tcl? If so that could be bad, but it doesn't sound like that's the problem. Zoran, since you've been a Tcl expert for so long, maybe you've forgotten that learning Tcl is EASY? It is, you know, at least for anybody good. (Or at least, I've both heard and seen many examples and claims supporting that assertion, and have neither seen nor heard of even a single contrary example or claim.) Yes, I'm basically just repeating an old Greenspun mantra here, but I'm repeating it because AFAICT it's true. [scratches head] Really, back when I did the three week ArsDigita Boot Camp in early 2000, I saw some people whom I DIDN'T consider sharp enough to hire as programmers pick up Tcl quickly, including at least one person who didn't have even a glimmer of programming experience at all, zip zero nada, (and in fact little computer experience period, didn't even know to type "ls" at the Unix shell prompt...) And Tcl definitely does have a real advantage in ease and speed of learning AFAICT. E.g., I also like the R programaming langauge a lot (despite some ugly corners), and R is also a high level, dynamic, rapid development language, but it took me quite a lot longer to come up to speed with R than it did with Tcl, and I'd had MUCH more programming experience by that time... Now, learning AOLserver and all your in-house APIs is probably much more work than learning Tcl, but, any new hire is going to be starting from scratch there anyway. Seriously, just how much extra time is learning Tcl going to add to the time it takes for a JavaScript wizard to become productive at your company? Maybe a week, three at the very most? Why is that a real problem? Hell, you Europeans take lots more vacation time than that every single year. ;) How long does your average programmer stay with your comany, years? If so, and if you truly believe that your mostly Tcl environment is highly productive for you, then you will easily recover that lost 1-3 weeks in increased productivity later on, no problem. > 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 It may sound trite, but then my advice is: Do your very best to hire only people you KNOW have a proven history of being highly productive, learning fast, and being self starting. (If you're company is small, then that might be feasible simply through personal contacts. But I guess not in your case.) > 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. That's nice when it happens, but I think it's highly overrated. What you typically want in a general programming hire is not so much someone who has less to learn, as someone who habitually learns many new things quickly. -- Andrew Piskorski <at...@pi...> http://www.piskorski.com/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 11:32:28
|
On 20.09.2006, at 12:17, Andrew Piskorski wrote: > On Wed, Sep 20, 2006 at 09:23:35AM +0200, Zoran Vasiljevic wrote: >> 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... > > Why is that a problem? Are candidates losing interest in your company > because of some sort of stigma associated with Tcl? If so that could > be bad, but it doesn't sound like that's the problem. Candidates have mostly no problem with that. It is us. > > Zoran, since you've been a Tcl expert for so long, maybe you've > forgotten that learning Tcl is EASY? It is, you know, at least for > anybody good. (Or at least, I've both heard and seen many examples > and claims supporting that assertion, and have neither seen nor heard > of even a single contrary example or claim.) > Hm... easy... It is much better having somebody good in a tool and then you get good results. If you have to learn the tool then you're not fast in producing good results. You have a "experience-gathering-curve" which can be quite long(er). We need production-quality code and if you are new in something, then what you produce is mostly not comparable to somebody who is mastering the tool. But you know all this... > > Now, learning AOLserver and all your in-house APIs is probably much > more work than learning Tcl, but, any new hire is going to be starting > from scratch there anyway. Seriously, just how much extra time is > learning Tcl going to add to the time it takes for a JavaScript wizard > to become productive at your company? Maybe a week, three at the very > most? Why is that a real problem? Oh no... I'm speaking about a year to two-year=B4s time. Because this is IMHO what you need to feel fully comfortable with the tool and have hit all the "walls" you are supposed to hit. > > Hell, you Europeans take lots more vacation time than that every > single year. ;) > Perhaps, but you can't generalize :-) Last time I took vacation (that is, more that 3 working days off) was about 7 years ago :-/ > How long does your average programmer stay with your comany, years? > If so, and if you truly believe that your mostly Tcl environment is > highly productive for you, then you will easily recover that lost 1-3 > weeks in increased productivity later on, no problem. I cant say. All guys that started 7 years ago are still here. =46rom the previous company, it was about 3-5 years on average. But it is really not 1-3 weeks. It is rather 1-2 years. > >> 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 > > It may sound trite, but then my advice is: Do your very best to hire > only people you KNOW have a proven history of being highly productive, > learning fast, and being self starting. (If you're company is small, > then that might be feasible simply through personal contacts. But I > guess not in your case.) It is difficult to find people. It is very difficult to find good people. If we had the chance to get to know "only people who have a proven history of being highly productive learning fast, and being self starting" we'd employ them ASAP. Yesterday. But we must take what we get. And that what we get are mostly Java, PHP and Javascript'ers. > > That's nice when it happens, but I think it's highly overrated. What > you typically want in a general programming hire is not so much > someone who has less to learn, as someone who habitually learns many > new things quickly. Hm... there is some truth in that, I admit. As said, to learn and understand something is one thing. To be _productive_ is another. For example: riding a bicycle can be learned fast (is the matter of hour or two). But to be the bicycle professional, you need years. |
|
From: Gustaf N. <ne...@wu...> - 2006-09-20 11:37:04
|
>> 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. >> > > That's nice when it happens, but I think it's highly overrated. What > you typically want in a general programming hire is not so much > someone who has less to learn, as someone who habitually learns many > new things quickly. > While I fully agree with Andrew (hey, you are doing as well some R-programming!), I understand Zoran's situation as well. We have hired in the last half year 5 people with the skill set Tcl+aolserver+OpenACS/.LRN+XOTcl. But maybe it was easier for us, since due the the later mentioned constraints of the skill set, we did not really expect to hire someone who is ready to be productive from the first day. In other respects it is harder for us, since as a government institution we are not able to pay competitive salaries. For these positions, we had about 70 applications. I am somewhat happy that we did not mention JavaScript or PHP in our ads. We had a large group of applicants writing "programming skills in PHP, HTML and XML" or the like. From such sentences it is pretty easy to deduce what to expect (... "i have programmed my homepage." ..). There are many people out there with a very shallow idea of what programming is, and not really willing to involve themselves deeply with unknown problems. This are exactly the people, i do not want to hire. I expect from people primarily that they are willing to learn, willing to develop himself. Then, they should know a couple of languages (a few script languages, C, Java) and understand to use the right language for the right job. And, they should have programmed a significant piece of code by themselves and in a team. Many JavaScript users use JavaScript in a very shallow way. In my experience people with profound JavaScript knowledge are as rare as Tcl people. What puzzles me somewhat is the question, for what purposes one would like JavaScript in the aolserver. Using it for traditional scripting is fine (the real issues are here not programming but browser semantics for cross browser functionality). For "real programming" issues, hmm.... Ask applicants about the object model of JavaScript. I have done lately some JavaScript programming for web2-style applications (e.g. JavaScript based chat without polling). This was the first time when i really wished that the Netscape people should have chosen Tcl instead of JavaScript as a scripting language. JavaScript has no io and relies on the io semantics of the browser. Getting simple things like asynchronous io working cross-browser was and is a challenge. How easy would that be based on Tcl (or Perl, etc.)! One might argue that this is no the fault of JavaScript, since it is not part of the language. But it is part of e.g. Tcl. So, if one wants to write real applications, one has to leave the language and roll the own interfaces, etc. This should be done by people, knowing only JavaScript? In the mentioned project, i had as well situations, where the same pure JavaScript-code lead to different results on two different JavaScript implementations (length of the list differed by 1). Other issues (unknown to me) are: c-language interfaces (Tcl is here hard to beat), thread-safety, character encodings, introspection, code-reusability (having the need to program some stuff twice, once in Tcl, once in js), maintenance costs, libraries.... just my 2 cents... -gustaf neumann |
|
From: Zoran V. <zv...@ar...> - 2006-09-20 12:12:21
|
On 20.09.2006, at 13:36, Gustaf Neumann wrote: > > just my 2 cents... Very valuable insights from (obvious) experience ... Look at for example our case... We have 3 people VERY good at C and "low-level" programming (including kernel-level drivers). We have one guy pretty experienced in Web GUI development. We need to have at least one or two more in that area. So, basically, good knowledge of HTML, XML and CSS are absolute prerequisites. But, we need to create server-side pages. That is, you need to add the Tcl, as there is nothing in Naviserver that you can use instead. Mostly, people having written some "home-page"-kind of apps (if you can call this application at all) HAVE some experience in Javascript. Because more and more functionality will be done in JS (client-side) you need to have those people learn JS pretty good and this is what they will do. Now, why not piggybacking on that and give them the tools to employ their knowledge on the server-side as well? They need not write async code nor concurrent MT-code. For that we have libraries either in Tcl or (mostly) in C written by a. people (see below). In the near future, most of the Web-applications will be even more (heavily) based on JS then they are now. So people will invest more and more in that area. Why not take advantage of that? I believe one thing that we've isolated so far is: a. To write serves-side code (libraries, complex logic, etc) we will mostly stay with Tcl and C as I know this is unbeatable combination. Years and years of experience have thought me so. b. To write dynamic HTML pages to produce a client-based "application" will (always) be the case of mixing HTML/CSS/JS hence by using JS both server and client side simplifies the task of the programmer. He/she, after all, has already enough to do in order to mix JS with HTML/CSS. Adding something else (Tcl, PHP, whatever) was out of the necessity (historical reasons) and not out of the design reasons. To find people doing a. is very hard. But when you find them, then the language question is secondary. They already have enough experience to learn and be productive quickly given XYZ tool. This is NOT the audience I'm talking about. To find people doing b. is simpler. But as they do NOT have that extensive programming background, you can't expect from them to learn 4 different languages (HTML/CSS/JS/TCL) to write a web-based application. Even HTML/CSS/JS is pretty enough for them. By having the server-side pendant of JS just simplifies things for b. people. So, it is the b. I'm talking about. I'd like to make the burden of working with NS lower by adding alternative language to compose dynamic pages. |
|
From: Stephen D. <sd...@gm...> - 2006-09-18 17:58:25
|
On 9/17/06, Zoran Vasiljevic <zv...@ar...> wrote: > Hi ! > > Following a recent discussion on the sister-project, I just wanted > to check what would you think about integrating javascript as an > alternate language to Tcl ? > > I'm long time user of Tcl (over 12 years) and I still preffer it > to any other scripting language, buI I see that most of the > younger people are actually already fluent in javascript > whereas they are not fluent in (mostly even do not know about) Tcl. > > This is at the moment not an issue for us but it may be one in the > future.... > > I do not know what would need to be done and to what extent a > "foreign" language could/should be integrated in the server; > I just wanted to hear what people would think about this. > Are you running a fever? |
|
From: Zoran V. <zv...@ar...> - 2006-09-18 20:31:58
|
On 18.09.2006, at 19:58, Stephen Deasey wrote: > > > Are you running a fever? Ah no! I'm just trying to see what others think. Well, all responses so far were not exactly in favour of that but that doesn't matter. I'm not going to start working on that in short nor in mid term. But, this MIGHT ease newbie acceptance, don't you think? After all, Netscape did that already some years ago.... So it is not just out of the blue... |
|
From: Stephen D. <sd...@gm...> - 2006-09-18 20:59:45
|
On 9/18/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> On 18.09.2006, at 19:58, Stephen Deasey wrote:
>
> >
> >
> > Are you running a fever?
>
> Ah no! I'm just trying to see what others think.
> Well, all responses so far were not exactly
> in favour of that but that doesn't matter.
> I'm not going to start working on that in short
> nor in mid term. But, this MIGHT ease newbie
> acceptance, don't you think?
> After all, Netscape did that already some years
> ago.... So it is not just out of the blue...
>
Yeah, and how popular are the Netscape servers?
Tcl sucks, that's for sure. But it rules in these three very important areas:
* It's thread safe (and thread friendly)
* It's utf-8 safe
* You can write domain specific languages in it.
I think it's the last point which makes up for the suckage, and which
is also the main selling point of Ruby. When you wite a Rails
application, what you end up with *looks* like it does what it does --
a python program always seem to look like just another python program.
People are writing a lot of sucky Tcl for AOLserver. Here's an
example from a couple of days ago:
proc startworker {name} {
nsv_set $name mutex [ns_mutex create]
nsv_set $name cond [ns_cond create]
nsv_set $name queue {}
nsv_set $name tid [ns_thread begindetached [list workermain $name]]
}
Jumping through hoops with low level mutexes and and variables etc.,
you see it all the time. Why can't we have code that looks like this?
ns_serialize {
# Only one copy of this code runs at a time
}
Which brings us back to nsproxy and handle management... :-)
|
|
From: Zoran V. <zv...@ar...> - 2006-09-18 21:12:19
|
On 18.09.2006, at 22:59, Stephen Deasey wrote: > > Yeah, and how popular are the Netscape servers? Well, not much, but this is not because of the JS as we all know. > > Tcl sucks, that's for sure. But it rules in these three very > important areas: > > * It's thread safe (and thread friendly) > * It's utf-8 safe > * You can write domain specific languages in it. I find Tcl actually very nice. Admitently, it could be facelifted to allow OO programming, as this helps a lot in some types of applications (we use XOTcl for that). But lets stop at this point, as we do not want to start yet another language-flame. Our sister-project is responsible for that kind of flames :-) |
|
From: Vlad S. <vl...@cr...> - 2006-09-18 21:06:19
|
>
> People are writing a lot of sucky Tcl for AOLserver. Here's an
> example from a couple of days ago:
>
>
> proc startworker {name} {
> nsv_set $name mutex [ns_mutex create]
> nsv_set $name cond [ns_cond create]
> nsv_set $name queue {}
> nsv_set $name tid [ns_thread begindetached [list workermain $name]]
> }
>
> Jumping through hoops with low level mutexes and and variables etc.,
> you see it all the time. Why can't we have code that looks like this?
>
> ns_serialize {
> # Only one copy of this code runs at a time
> }
>
>
> Which brings us back to nsproxy and handle management... :-)
You just showed that it is not Tcl sucks but a programmer that writes
bad code in Tcl without using it properly or not in full. That example
of your shows that programmer that wrote it has more experience in C and
uses Tcl in pure procedure way, which is not that bad, the code works.
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Zoran V. <zv...@ar...> - 2006-09-27 14:38:25
|
On 17.09.2006, at 19:37, Zoran Vasiljevic wrote: > I just wanted to hear what people would think about this. The response(s) so far were almost unisono: NO. Summary (rough): We like Tcl and we are happy with C/Tcl server as-is now. There is no need for any alternative page-construction language (PHP, JS, whatever) because what we have is good (enough) and its fairly easy to learn Tcl anyway, so why bother with anyhing else? It is good to know where are we when thinking about evolvement of the server code for the next few years. As the documentation effort (Vlad, Bernd, you are champs!) is materializing, we will soon be able to release our long awaited 5.0 release, as planned some time ago. This is the time to start to think about all the cool things we always wanted to do but never had time for or were afraid to ask :-) What I wanted to do before 5.0 is to integrate the ns_proxy with ns_job (and junk the former). If there are any special wishes (which we can slip into before the 5.0) please use RFE section at SF. Cheers zoran |
|
From: Vlad S. <vl...@cr...> - 2006-09-27 14:48:33
|
It would be good to have documentation ready for the 5.0 release, at least all commands needs to be somewhat documented. Zoran Vasiljevic wrote: > On 17.09.2006, at 19:37, Zoran Vasiljevic wrote: > >> I just wanted to hear what people would think about this. > > The response(s) so far were almost unisono: NO. > Summary (rough): We like Tcl and we are happy with > C/Tcl server as-is now. There is no need for any > alternative page-construction language (PHP, JS, > whatever) because what we have is good (enough) > and its fairly easy to learn Tcl anyway, so why > bother with anyhing else? > > It is good to know where are we when thinking about > evolvement of the server code for the next few years. > > As the documentation effort (Vlad, Bernd, you are champs!) > is materializing, we will soon be able to release our > long awaited 5.0 release, as planned some time ago. > This is the time to start to think about all the cool > things we always wanted to do but never had time for or > were afraid to ask :-) > > What I wanted to do before 5.0 is to integrate the ns_proxy > with ns_job (and junk the former). If there are any special > wishes (which we can slip into before the 5.0) please use > RFE section at SF. > > Cheers > zoran > > > > > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-27 14:53:38
|
On 27.09.2006, at 16:47, Vlad Seryakov wrote: > It would be good to have documentation ready for the 5.0 release, at > least all commands needs to be somewhat documented. Correct. As all (most) is now in CVS and in doctools... |
|
From: Vlad S. <vl...@cr...> - 2006-09-27 15:01:15
|
yes, all docs are in doctools under doc/src and there is make build-doc command that will generate .html and .n files under doc/html and doc/man make install will install manpages and html files in the installation directory so for the first access to newly installed server documentation will be available Also, when do you plan to release 5.0? Zoran Vasiljevic wrote: > On 27.09.2006, at 16:47, Vlad Seryakov wrote: > >> It would be good to have documentation ready for the 5.0 release, at >> least all commands needs to be somewhat documented. > > Correct. As all (most) is now in CVS and in doctools... > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Bernd E. <eid...@we...> - 2006-09-27 15:15:19
|
> The response(s) so far were almost unisono: NO. > Summary (rough): We like Tcl and we are happy with > C/Tcl server as-is now. There is no need for any > alternative page-construction language (PHP, JS, > whatever) because what we have is good (enough) > and its fairly easy to learn Tcl anyway, so why > bother with anyhing else? > > It is good to know where are we when thinking about > evolvement of the server code for the next few years. PHP is available, thanks to Vlad. We already use the latest version on a production system with NaviServer. We needed to integrate some PHP code from a customer and are happy to do it with NaviServer. You can evaluate code in both directions: PHP from within TCL/ADP pages and TCL from within PHP. That's nice. (**) I did not answer to your original mail because (a) I don't know if it would be the best strategical solution in your specific situation to let new candidates introduce an additional language you (and your colleagues) have to take care of and build knowledge, rather them learning the language the company is familiar with; and (b) if Server-Side Javascript is or becomes a 'Hype', worth enough to integrate. That said, I never understood why every effort to introduce a new language to the webserver over the last years crashes everytime on the TCL-is-so-great-and-Hypes-come-and-go-firewall. I doubt one would need a level of integration and status TCL has with the server to see interesting combinations of the new possibilites and to attract more people to the server. What's so bad (besides working effort) to try, fail or succeed? Bernd. (**) Of course, the natural brother and sister are a forking Apache and PHP, so you don't run into threading issues some binary PHP extension might have. On the production system we have modest requirements for the PHP interface we needed to integrate. |
|
From: Zoran V. <zv...@ar...> - 2006-09-27 15:29:14
|
On 27.09.2006, at 17:19, Bernd Eidenschink wrote: > That said, I never understood why every effort to introduce a new > language to > the webserver over the last years crashes everytime on the > TCL-is-so-great-and-Hypes-come-and-go-firewall. Weird, isn't it? > What's so bad (besides working effort) to try, fail or succeed? Time needed to get this done, which one could (better?) invest in polishing the things we have already. I believe this is the main reason (and, this is a good reason indeed). At the moment this Tcl/C marriage begins to itch us too much I will have to do something about (an alternative). |
|
From: Vlad S. <vl...@cr...> - 2006-09-27 15:31:47
|
Regarding PHP, now it has useful feature that if module is not thread-safe it will not be compiled when threading is enabled. We are usuing PHP with RoundCube Webmail and Drupal (http://www.drupal.org) system and it never crashed and works very stable. I thought that Javascript can be used same way, as external module. And Tcl will not be overhead beacuse if my conn thread does not call any Tcl script Tcl interp is not used, instead i can register Javascript server-side proc that will be called directly through the module. Bernd Eidenschink wrote: >> The response(s) so far were almost unisono: NO. >> Summary (rough): We like Tcl and we are happy with >> C/Tcl server as-is now. There is no need for any >> alternative page-construction language (PHP, JS, >> whatever) because what we have is good (enough) >> and its fairly easy to learn Tcl anyway, so why >> bother with anyhing else? >> >> It is good to know where are we when thinking about >> evolvement of the server code for the next few years. > > PHP is available, thanks to Vlad. We already use the latest version on a > production system with NaviServer. We needed to integrate some PHP code from > a customer and are happy to do it with NaviServer. You can evaluate code in > both directions: PHP from within TCL/ADP pages and TCL from within PHP. > That's nice. (**) > > I did not answer to your original mail because (a) I don't know if it would be > the best strategical solution in your specific situation to let new > candidates introduce an additional language you (and your colleagues) have to > take care of and build knowledge, rather them learning the language the > company is familiar with; and (b) if Server-Side Javascript is or becomes > a 'Hype', worth enough to integrate. > > That said, I never understood why every effort to introduce a new language to > the webserver over the last years crashes everytime on the > TCL-is-so-great-and-Hypes-come-and-go-firewall. I doubt one would need a > level of integration and status TCL has with the server to see interesting > combinations of the new possibilites and to attract more people to the > server. What's so bad (besides working effort) to try, fail or succeed? > > Bernd. > > > (**) Of course, the natural brother and sister are a forking Apache and PHP, > so you don't run into threading issues some binary PHP extension might have. > On the production system we have modest requirements for the PHP interface we > needed to integrate. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-27 15:42:01
|
On 27.09.2006, at 17:31, Vlad Seryakov wrote: > > We are usuing PHP with RoundCube Webmail and Drupal > (http://www.drupal.org) system and it never crashed and works very > stable. Amazing just how many CMS systems are out there... > I thought that Javascript can be used same way, as external module. > And Tcl will not be overhead beacuse if my conn thread does not > call any > Tcl script Tcl interp is not used, instead i can register Javascript > server-side proc that will be called directly through the module. It is much more than that: you need to open some of the things now only visible to the Tcl level, to Javascript as well in order to do something "meaningful". But is not impossible. It is just work... |
|
From: Vlad S. <vl...@cr...> - 2006-09-27 15:46:54
|
I remember i've done it with my OCaml module, it registers handlers for .cmo files and handles them in C, not via Tcl. I had to provide API to ns_conn and other stuff of course but it is not that complicated as it looks. Zoran Vasiljevic wrote: > On 27.09.2006, at 17:31, Vlad Seryakov wrote: > >> We are usuing PHP with RoundCube Webmail and Drupal >> (http://www.drupal.org) system and it never crashed and works very >> stable. > > Amazing just how many CMS systems are out there... > >> I thought that Javascript can be used same way, as external module. >> And Tcl will not be overhead beacuse if my conn thread does not >> call any >> Tcl script Tcl interp is not used, instead i can register Javascript >> server-side proc that will be called directly through the module. > > It is much more than that: you need to open some of the things > now only visible to the Tcl level, to Javascript as well in order > to do something "meaningful". But is not impossible. It is just work... > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2006-09-27 15:30:47
|
On 27.09.2006, at 17:00, Vlad Seryakov wrote: > > Also, when do you plan to release 5.0? A Christmas present to all of us? Hm? Should be possible... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X