Project: in Ruby, Perl?

[Zach Dennis]

Hi,

We've got a small project coming up at work that will deal with a MySQL
database. It will be a small scale inventory management and
production/purchase order management system. We are trying to decide what
language to write it in. We have ruled out Java, C, C++, anything .NET and
Python. We have Ruby and Perl left on our list(although we may include C
extensions).

Much of the data and transactions can be conceived to be very OO, which is
why I picked Ruby. Another fellow on my team though feels that since Perl is
older then Ruby and has OO ability that it is better to use because there
are more books, documentation, etc....(in English).

The system will need to deal with different types of Queues and Threads
since it will spawn across 2 servers and have multiple users on multiple
workstations. It will also need to eventually interact with UPC Scanners.

Any particular reasons why or why not Ruby or Perl? We have a small list of
pros and cons, but I thought I might get some more insightful answers here.

Thanks,

Zach

 

[Phil Tomson]

Hi,

We've got a small project coming up at work that will deal with a MySQL
database. It will be a small scale inventory management and
production/purchase order management system. We are trying to decide what
language to write it in. We have ruled out Java, C, C++, anything .NET and
Python. We have Ruby and Perl left on our list(although we may include C
extensions).

Much of the data and transactions can be conceived to be very OO, which is
why I picked Ruby. Another fellow on my team though feels that since Perl is
older then Ruby and has OO ability that it is better to use because there
are more books, documentation, etc....(in English).

Sure you can do OO Perl... you could probably do OO Assembly too if your
pain tolerance is high enough.

Turns out that OOPerl tends to run slower than Ruby, so if you're planning
to do the project in an OO style, you should keep that in mind.
(of course, procedural Perl is faster than Ruby in general).

The system will need to deal with different types of Queues and Threads
since it will spawn across 2 servers and have multiple users on multiple
workstations. It will also need to eventually interact with UPC Scanners.

Any particular reasons why or why not Ruby or Perl? We have a small list of
pros and cons, but I thought I might get some more insightful answers here.

I can only give you my experience in moving from Perl to Ruby (which for
me happened in early 2001): We were developing a distributed test system
that also needed to run on several machines (similar to your requirement).
I started out in OO Perl, but soon I decided that the code-base was just
becoming unwieldly cumbersome. I looked at Ruby and within a couple of
weeks of getting the pickaxe book, I was more productive in Ruby than I
had been in Perl (and I had programmed primarily in Perl for several
years). (drb helped a lot with that project as well, you might want to
look into it.)

Perl as it is now has had it's day and now is starting to look a bit
too old. I wouldn't recommend Perl for any real production system at
this point when there are much better alternatives available now (and I
used to be a big fan of Perl). Perl6 may change my mind, but it's still
vaporware at this point.

I think the main advantages Ruby offers over Perl are in the following areas:
1) Maintainability (and readability): It's nice to come back to your code
six months later and have a good idea of what you were trying to do
and what you were thinking back when you wrote it. One of the things
that annoyed me the most about Perl readability was that you couldn't
tell what arguments a function took just by quickly glancing at the code
since they pass arguments via the @_ array. You had to look through
the whole function to see what was being shifted off of @_.
2) Real support for OO with a very nice Smalltalk-like model. OO is not a
do-it-yourself, ad-hoc afterthought as it is with Perl.
3) enhanced productivity (in my experience, anyway, YMMV).
4) very easy to write C extensions for Ruby. (to be fair, this has
improved for Perl as well since the Inline modules have become
available)

Sure, Ruby's RAA isn't as large as Perl's CPAN, but you'll find a lot more
functionality built-in to Ruby's libraries than you will in Perl - for
example, look at all of the built in functions for arrays in Ruby vs.
Perl - so you'll find yourself reaching outside for special libraries less
often than you need to with Perl.

Perl was great in it's day (5 to 10 years ago), but times have changed.

Phil

 

[Robert Klemme]

Hi,

