[email protected] wrote in message
news:[email protected]…
time ago but have never actually written any C++). The problem is that
none of us can compare apples to apples, even though we more or less
can do what needs to be done with the tools we know.I don’t expect the ‘magical beast.’ What I do expect is several posts
along the following lines: ‘We faced a similar situation, and used X,
Y, and Z. X proved the best choice because of reasons A, B, and C. The
problem with Y was D and the problem with Z was E.’
But that’s what makes it impossible to give you any meaningful advice:
every
situation is different. Without being intimate with your architecture
and
what exactly web scripting and admin scripting means to you, it’s nearly
impossible to give vanilla advice about what language to use. You also
need
to bear in mind the skill set at your disposal. If no one knows the
language
you want to use, do you have time to account for the learning curve? Do
you
really want to try and replace all your programmers?
In Perl’s defence, bad programmers write bad Perl code. There is nothing
about the language that makes for unreadable code, only how you choose
to
write it. Going OO should be a no-brainer if you stay with Perl (just
for
the maintenance savings alone), but regardless of which language you
choose
you should have your programmers develop an accepted style (everything
from
how to name functions to how to structure your code library). If you let
programmers build their own little universes they will!
we need to rewrite the code is because (1) it doesn’t work (due to
external changes) and (2) it takes us less time to write new routines
that it does to decypher the old ones and modify them.
That’s again a sign of poor documentation coupled with bad style. It
will
always take a while to get back into your code, no matter what language
you
use. If you maintain consistency as you go, however, it eases a lot of
the
curve when you have to go back. You should probably look at other
measures
that involve your programmers more in making the coding a collective
practice (peer review, for example). So long as the focus is
constructive,
it will help the group better understand what they should all be
striving
for and what they should all be doing. That more than anything will help
prevent you from winding up in the same mess in a few years when you
discover each person has their own coding ideas for whatever language
you
opt for.
Matt
