Forum: Ruby application and web app technologies

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
5b0b7a55223dba7a538aaf97dbbc6150?d=identicon&s=25 unknown (Guest)
on 2006-01-02 19:31
(Received via mailing list)
January, 2006.

I do not intend to start any kind of flame war, but only to seek advice
about different technologies concerning which I am mostly ignorant.

I am the database manager for a unit of a major state university. A
part of my job includes building database access and web enabled
applications for student services, faculty, and staff. These include
both information gathering applications and dynamic updates from our
big database to other applications. About 90 percent of our current
programming is in Perl. Of the rest, some is in ColdFusion, some is in
VB6, and we may have snippets in other languages. I might add that our
WWW pages are all in ColdFusion, which we like very much and have no
interest in changing.

I have been tasked by me IT department with investigating different
technologies for what will be a total rewrite and major update of our
applications. The problem with Perl is that it seems dowdy and old
fashioned, and that we never really investigate alternatives. We just
fell into Perl because that's what people knew. Also, we have had some
staff changes, and updating Perl code, some of which is years old,  has
proved to be a real nightmare. Perl works great! ... but trying to read
and modify someone else's code, or even your own, is pretty darn tough.

A real important part of this is database connectivity. We use a number
of different databases, Access, SQL Server, Datatel (the big University
DB), PostgreSQL (my favorite), MySQL, and a couple of others.

Here is where we currently are:

 * Java/JSP -- We have already made the decision to go with Java, but
we haven't started with it, and have not committed to Java.
 * Python -- Some of us have had limited experience with Python.
 * Ruby -- We have a Ruby advocate here, but no one knows anything
about it.
 * .NET/ASP -- We have a MS shop, I think that we have two UNIX servers
out of several dozen, and we are pretty firmly committed to Windows,
but no one is real excited about .NET, and the chances that we will
choose .NET seem real remote. Are there any advantages to using .NET?
 * OO Perl/Perl6 -- Perl has worked real well for us, but we have
doubts that it is the best technology, and we want to make a serious
attempt to look at other things.
 * C/C++ -- I mention this only because this is what IT uses. We have
no interest in C/C++, unless it really is the best.

We want something that we can use across the board, from web apps to
sys admin (which is why ColdFusion is not a candidate). I'm not
interested in advocacy, but if anyone has experience in and compare
these technologies, we would be grateful for your experiences.

My apologies for cross posting, I don't do it often, but I'd like to
reach as wide an audience as possible.

CC
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-01-02 19:40
(Received via mailing list)
cartercc@gmail.com wrote:
> January, 2006.
>
> I do not intend to start any kind of flame war, but only to seek advice
> about different technologies concerning which I am mostly ignorant.

I really do not want to see Yet Another "My Language/Toolkit Can Beat Up
You Language/Toolkit" thread (which, despite all the best intentions, is
where such topics often lead).   The new year *just* started. :)

Rather than rehashing it all, perhaps people can just post links to
existing resources that make a case for one or anther technology.

You can find some Ruby advocacy material at:

http://ruby-doc.org/whyruby/


James Britt

--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
280b41a88665fd8c699e83a9a25ef949?d=identicon&s=25 Stephen Waits (Guest)
on 2006-01-02 19:59
(Received via mailing list)
On Jan 2, 2006, at 10:27 AM, cartercc@gmail.com wrote:

> Datatel (the big University DB)

Ugh.. I feel for you.

--Steve
33eda546f35b0667856505f21f940529?d=identicon&s=25 Reinder Verlinde (Guest)
on 2006-01-02 20:15
(Received via mailing list)
In article <1136226294.170886.159690@z14g2000cwz.googlegroups.com>,
 cartercc@gmail.com wrote:

> January, 2006.
>
> I do not intend to start any kind of flame war, but only to seek advice
> about different technologies concerning which I am mostly ignorant.
> [...]
> I have been tasked by me IT department with investigating different
> technologies for what will be a total rewrite and major update of our
> applications.

From your post, it is not clear what these applications do. That may
hugely influence any advice you can get.

For instance: if you are running weather simulations on your back end,
Fortran and C would probably be good choices for part of your system. If
you are mostly running static web pages, your choice of CMS will
probably have more impact than your choice of scripting language.

Moreover, you do not tell who will do the maintenance on these systems.
If it is "IT", the choice might move towards C/C++ or a C/C++-like
scripting language.

> [...]
> The problem with Perl is that it seems dowdy and oldfashioned,

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).

> A real important part of this is database connectivity. We use a number
> of different databases, Access, SQL Server, Datatel (the big University
> DB), PostgreSQL (my favorite), MySQL, and a couple of others.

Any decent scripting language will be able to connect to most, if not
all, of these.

>  * Java/JSP -- We have already made the decision to go with Java, but
> we haven't started with it, and have not committed to Java.

If your 'deciding to' does not imply commitment, you have larger
problems then choosing a technology.

>  * Ruby -- We have a Ruby advocate here, but no one knows anything
> about it.

Never trust an advocate who knows nothing about the thing (s)he
advocates.

However, you should really take a look at Ruby on Rails
(www.rubyonrails.org). It is both good under the hood, and well-marketed
(check out some of the videos)

>  * C/C++ -- I mention this only because this is what IT uses. We have
> no interest in C/C++, unless it really is the best.

If your web apps contain stuff that needs high performance and is CPU
bound, you should keep these in as a language. Calling C/C++ code from
any decent scripting language is easy. Also, if you need commitment from
IT, choosing a less than best language may be a good idea.

