application and web app technologies

**Reinder Verlinde** · Jan 2 '06, 07:25 PM

Re: application and web app technologies

In article <1136226294.170 886.159690@z14g 2000cwz.googleg roups.com>,
cartercc@gmail. com wrote:
[color=blue]
> 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.[/color]

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.
[color=blue]
> [...]
> The problem with Perl is that it seems dowdy and oldfashioned,[/color]

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).
[color=blue]
> 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.[/color]

Any decent scripting language will be able to connect to most, if not
all, of these.
[color=blue]
> * 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.[/color]

If your 'deciding to' does not imply commitment, you have larger
problems then choosing a technology.
[color=blue]
> * Ruby -- We have a Ruby advocate here, but no one knows anything
> about it.[/color]

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)
[color=blue]
> * 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.[/color]

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.
[color=blue]
> We want something that we can use across the board, from web apps to
> sys admin[/color]

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

**Matt Garrish** · Jan 2 '06, 08:05 PM

Re: application and web app technologies

<cartercc@gmail .com> wrote in message
news:1136226294 .170886.159690@ z14g2000cwz.goo glegroups.com.. .[color=blue]
> 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.[/color]

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

**Roedy Green** · Jan 3 '06, 12:35 AM

Re: application and web app technologies

On 2 Jan 2006 10:24:54 -0800, cartercc@gmail. com wrote, quoted or
indirectly quoted someone who said :
[color=blue]
> * 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.[/color]

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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

**Van** · Jan 3 '06, 05:25 AM

Re: application and web app technologies

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

**ccc** · Jan 3 '06, 04:15 PM

Re: application and web app technologies

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.
[color=blue]
> From your post, it is not clear what these applications do. That may
> hugely influence any advice you can get.[/color]

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.
[color=blue]
> 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).[/color]

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.
[color=blue]
> Moreover, you do not tell who will do the maintenance on these systems.[/color]

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.
[color=blue]
> If your 'deciding to' does not imply commitment, you have larger
> problems then choosing a technology.[/color]

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.
[color=blue]
> Never trust an advocate who knows nothing about the thing (s)he
> advocates.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
>From what I have gathered, our first impulse to use Java was probably[/color]
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

**cartercc@gmail.com** · Jan 3 '06, 04:55 PM

Re: application and web app technologies

> It might help if you elaborated on what these "doubts" are. It doesn't sound[color=blue]
> 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.[/color]

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.'
[color=blue]
> 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?).[/color]

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

**Matt Garrish** · Jan 3 '06, 06:35 PM

Re: application and web app technologies

<cartercc@gmail .com> wrote in message
news:1136306578 .271826.302110@ g44g2000cwa.goo glegroups.com.. .[color=blue][color=green]
>> 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.[/color]
>
> 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.'
>[/color]

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!
[color=blue][color=green]
>> 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?).[/color]
>
> 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.[/color]

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

**ccc** · Jan 3 '06, 09:45 PM

Re: application and web app technologies

> If no one knows the language[color=blue]
> 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?[/color]

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.
[color=blue]
> If you let
> programmers build their own little universes they will![/color]

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.
[color=blue]
> 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.[/color]

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

**Harpo** · Jan 3 '06, 11:55 PM

Re: application and web app technologies

ccc wrote:
[color=blue]
>
> We don't have any 'programmers' on staff. At most, we have several
> people writing, maybe, two hours of code a week,[/color]

Fine !
[color=blue]
> 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.[/color]

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

**l v** · Jan 4 '06, 03:35 AM

Re: application and web app technologies

ccc wrote:[color=blue]
> [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.[/color]

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.
[color=blue]
>
> 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.[/color]

Ah, one language fits all. Perhaps OO COBOL should be considered. :)
[color=blue]
>
> Actually, Java was a pretty easy decision to make, since we already had
> a problem with Perl, [snip][/color]

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

**Juha Laiho** · Jan 6 '06, 07:05 AM

Re: application and web app technologies

"ccc" <cartercc@gmail .com> said:[color=blue]
>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.[/color]

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.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

application and web app technologies

application and web app technologies

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment