Thanks for your post. I see from the tone of the replies that I may
have made a 'huge' mistake in using the ngs for research.
> From your post, it is not clear what these applications do. That may
> hugely influence any advice you can get.
Just about everything. For two cases in point: (1) We have a web
enabled application for faculty members to do things like posts
attencence, print rosters, etc., which is updated four times a day from
the big DB. The big DB uses a product named Datatel, and our webapp
runs on SQL Server. Our Perl script queries Datatel, runs a number of
queries, downloads the data, shakes it a bakes it, and then shoves it
into SQL Server with DTS. This is one of our most important
applications and it is an absolute monster to do manually. (2) We also
run a little app to generate email accounts for new employees, which is
not a big deal unless you happen to be a new employee who doesn't have
an email address. Our applications run the gamut from the large,
critical apps to the convenience ones.
> Never dismiss anything because it 'seems' bad. Your 'seems
> old-fashioned' is someone else's 'proven technology'. You should work on
> objectifying this statement (because I am not a Perl fan, I expect that
> this will be possible).
I *am* a Perl fan, but after having looked at scripts someone else
wrote (who is no longer with us) with a view toward updating them, I
have concluded that a quick and dirty scripting language in someone
else's idiom isn't a very good choice institutionally. Which is why I'm
looking at OO Perl.
> Moreover, you do not tell who will do the maintenance on these systems.
The database people will maintain the programs, and as you can imagine
these skills are quite varied, which is one reason we want to settle on
one technology we can all use.
> If your 'deciding to' does not imply commitment, you have larger
> problems then choosing a technology.
Our 'deciding to' was like this: 'Java seems to be hot, so let's all
use it.' Yes, we may have bigger problems, but we still want to commit
to one technology that will do the job.
> Never trust an advocate who knows nothing about the thing (s)he
> advocates.
I mispoke ... the advocate know a little about Ruby, but none of the
others do, and we don't want to take his word without satisfying
ourselves that what he says is true.
> Why would you? programming languages all have their strengths and
> weaknesses. Good programmers will be able to choose a midway path
> between standardisation on a single language and using the best language
> for every task.
We really have a hodgepodge. We have snippets written in ColdFusion,
Perl, VB6, VB7, a little C, a couple of Java apps, and some other
miscellanous stuff. We don't have any 'programmers' on staff. People
have tended to focus on the problem at hand and have used whatever
language they were familier with. We want to move beyond this, and do
some real SW engineering.
>From what I have gathered, our first impulse to use Java was probably
the right one, even though it wasn't really based on any kind of
investigation. I just hate to commit to something that I have doubts
about.
CC
--
http://mail.python.org/mailman/listinfo/python-list