Having said that, as far as I know, there are good reasons C and C++ are
not really popular for the development of web applications.

> We want something that we can use across the board, from web apps to
> sys admin

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.

Reinder
9dfe8c734b0f9b37a4e218425c0a2138?d=identicon&s=25 Gene Tani (Guest)
on 2006-01-02 20:24
(Received via mailing list)
cartercc@gmail.com wrote:
> January, 2006.
>
> I do not intend to start any kind of flame war, but only to seek advice
> about different technologies concerning which I am mostly ignorant.
>

</cross-posted>

It appears to me that you *are* inciting perlers to flame war by
cross-posting dowdy.  Regardless, your path of least resistance is to
sharpen uyp your googling skills, learn how to "Search this group" in
comp.lang.*.  Also look at reddit, furl, delicious, technorati, pubsub,
digg, projectionist, places like that (reddit 1st), see what other
people consider significant, and focus on TDD, unit- and other testing
capabilities, profilers, debuggers, tools like that.  And really, in
the dozen or hundreds of replies you will get, how will you decide who
has credibility?
1ffbf94afdc855391fc90cb1f9ec0ab5?d=identicon&s=25 Matt Garrish (Guest)
on 2006-01-02 21:00
(Received via mailing list)
<cartercc@gmail.com> wrote in message
news:1136226294.170886.159690@z14g2000cwz.googlegroups.com...
> January, 2006.
>
> * OO Perl/Perl6 -- Perl has worked real well for us, but we have
> doubts that it is the best technology, and we want to make a serious
> attempt to look at other things.

It might help if you elaborated on what these "doubts" are. It doesn't
sound
like you know any of the languages you've listed and are hoping that
somehow
you'll find one magical beast by cross-posting to a bunch of groups. I
don't
expect you're going to have much luck.

The fact that you list Perl 6 shows you aren't following Perl's
development
very closely. Perl 6 is not on the near horizon, and even as an avid
Perl
enthusiast I'd say you'd have to be insane to jump on it for production
use
as soon as it is.

That said, Perl is still one of the best choices for both Web and admin
scripting, and I don't see that you'd gain anything by rewriting all of
your
existing code to Ruby or Python just for the sake of saying you now use
Ruby
or Python (not that there's anything wrong with either, but why rewrite
code
for the sake of rewriting it?). If you wrote terrible and unreadable
Perl
code, what's really going to stop you from writing terrible and
unreadable
Ruby and Python code? That's more a statement on your programmers and
lack
of in-house style than the language.

C# isn't too bad for Web scripting and quick GUIs, but I've never used
it
for admin scripting and the downside is that it takes a lot of effort to
do
tasks in .Net that are simple in Perl/Python/Ruby (particularly database
work). I wouldn't use C/C++ for the web, but there's nothing stopping
you.

Matt
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2006-01-02 21:15
(Received via mailing list)
On Monday 02 January 2006 11:27 am, cartercc@gmail.com wrote:

> We want something that we can use across the board, from web apps to
> sys admin (which is why ColdFusion is not a candidate). I'm not
> interested in advocacy, but if anyone has experience in and compare
> these technologies, we would be grateful for your experiences.

Not to discount the comments from the others who have already replied --
they
are very correct that you'd probably benefit by looking in the archives
at
past advocacy discussions, and that you need to think about any changes
carefully; if you already have a large corpus of code and knowledge with
Perl, you need some pretty convincing reasons to change, I think.

However, I switched from being a hardcore Perl advocate and user close
to 4
years go to being a dedicated Ruby user for nearly everything I write,
from
sysadmin tools to web applications, and have been very happy with the
switch.
It is a fabulous language to work, day after day.

That said, do you have any specfiic questions or concerns about Ruby, in
particular, that we might be able to address?


Kirk Haines
9dfe8c734b0f9b37a4e218425c0a2138?d=identicon&s=25 Gene Tani (Guest)
on 2006-01-02 21:34
(Received via mailing list)
Gene Tani wrote:
> cross-posting dowdy.  Regardless, your path of least resistance is to
> sharpen uyp your googling skills, learn how to "Search this group" in
> comp.lang.*.  Also look at reddit, furl, delicious, technorati, pubsub,
> digg, projectionist, places like that (reddit 1st), see what other
> people consider significant, and focus on TDD, unit- and other testing
> capabilities, profilers, debuggers, tools like that.  And really, in
> the dozen or hundreds of replies you will get, how will you decide who
> has credibility?

a few follow ups so i don't appear nasty, but rather helpful, cause,
y'know, Matz is nice.

- the language flame wars had a home at artima.com, but they purged a
lot of them, but they're cached on google.  Since you're trying to get
power/weight ratios (power is how good tools are, weight is how verbose
/intuitive the core and std libs for each language/framework are),
google the site for terms like duck typing, polymorphism, pass by
value/reference, you'll see that a lot of smart people can't agree on
anything

- ok, so that doesn't help, but I will tell you Alex Martelli has
credibility, and he isn't afraid to make recommendations on just this:

http://groups.google.com/group/comp.lang.python/br...

