Application and web app technologies

ruby-talk
1

<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

2

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

3

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

···

On Jan 3, 2006, at 17:47, cartercc@gmail.com wrote:

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

4

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.

···

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

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

5

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

···

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

6

<cartercc@gmail.com> wrote in message
news:1136306578.271826.302110@g44g2000cwa.googlegroups.com...

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

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!

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.

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

7

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

8

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

9

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.

···

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.

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

10

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

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

···

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

11

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

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

12

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

13

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

···

On Wed, 04 Jan 2006 00:47:22 +0100, Harpo <trashcan@hotmail.com>
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

14

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