We've got a small project coming up at work that will deal with a MySQL
database. It will be a small scale inventory management and
production/purchase order management system. We are trying to decide what
language to write it in. We have ruled out Java, C, C++, anything .NET and
Python. We have Ruby and Perl left on our list(although we may include C
extensions).

Much of the data and transactions can be conceived to be very OO, which is
why I picked Ruby. Another fellow on my team though feels that since Perl is
older then Ruby and has OO ability that it is better to use because there
are more books, documentation, etc....(in English).

The system will need to deal with different types of Queues and Threads
since it will spawn across 2 servers and have multiple users on multiple
workstations. It will also need to eventually interact with UPC Scanners.

Any particular reasons why or why not Ruby or Perl? We have a small list of
pros and cons, but I thought I might get some more insightful answers

here.

+ more readable, cleaner syntax
+ much cleaner OO
+ code is usually smaller (less typing => less errors)
+ thread support

- performance in some regions
- amount of tested and working code (RAA vs. CPAN)

I'd choose Ruby.

Regards

robert

 

[Louis M]

Hi,

We've got a small project coming up at work that will deal with a MySQL
database. It will be a small scale inventory management and
production/purchase order management system. We are trying to decide what
language to write it in. We have ruled out Java, C, C++, anything .NET and
Python. We have Ruby and Perl left on our list(although we may include C
extensions).

Much of the data and transactions can be conceived to be very OO, which is
why I picked Ruby. Another fellow on my team though feels that since Perl is
older then Ruby and has OO ability that it is better to use because there
are more books, documentation, etc....(in English).

The system will need to deal with different types of Queues and Threads
since it will spawn across 2 servers and have multiple users on multiple
workstations. It will also need to eventually interact with UPC Scanners.

Any particular reasons why or why not Ruby or Perl? We have a small list of
pros and cons, but I thought I might get some more insightful answers here.

Thanks,

Zach

Why have you ruled out J2EE? All the concurrency and transaction and
security features you need are built into the application server.

 

[Lothar Scholz]

Hello Phil,

Thursday, January 29, 2004, 6:09:56 AM, you wrote:


PT> 2) Real support for OO with a very nice Smalltalk-like model. OO is not a
PT> do-it-yourself, ad-hoc afterthought as it is with Perl.

As far as i know the complete OO System will be rewritten in an
incompatible way which is not so bad because only a few people seem to
use OO Perl at the moment because of it problems.

PT> 3) enhanced productivity (in my experience, anyway, YMMV).
PT> 4) very easy to write C extensions for Ruby. (to be fair, this has
PT> improved for Perl as well since the Inline modules have become
PT> available)

Have you ever looked at C extensions in the past. They are much much
more readable and easier to write then a Ruby extension. I mean not
only 100% but a factor 10 easier.

PT> Sure, Ruby's RAA isn't as large as Perl's CPAN, but you'll find a lot more
PT> functionality built-in to Ruby's libraries than you will in Perl - for
PT> example, look at all of the built in functions for arrays in Ruby vs.
PT> Perl - so you'll find yourself reaching outside for special libraries less
PT> often than you need to with Perl.

I tried to use the NNTP module some time ago. This is so terrible
buggy and a lot of others ruby modules are of the same bad quality.
First it should work alright, then elegance comes in.

PT> Perl was great in it's day (5 to 10 years ago), but times have changed.

That's true. But i would count on python more then on ruby.

 

[Peter Hickman]

Turns out that OOPerl tends to run slower than Ruby, so if you're planning
to do the project in an OO style, you should keep that in mind.

We do all our work in OO Perl and I can't say that it has ever been a
problem. There will always be a trade off between ease of use and raw
speed. But we have a lot of code to maintain and the ease of use ticket
wins every time.

Perl as it is now has had it's day and now is starting to look a bit
too old. I wouldn't recommend Perl for any real production system at
this point when there are much better alternatives available now (and I
used to be a big fan of Perl). Perl6 may change my mind, but it's still
vaporware at this point.