- if you go to your manager and say, ok our RFP got this short list,
each of these has ample case studies on the web and we read all of
them, you probably won't be accused of being bought off by a vendor:
Zope 3, another python framework, rails, ASP.NET,
hibernate/strut/spring, PHP, something in perl that's better than
slashdot.  IANAL, this isn't a binding recommendation, notwithstanding
the foregoing this list includes without exclusion stuff i know nothing
about, don't sue me.
1b62a85b59ccab03b84ee5ec378f75b4?d=identicon&s=25 Steve Litt (Guest)
on 2006-01-02 21:37
(Received via mailing list)
On Monday 02 January 2006 01:27 pm, cartercc@gmail.com wrote:
> January, 2006.
[clip]
> A real important part of this is database connectivity. We use a number
> of different databases, Access, SQL Server, Datatel (the big University
> DB), PostgreSQL (my favorite), MySQL, and a couple of others.
[clip]
> We want something that we can use across the board, from web apps to
> sys admin (which is why ColdFusion is not a candidate). I'm not
> interested in advocacy, but if anyone has experience in and compare
> these technologies, we would be grateful for your experiences.

Perl, Python and Ruby can all be used across the board, assuming no huge
performance needs. Like another poster's reply, I don't think it's
necessary
to use only one language, but that's your decision.

I've used Perl 5 since 1997. It's wonderful. But not as good as Ruby,
IMHO.

Perl has that "many ways to do something" philosophy, which, in my
opinion, is
the kiss of death to maintainability in the face of transitioning staff.

Ruby has in my opinion a much less surprising syntax and behavior. Ruby
has a
MUCH better OOP implementation, with true encapsulation complete with
the
private, protected and public keywords. Ruby's attr_accessor,
attr_reader and
attr_writer give you what *looks like* direct access to instance
variables,
but really through get and set methods of the same name, so
incapsulation is
intact.

C++ has a very complete OOP implementation, but it's often complex and
can
throw surprises at the programmer.

Java is Java -- very broad and lots to learn.

Ruby, like Python and Java, has a much shorter debugging phase than Perl
or
Java.

I haven't tried Perl6 yet, but I've read about it, and it sounds broad
and
complex, and I'm not sure what it would do that Ruby can't.

The one area where Perl wins over Ruby is performance -- others can give
you
ideas as to the extent of the performance gap.

HTH

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2006-01-02 21:40
(Received via mailing list)
On Tue, Jan 03, 2006 at 03:27:56AM +0900, cartercc@gmail.com wrote:
> interest in changing.
Use what works.  Don't change things just to change them.

Of the above, however, I guess I'm not surprised VB is on the chopping
block for future development (I'm not a huge fan of hamstrung
languages), but it surprises me that the ColdFusion web apps aren't.
Call it a personal bias, and ignore it, I guess.


>
> I have been tasked by me IT department with investigating different
> technologies for what will be a total rewrite and major update of our
> applications. The problem with Perl is that it seems dowdy and old
> fashioned, and that we never really investigate alternatives. We just
> fell into Perl because that's what people knew. Also, we have had some
> staff changes, and updating Perl code, some of which is years old,  has
> proved to be a real nightmare. Perl works great! ... but trying to read
> and modify someone else's code, or even your own, is pretty darn tough.

If Perl is what people know, perhaps you should use it -- at least until
people know something else.  On the other hand, I've got to wonder
what's wrong with your programmers that their code isn't later
modifiable.  Despite Perl's reputation amongst some other programming
communities, it isn't intrinsically difficult to maintain.  Hard to read
code can be written in any language, as can easy to read code.  Don't
blame the language.


>
>  * Java/JSP -- We have already made the decision to go with Java, but
> we haven't started with it, and have not committed to Java.

Java's very good for at least one thing: allowing many programmers over
the life of a long-term project (and anything that needs to be
maintained for a long time is a long-term project) to write and maintain
code without any one programmer screwing up the codebase.  I suspect
that's one of the reasons it's so popular with corporate development
shops (aside from all the Sun marketing and so on).  It's something to
consider when picking a language for a project.


>  * Python -- Some of us have had limited experience with Python.

It's a great language for rapid development, OOP, and enforcing some
clear code formatting, by all accounts.  Considering your previously
indicated problem with unreadable code, perhaps this is exactly what you
need, to strongarm some clean formatting where your programmers might
lack the discipline to do it on their own.  Python source code makes my
eyes bleed, but that doesn't hold true for everyone, and I'd personally
rather work with Python than Java anyway, so if you're looking for
personal opinions you've now got mine.


>  * Ruby -- We have a Ruby advocate here, but no one knows anything
> about it.

Ruby's great.  Rails makes database-driven web applications blindingly
easy, and might in itself be a reason to pick Ruby for some development
work over another language, though I hear Django (for Python) is coming
along nicely.  That aside, I'd say that the capabilities of Perl,
Python, and Ruby are close enough that if it comes down to those three,
personal preferences should probably end up being among your major
factors for consideration.


>  * .NET/ASP -- We have a MS shop, I think that we have two UNIX servers
> out of several dozen, and we are pretty firmly committed to Windows,
> but no one is real excited about .NET, and the chances that we will
> choose .NET seem real remote. Are there any advantages to using .NET?

Plenty.  It does for Windows what a bunch of Java marketers claim Java
does.  Have you heard the phrase "write once, run anywhere"?  How about
"write once, run nowhere"?  There's some considerable frustration with
the mythical portability of Java amongst fairly large segments of the
developer population, and .NET solves a lot of that for MS platforms.
Its development environments are reportedly great for people who like
that sort of thing.

That said, I could give you about 1001 different reasons to avoid .NET,
but most of them would fall on deaf ears in a Microsoft shop, so maybe
you should consider it.


