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
