Application and web app technologies

January, 2006.

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.

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.

ยทยทยท

On Tue, Jan 03, 2006 at 03:27:56AM +0900, cartercc@gmail.com wrote:

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

This sig for rent: a Signify v1.14 production from http://www.debian.org/

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