>  * OO Perl/Perl6 -- Perl has worked real well for us, but we have
> doubts that it is the best technology, and we want to make a serious
> attempt to look at other things.

At the risk of being told to "go back to Perl" again: If it has worked
really well for you, and you have people that already know it but don't
know similarly applicable languages, you might consider why you're
looking at other languages for development.  If you don't have a good
solid reason for changing, stick with what you've got.  Changing for the
sake of change is more likely to introduce problems than solve any, and
Perl's a great language anyway.  There are very good reasons that it's
the sysadmin language of choice.

You probably shouldn't be using Perl 6 for production code yet.  It's
still in a serious state of flux, and what you write today is likely to
be broken when a stable Perl 6 release is available.  5.8.7 is pretty
much where it's at right now.


>  * C/C++ -- I mention this only because this is what IT uses. We have
> no interest in C/C++, unless it really is the best.

"Best" for what?

This might be the heart of the problem: you might be looking for a
"best" language.  While there are some languages I'd pretty much rather
suffer a sucking chest wound than use, and there are some languages for
which I look for excuses to use (Perl is one, and Ruby is looking like
it's going to be another), I'd never go so far as to say that any of
them are "the best".  Languages tend to have strengths and weaknesses,
and which is best to use for a given project depends on the project and
the people involved.  Paul Graham, one of the world's most infamous Lisp
advocates, might disagree with my estimation of the existence of a
"best" language (or at least family of languages), but unlike him I
don't expect you're likely to end up with a shop full of genius hackers
just by choosing a language that mostly shines in the hands of that rare
breed and is almost inscrutable to most of the rest of us.


>
> We want something that we can use across the board, from web apps to
> sys admin (which is why ColdFusion is not a candidate). I'm not
> interested in advocacy, but if anyone has experience in and compare
> these technologies, we would be grateful for your experiences.

Perl, Python, and Ruby all fit that bill nicely.  Usually, you don't
want to use C or Java for sysadmin scripts or anything involving rapid
development.

I'm a little confused by the desire to make everything use one language.
There are, for instance, a great many places that use Perl for
prototyping, testing, and so on when doing C or C++ development.  Python
seems to be among the most popular choices for doing the same thing for
Java development.  While I've heard catalyst is Perl's answer to Rails,
I suspect we'll start seeing a lot of primarily Perl shops using Ruby on
Rails for web development in the near future.

It might make sense to standardize on a small number of languages,
depending on your organization's needs (I've never done any information
technology work in academia so I wouldn't really know its peculiar
needs), I doubt there's a silver bullet language for you, no matter what
Sun and MS might tell you about Java and .NET respectively.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

This sig for rent:  a Signify v1.14 production from
http://www.debian.org/
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2006-01-02 21:43
(Received via mailing list)
On Tue, Jan 03, 2006 at 05:32:57AM +0900, Gene Tani wrote:
>
> them, you probably won't be accused of being bought off by a vendor:

Considering the indication that it's a Microsoft shop, I doubt that's at
issue here.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

This sig for rent:  a Signify v1.14 production from
http://www.debian.org/
B44322cee8f1794fdac669d9c29a2585?d=identicon&s=25 Roedy Green (Guest)
on 2006-01-03 01:25
(Received via mailing list)
On 2 Jan 2006 10:24:54 -0800, cartercc@gmail.com wrote, quoted or
indirectly quoted someone who said :

> * Java/JSP -- We have already made the decision to go with Java, but
>we haven't started with it, and have not committed to Java.
> * Python -- Some of us have had limited experience with Python.
> * Ruby -- We have a Ruby advocate here, but no one knows anything
>about it.

In many shops, perhaps yours too, you are relying on volunteers.  The
problem is they suddenly disappear on you leaving no notes.   In that
situation, you want to push for as vanilla technology as possible so
that you have maximal chance the next guy will already be familiar
with the tools.

From that point of view Java is a nice choice, as is MySQL and JSP.
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 James Britt (Guest)
on 2006-01-03 01:34
(Received via mailing list)
Roedy Green wrote:
>
> In many shops, perhaps yours too, you are relying on volunteers.  The
> problem is they suddenly disappear on you leaving no notes.   In that
> situation, you want to push for as vanilla technology as possible so
> that you have maximal chance the next guy will already be familiar
> with the tools.

Ah. The famous Redundant Array of Java Coders

I hear you can hot-swap them, but they're terribly inefficient.

James
--

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
Fd455730035cffbf65355869ba251b18?d=identicon&s=25 Van (Guest)
on 2006-01-03 06:19
(Received via mailing list)
Try matching technologies when building a decision matrix...
For example, if you need the PHP open source pile then MySQL works
well.
If you like SQL Server then ASP.NET or Mono with C# is attractive.
Eliminate contenders that have performance obstacles...
PERL does not multithread, PHP.com holds back the cache goods from
PHP.org.
Find a theme and follow it a logical conclusion, here is my
experience....I was looking for a good JavaScript Library to Ajax my
offering.I found Mochikit to be well documented, cross browser with an
active forum.The author described Mochikit as Python like which caused
me to investigate Python.Terse, compact, easy to embed C/C++ with
multithreading are impressive.ZOPE a python written web server with
ZODB (in-memory db/cache mechanism) sealed the deal for me.  Most of
the Zope/Python/SQL code uses PostgreSQL examples.
I am concerned about bandwidth associated with the myriad dev tasks.
A good JavaScript library eliminates major hassles, you may have to
combine some.
SQL is SQL, it comes down to documentation, interface, licensing or
preference.
Server code that does not render standards compliant web pages is a
pain to test.
ZPT from ZOPE solves that problem nicely, with a fast XML page parser.
So prioritize you needs:  Labor, Standards, Functionality, Training,
etc.
Then evaluate you stacks based on your priorities.
The last time I was involved with university operations we had unit
record gear.
Good Luck,
Van
5b0b7a55223dba7a538aaf97dbbc6150?d=identicon&s=25 ccc (Guest)
on 2006-01-03 18:59
(Received via mailing list)
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
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 Ryan Leavengood (Guest)
on 2006-01-03 19:00
(Received via mailing list)
On 1/3/06, ccc <cartercc@gmail.com> wrote:
>
> 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.

