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