What does 'starting to look a bit too old' actually mean. Perl is used
in many production systems and will continue to be used because it is
good at getting the job done. Maybe familiarity has bred contempt for
you but Perl can do almost anything, the rather modern field of
bioinformatics has benefited greatly from using Perl. Whats 'too old'
got to do with it?

I think the main advantages Ruby offers over Perl are in the following areas:
1) Maintainability (and readability): It's nice to come back to your code
six months later and have a good idea of what you were trying to do
and what you were thinking back when you wrote it.

I just went back to a four year old program of mine, it still works and
I manages to extend it with little difficulty despite having not seen it
for four years (the danger of putting your code out on the web).

One of the things
that annoyed me the most about Perl readability was that you couldn't
tell what arguments a function took just by quickly glancing at the code
since they pass arguments via the @_ array. You had to look through
the whole function to see what was being shifted off of @_.

Bad code is hard to read regardless of what language you use, ruby will
not save you from writing bad code.

Perl was great in it's day (5 to 10 years ago), but times have changed.

Perl has changed too, and it will continue to do so. Please stay seated
until the ride is over.

 

[Florian Gross]

Hi,
Moin!

Any particular reasons why or why not Ruby or Perl? We have a small list of
pros and cons, but I thought I might get some more insightful answers here.

When doing OOP in Perl, you have to do mostly everything yourself. (Just
take a look at constructors or methods calling overridden ones when
multiple inheritance is used.) Added user complexity aside this this
would theoretically give you more power, but Ruby's model is composed of
so simple and general rules that you can practically do everything you
could do in Perl.

Another thing worth noting is that all of Perl's built-ins aren't real
objects while in Ruby everything really is an object. (It will be hard
to add methods to numbers, strings or arrays in Perl.)

I've also felt that Perl projects get way harder to maintain after time.
I have the feeling that I can't refactor Perl code as Ruby code.

Oh, and references in Perl are one thing that was done way to complex.
Why isn't it possible to return an Array from a sub? When do you use
('a', 'b') and when ['a', 'b']? Would you want to use references for
complex structures? Will not using or using references get you into
trouble when doing serialization? What about dereferencing complex
things? Do you really want that? (This is the main reason of me
replacing Perl with Ruby as my primary programming language.)

There are also lots of smaller reasons like -> not looking as nice as .,
Ruby having setter and getter methods that look just like variable
getting and setting, and more stuff like this.

Just a few opinion pieces. Remember: This is all subjective!

Thanks,
Zach

Regards,
Florian Gross

 

[Alan Chen]

Any particular reasons why or why not Ruby or Perl? We have a small list of
pros and cons, but I thought I might get some more insightful answers here.

With an eye towards long term maintenance, the standard Ruby
distribution is a lot smaller than a standard Perl dist. That makes it
easier to install or build a custom production version, easier to
archive, and you have a hope understanding it should you need to go
digging into the depths to solve some issue.

 

[Rasputin]

Why have you ruled out J2EE? All the concurrency and transaction and
security features you need are built into the application server.

Unfortunately, so are a lot of features you *dont* need.
Many J2EE shops I've seen seem to be 90% scaffolding, and 10% useful
code (imo).

 

[Peter Hickman]

With an eye towards long term maintenance, the standard Ruby
distribution is a lot smaller than a standard Perl dist. That makes it
easier to install or build a custom production version, easier to
archive, and you have a hope understanding it should you need to go
digging into the depths to solve some issue.

This is also a con. Perl has lots of prewritten modules that will save
you a great deal of work.

Need to validate an email address Email::Validate, need to check Country
names Locale::Country, multipart email MIME::Lite, the list goes on.
This is not to say that Ruby cannot do these things or that Ruby has no
modules just that Perl has a lot of them. You can write quite
significant amounts of functionality by downloading stuff from CPAN.

Of course if you don't need these modules then things become more equal,
but if you are going to need these things then you have to ask yourself
if you are willing to write virtually everything your require from
scratch or do you just want to download it?

From a commercial perspective CPAN is a big plus for Perl.
From a coding point of view writting everything from scratch is a much
more fun (for some value of fun).