I have been programming Java for about 8 years (6 or 7 of that
professionally) and Ruby for about 5 years (mostly as a hobbyist.)
I've dabbled in Python but not much in Perl.

With that said, I would not recommend Java for the kind of tasks you
seem to be doing. You need something flexible and lightweight, and
from my experience Java is not that. Java certainly has its place, but
I don't think your university and its associated applications is one
of those places.

I would highly recommend you stay in the scripting language realm,
either maintaining your Perl or switching to Python or Ruby.

Ruby is a great language and one that I have found fits my style and
mind better than Python or Perl. It has the flexible TIMTOWDI (There
Is More Than One Way to Do It) nature of Perl with less of a tendency
to get obfuscated. I personally never liked the significant whitespace
of Python, but in general it is a great language and would be a good
choice if that style works with you and your colleagues.

Either way, before you make a complete "switch", do a few prototype
applications in the serious contenders for your new language choice.
You should be able to learn the small amount required of each language
to code up some fairly small apps in a week or two, and the learning
experience of coding a real application will be completely worth it.
Believe me there is no better way to learn a language (both its
strengths and weaknesses) than to code up an application in it.

If you could make the *same* application in all your language choices
(let's say the email creator in Ruby, Python and Java) that would
provide the best comparison. I would also recommend posting the
resulting code to Ruby, Python and Java mailing lists or newsgroups to
see what kind of improvements the experts can recommend.

Then show the resulting tweaked code to your colleagues and let them
decide what looks best.

Ryan
5b0b7a55223dba7a538aaf97dbbc6150?d=identicon&s=25 unknown (Guest)
on 2006-01-03 19:00
(Received via mailing list)
> It might help if you elaborated on what these "doubts" are. It doesn't sound
> like you know any of the languages you've listed and are hoping that somehow
> you'll find one magical beast by cross-posting to a bunch of groups. I don't
> expect you're going to have much luck.

No, we don't know any of these languages. I'm reasonably competent in
Perl, and I have used some Java and Python (and taught C++ a loooong
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.'

> That said, Perl is still one of the best choices for both Web and admin
> scripting, and I don't see that you'd gain anything by rewriting all of your
> existing code to Ruby or Python just for the sake of saying you now use Ruby
> or Python (not that there's anything wrong with either, but why rewrite code
> for the sake of rewriting it?).

I agree with you about Perl, and CPAN is a fab resource, but the reason
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. Besides, I work
in an academic setting, and when people ask you what you use, I have
learned to cringe when I reply, 'Perl.'

CC
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2006-01-03 19:00
(Received via mailing list)
On Jan 3, 2006, at 17:47, cartercc@gmail.com wrote:

> I have
> learned to cringe when I reply, 'Perl.'

For each language L you'll need to cringe at someone because you use
L. Some people love Python, clean, design well-taste, blah, blah,
some can't stand its whitespace conventions, can't stand the mix
functions/methods, its documentation (that's me) etc. Some people
love Ruby, some think it ends up being too dense, lack of mature
libraries versus such and such, blah, blah. Some people love Perl,
some say it's line noise, blah, blah. Lisp, Java, Eiffel, C++, C, ....

It's a lost battle :-).

-- fxn
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2006-01-03 19:00
(Received via mailing list)
On Wed, Jan 04, 2006 at 01:47:58AM +0900, cartercc@gmail.com wrote:
>
> I agree with you about Perl, and CPAN is a fab resource, but the reason
> 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. Besides, I work
> in an academic setting, and when people ask you what you use, I have
> learned to cringe when I reply, 'Perl.'

Just use the best tool for the job.  Who cares if someone has delusions
of the "one true way"?  Most language communities have a sense of
superiority as if they've found the only language worth knowing in some
significant portion of that community.  My experience is that Ruby and
Perl suffer that problem less than most, but the point is that you'll
end up with someone looking down their nose at you no matter what
language you choose.

If you really want to be in some kind of academic elite with your
language of choice, though, you could just go with a Lisp variant.  The
Lisp family of language has a lot going for it, including the fact that
Lisp is apparently the One True Way -- just like every other language,
but even moreso in academia.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

"Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts." - Paul Graham
Dba0cb4cdad3b8e3b7ed0fddff5d20a5?d=identicon&s=25 Stephen Kellett (Guest)
on 2006-01-03 19:16
(Received via mailing list)
In message <43B9C6A6.5050903@neurogami.com>, James Britt
<james_b@neurogami.com> writes
>Ah. The famous Redundant Array of Java Coders
>
>I hear you can hot-swap them, but they're terribly inefficient.

Yeah, the latency between cups of latte is horrendous.

Stephen
1b5341b64f7ce0244366eae17f06c801?d=identicon&s=25 Kirk Haines (Guest)
on 2006-01-03 19:16
(Received via mailing list)
On Tuesday 03 January 2006 9:47 am, cartercc@gmail.com wrote:

> 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.'

I think, though, that what you will find is that there is someone who
can give
that answer for many different values of X, Y, and Z.

I flipped, cold turkey from Perl to Ruby nearly 4 years ago, as I said.
I was
convinced that for sysadmin programming and web site/application
programming,
I would get better productivity and maintainability from Ruby than Perl,
even
though I had vastly more experience with Perl at the time.

IMHO, I made the right decision, for me.  I have some Perl legacy
systems that
I have had to maintain, though I have converted a portion of those to
Ruby
systems, and I occasionally have to do new work in Perl or PHP or,
rarely,
other languages, but Ruby is the primary programming language, day to
day.

I doubt that you will have to look hard to find someone who will say the
same
things about Python, though, nor will you have to look far to find
people who
say that my assessment was wrong, and that if I had been smarter, I
would
have been just fine or even better off sticking with Perl.

So, I'll reiterate what I said before.  Take a look at the previous
threads
along these lines.  Take a look at the Ruby advocacy link that was
provided,
and then see if you have any specific questions that we might be able to
answer about Ruby.


Kirk Haines
1ffbf94afdc855391fc90cb1f9ec0ab5?d=identicon&s=25 Matt Garrish (Guest)
on 2006-01-03 19:28
(Received via mailing list)
<cartercc@gmail.com> wrote in message
news:1136306578.271826.302110@g44g2000cwa.googlegroups.com...
> 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
5b0b7a55223dba7a538aaf97dbbc6150?d=identicon&s=25 ccc (Guest)
on 2006-01-03 22:41
(Received via mailing list)
> 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?

We don't have any 'programmers' on staff. At most, we have several
people writing, maybe, two hours  of code a week, with maybe once a
year building an application. We are just your basic IT shop, system
and network administration, hardware, help desk, the web site, and
database administration. This is also the reason for the 'bad code' (
which we have in abundance.) People who are not programmers and whose
job it isn't to program will not write good code. I'm not being
perjorative, just factual.

> If you let
> programmers build their own little universes they will!

Yeah, well, if you have a database admin writing his scripts, a network
admin writing his scripts, and a couple of floaters trying to fix
things that break, with no one holding the reins, you get little
universes. Which is what happened and which we want to be proactive and
prevent in the future.

> 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.

Exactly! And a major decision is deciding on a technology so that we'll
all be using the same thing.

Actually, Java was a pretty easy decision to make, since we already had
a problem with Perl, no one wanted to do C or C++, and no one knows VB,
and most of us had used Java at some point along the way. HOWEVER, we
know we face a learning curve, and we want to get the most bang for the
buck, and we have a good enough handle on our Perl scripts so this
isn't a time critical desicion, so we are just looking.

CC
Fbaa72b7e8188955d64448f74b8e1feb?d=identicon&s=25 Harpo (Guest)
on 2006-01-04 00:48
(Received via mailing list)
ccc wrote:

>
> We don't have any 'programmers' on staff. At most, we have several
> people writing, maybe, two hours  of code a week,

Fine !

> with maybe once a
> year building an application. We are just your basic IT shop, system
> and network administration, hardware, help desk, the web site, and
> database administration. This is also the reason for the 'bad code' (
> which we have in abundance.) People who are not programmers and whose
> job it isn't to program will not write good code. I'm not being
> perjorative, just factual.

Let's be positive : 2 hours of bad code a week is better than 40 hours
of bad code a week.

And what is bad code and what is good code ? Your problem doesn't seem
to be a programming issue, Often, the problem is not at this level,
trying to find 'the good language' is just spending time, there is no
'good language', it is just a thing that doesn't exist in the real
life,

Gathering code to make an heteroclitic system is never a good solution,
threwing heterodoxic code (but maybe good code) to the trashcan is not
a good solution, rewriting in another language is painful and bug
prone, therefore not a good solution if not the worst.

In the real life, there is no good solution but many false problems.
Your problem in not a programming problem but a liability problem, not
seeing this problem will give more problems.

What do you expect ? You crosspost to perl, python, java and ruby NGs,
Do you want me to say 'Ruby is better' ? This would be stupid.

You have Perl code that you seem to find non understandable ? Does it
work ? If it works, it's ok but it would have been better if you
understood why.

My advice : Just don't touch anything.

FU2
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2006-01-04 01:40
(Received via mailing list)
On Wed, Jan 04, 2006 at 06:37:58AM +0900, ccc wrote:
>
> Actually, Java was a pretty easy decision to make, since we already had
> a problem with Perl, no one wanted to do C or C++, and no one knows VB,
> and most of us had used Java at some point along the way. HOWEVER, we
> know we face a learning curve, and we want to get the most bang for the
> buck, and we have a good enough handle on our Perl scripts so this
> isn't a time critical desicion, so we are just looking.

I don't foresee this solving your problem in the least.  Unreadable or
unmaintainable code can be written in any language.

That having been said, however, you could do worse than Java for your
purposes.  After all, limiting the damage that large numbers of mediocre
programmers can do over an extended period is the one thing at which
Java seems to excel most.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

"A script is what you give the actors.  A program
is what you give the audience." - Larry Wall
B44322cee8f1794fdac669d9c29a2585?d=identicon&s=25 Roedy Green (Guest)
on 2006-01-04 02:00
(Received via mailing list)
On Wed, 04 Jan 2006 00:47:22 +0100, Harpo <trashcan@hotmail.com>
wrote, quoted or indirectly quoted someone who said :

>Gathering code to make an heteroclitic system is never a good solution,
>threwing heterodoxic code (but maybe good code) to the trashcan is not
>a good solution, rewriting in another language is painful and bug
>prone, therefore not a good solution if not the worst.

heteroclitc -- irregular, abnormal
heterodoxic -- unorthodox
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-01-04 03:46
(Received via mailing list)
Xavier Noria wrote:

> For each language L you'll need to cringe at someone because you use
> L. Some people love Python, clean, design well-taste, blah, blah,
> some can't stand its whitespace conventions, can't stand the mix
> functions/methods, its documentation (that's me) etc. Some people
> love Ruby, some think it ends up being too dense, lack of mature
> libraries versus such and such, blah, blah. Some people love Perl,
> some say it's line noise, blah, blah. Lisp, Java, Eiffel, C++, C, ....
>
> It's a lost battle :-).

It's not a lost battle here ... unless you're advocating something other
than Ruby. :)

Seriously, though, Ruby is a young language that's had a chance to learn
from the mistakes of its ancestors. The things it's missing --
Lisp-style macros are the only major one I can think of at the moment --
aren't things that necessarily are useful to a *lot* of programmers. A
few improvements in the performance of the run-time, and Ruby could well
rule the world.

But it will never replace R. :)

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
A21dbcbb339a1198f4ab81d6f833778c?d=identicon&s=25 l v (Guest)
on 2006-01-04 04:28
(Received via mailing list)
ccc wrote:
> [snip] We are just your basic IT shop, system
> and network administration, hardware, help desk, the web site, and
> database administration. This is also the reason for the 'bad code' (
> which we have in abundance.) People who are not programmers and whose
> job it isn't to program will not write good code.

Technology is not your problem just as the above are not the reasons
for the bad code.  In my 15 years in IT, I've see bad COBOL, Quickjob,
JCL, Java, shell scripts, DB modeling, Perl, SQL, ABAP, etc.  Bad code
moves from one language to another.  Procedures such as good coding
standards, peer reviews, adherence to coding standards, etc are the
key.

>
> Yeah, well, if you have a database admin writing his scripts, a network
> admin writing his scripts, and a couple of floaters trying to fix
> things that break, with no one holding the reins, you get little
> universes. Which is what happened and which we want to be proactive and
> prevent in the future.
>
> Exactly! And a major decision is deciding on a technology so that we'll
> all be using the same thing.

Ah, one language fits all.  Perhaps OO COBOL should be considered.  :)

>
> Actually, Java was a pretty easy decision to make, since we already had
> a problem with Perl, [snip]

IMO, your problem was not with Perl, it was not having standards,
reviews and quite possibility the staff's unfamiliarity with the Perl
language.  Is it unreadable code or code that  uses more advanced
techniques than the programmers knowledge?

Len
918c6daad03c85e51ad1a11f57017947?d=identicon&s=25 Devin Mullins (Guest)
on 2006-01-04 05:01
(Received via mailing list)
ccc wrote:

>Exactly! And a major decision is deciding on a technology so that we'll
>all be using the same thing.
>
>
If I had to pick a technology to unify in a development shop, it'd be
the source code repository. More important, though, is unifying the
version/build process.

>Actually, Java was a pretty easy decision to make, since we already had
>a problem with Perl, no one wanted to do C or C++, and no one knows VB,
>and most of us had used Java at some point along the way. HOWEVER, we
>know we face a learning curve, and we want to get the most bang for the
>buck, and we have a good enough handle on our Perl scripts so this
>isn't a time critical desicion, so we are just looking.
>
>
Try Ruby. It's friendly for Perl users, but object-oriented enough to be
competitive with Java (which, granted, isn't saying much).
http://tryruby.hobix.com/

Of course, this is a Ruby mailing list, so don't expect lack of bias...

I do agree with everyone else, though, that your solution may best be
acquired in a non-technical way first. Once you've found that your
process is improving, and you're able to track changes, and whatnot,
*then* you can look around for new toys -- er, technologies -- to play
with.

Devin
5b0b7a55223dba7a538aaf97dbbc6150?d=identicon&s=25 ccc (Guest)
on 2006-01-04 18:12
(Received via mailing list)
> I don't foresee this solving your problem in the least.  Unreadable or
> unmaintainable code can be written in any language.

> That having been said, however, you could do worse than Java for your
> purposes.  After all, limiting the damage that large numbers of mediocre
> programmers can do over an extended period is the one thing at which
> Java seems to excel most.

A pretty high priority is getting everyone to use the same language. If
we do that, we will at least have the benefits of cross pollination,
and other shoulders to cry on if something doesn't work.

The pay is low, but one of the benefits of working at a school is that
you get your education at a greatly reduced cost. We have a PhD
candidate in SwEng, several MS candidates in CS, and several MSs in CS
floating around, and Java is real big right now in academia.
Personally, I just have this nagging suspicion, an anxiety really, that
we haven't done everything we should unless we look at alternatives.

But we'll probably gravitate to Java, kind of like a satillite falling
to earth -- it's gravitational attraction is so strong that it's a lot
more work to try something different. That said, I really like Perl,
but it seems too hard to use in an environment where we have a lot of
turnover and always need to change something someone else has written.

Thanks for your advice, this exchange has been helpful for us.

CC
5b0b7a55223dba7a538aaf97dbbc6150?d=identicon&s=25 ccc (Guest)
on 2006-01-04 18:12
(Received via mailing list)
> but it surprises me that the ColdFusion web apps aren't.
> Call it a personal bias, and ignore it, I guess.

CF is like that torx screwdriver in the toolbox. It only works on a few
things, but boy, it does a good jopb on those. For our websites, we use
a combination of CF, Dreamweaver, and Photoshop, and these have worked
extremely well. I'm not a fan of proprietary software, but I'd put CF
up against PHP, ASP, and CGI-Perl/Python any day.

> I'd never go so far as to say that any of
> them are "the best".  Languages tend to have strengths and weaknesses,
> and which is best to use for a given project depends on the project and
> the people involved.

Right. We don't build big apps, but we have a need for something that
isn't too difficult for people to get up to speed on, that can be used
in different contexts, and that will be around for a while.

> I'm a little confused by the desire to make everything use one language.

Not 'everything' but 'everything we do.' Probably about ninety percent
of what we do involves writing some kind of data to a DB, then reading
the data and spitting it out in one for or another. Unfortunately, we
also deal with a number of different systems, AIX, Linux, even BSD,
although our unit is primarily a MS shop.

> It might make sense to standardize on a small number of languages,
> depending on your organization's needs (I've never done any information
> technology work in academia so I wouldn't really know its peculiar
> needs), I doubt there's a silver bullet language for you, no matter what
> Sun and MS might tell you about Java and .NET respectively.

Yeah, and we have a couple of folks excited about Monad (MSH). I don't
think our needs are any different from any other small shop. We have a
bunch of non-programmers hacking on code, using the language of their
choice, with the predictable results. Perl I think is the 'silver
bullet' that will kill all the vampires, but in our experience it's
proven more than we can handle given our turnover and different
abilities and interests.

We'll probably standardize on a 'big' language and a 'little' language.
Just before Christmas, I had to send a bulk email to students matching
certain criteria, and I wrote a little Perl script of less that 20
lines that ran the query, cleaned up the data, sent the email, and
generated reports on those getting the email and those not getting it
(6 out of some 200 names). I figure Java would have required a lot more
code, but I would hate to have to ever look at my Perl script again.
Which is why we are looking at trading some ease of development in
exchange for some persistence of the codebase.

CC
64eb208fbf53dd0f9ac7ba900ef6c18b?d=identicon&s=25 Juha Laiho (Guest)
on 2006-01-06 07:58
(Received via mailing list)
"ccc" <cartercc@gmail.com> said:
>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.

This tells a lot more about the original author of the scripts than the
language used. I'm seeing unmaintainable code written in pretty much any
language. Java (and in some ways, especially JSP in the web side) is no
cure for that.

Having said that, it may be easier to write unmaintainable Perl than
unmaintainable Java. The key is to educate (and to a certain limit
restrict) the programmers on what kind of code is acceptable to write.
And this work I think is not that dissimilar between different
languages.

Also, OO is not a magic bullet in making code readable. At worst it
gives the programmer a couple of extra levels of indirection to use
just to complicate the otherwise streamlined program. OO is good
where the data used naturally forms nice object relationships, but
there are a good number of cases where this does not happen (or at
least the relationships do not help that much in solving the actual
problem).

If you really, as you mentioned somewhere, want an all-around-language,
then Perl might be your best bet. Java is nice for web applications,
however I wouldn't use it for sysadmin stuff (or, it could be used
for part, but part is that you need an one-off tool; something you
cook up fast and use once or twice -- or a quick modification for
the existing tools). Also, much of sysadmin (esp. on Unix side) is
processing various text formats, which is one of the great strengths
of Perl. It's not just regexes (which finally are available in Java
as well), but overall facilities of the language.

Then, regarding the performance/efficiency; yes; there are cases where
use of C is justified for performance reasons. This performance
comes at a cost of programmer productivity (and possible higher
rate of certain kinds of errors). Also, in higher-level languages
the libraries are getting pretty-well tuned at least for the general
case, so it may well be that much of the general routines you find
in the library of a given language are of better performance than
something you yourself cook in C.

Another area where C would be useful is for making the necessary
glue to access some backend system (for which only C interface
library is provided) in the higher-level language of your choice.
A good example of this are the various database connectivity modules
in Perl (part Perl, part C; linking to the database client library
code).

So, overall:
- you're a Perl shop - however have lost some of your assets
  (knowledgeable personnel)
- one problem may have been too great independence of the developers,
  and lacking maintainability guidelines for the created code
- making the hop to another language would be a major hurdle
  (possibly giving major gains, though)
- could the same potential gains be realised without doing the
  language hurdle? Potentially yes; but would require more-or-less
  redesign/rewrite of the whole current environment, so a major
  hurdle anyway
- does the current language limit what you can do - doesn't seem so
- what would be gained by another language? For some other languages
  it could be easier to find developers -- however, finding competent
  developers appears to be hard for any language (competent defined
  as "able to produce code that is maintainable in the long run")

.... so, all in all, I wouldn't be that eager in shifting from the
current. Java/JSP (and higher-level frameworks built on top of these)
could be good for web side - but these require quite a lot of knowledge
to do properly (just plugging things from a full Java/J2EE toolbox to
solve your problem could well give you nothing else but horrible
performance problems -- whereas proper use of J2EE technologies could
give you a somewhat elegant solution).

Apologies for omitting completely Python, Ruby, and MS technologies;
I don't know enough of them to do any comparision.
This topic is locked and can not be replied to.