Does someone have a ‘.vimrc’ file they will share
that will help me keep my Ruby code all cleanly organized ?
When I programmed in Perl, I was highly addicted to perltidy.
Has anyone wrote a rubytidy ?
35570707f6274702478656021626f6c6964796f6e602f66602478656
02e6164796f6e60237471647560216e6460276c6f62616c60257e696
4797e2a0
Does someone have a ‘.vimrc’ file they will share
that will help me keep my Ruby code all cleanly organized ?
Look in VimExtensions and VimRubySupport in the Ruby Wiki. Then reply to
this thread and summarize what you’ve learned and what information you
think would be valuable. I’d like to gather as much helpful information
in http://vim-ruby.rubyforge.org as I can.
I’m not sure what you mean by “all cleanly organized” though.
When I programmed in Perl, I was highly addicted to perltidy.
Has anyone wrote a rubytidy ?
Never heard of perltidy. I’ll Google it sometime.
Some Vim settings I use for Ruby:
set ts=2 sts=2 et ai tw=95
set fo+=ro
And a bunch of mappings you’d probably be interested in but I don’t have
them handy and can’t remember them and they’re probably on the Wiki
anyway.
Cheers,
Gavin
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
When I programmed in Perl, I was highly addicted to perltidy.
Has anyone wrote a rubytidy ?Never heard of perltidy. I’ll Google it sometime.
Having done that, I’ll say that: (a) perltidy looks extremely useful; (b)
no rubytidy exists AFAIK; (c) I’ve proposed such a program for Ruby in the
past, believing that to be better than editor-dependent solutions.
I’m taking a look at perltidy to see if it can be adapted. Low
expectations…
Cheers,
Gavin
Quoteing gsinclair@soyabean.com.au, on Thu, Jan 29, 2004 at 12:05:00PM +0900:
> Does someone have a '.vimrc' file they will share
> that will help me keep my Ruby code all cleanly organized ?Look in VimExtensions and VimRubySupport in the Ruby Wiki. Then reply to
this thread and summarize what you've learned and what information you
think would be valuable. I'd like to gather as much helpful information
in http://vim-ruby.rubyforge.org as I can.
I had a problem with autoindenting yesterday. I had code like:
--------
class Bar
class Foo
def hi
end
=begin
a long comment
=end
def bye
end
end
end
-----
That's the way it was forced to look, every time used "=" to reindent
bye, everything after the =end was pushed to the margin. Frustrating!
Any idea why this is? If you can't reproduce, I'll provide the actual
code.
I'm using rcs version 1.11 of vim.indent, perhaps there is a newer, but
the URL in vim.indent isn't valid anymore
(http://www.soyabean.com.au/gavin/vim/index.html\).
Thanks,
Sam
Readability and re-usability will be better with Ruby.
I lump Perl, Python, and Ruby into the same class of interpreted
languages. However, I don’t like Python because I find the
‘white space’ in it too restrictive. Perl is good, but after using
it for over two years I feel as if I find Perl a little
frustrating. Perl is like learning a Foreign language.
Right when you think you mastered the foreign language, you find
that there are dialects that you can not understand. PERL has too
many dialects. Languages evolve, but PERL has went through many
transformations. I feel there are too many exceptions and syntax
variations in PERL.
As for object oriented code support, I think Larry Wall added that late.
I do not think that PERL was originally designed to be an OO programming
language. Both Ruby and Python seem to be better designed for OO coding.
Also Ruby and Python seem to work with C extensions. Perl does not last
time I used it.
As for your programmers, I feel they will get more satisfaction out of
programming in Ruby than in PERL. If you had the money to test three
teams, the Ruby team would be the happiest and create the most reusable code, the
Python team would be happy but slower, the Perl team would create code
at the same rate as the Ruby people but only they would understand it.
With that Perl and Python will have a large following for many years.
They are entrenched programmers. However, in near future more will learn
Ruby for the same reasons I did. Eventually, Ruby will dominate the
OO interpreted languages until something better comes out.
On 29/01/04 12:25 +0900, Zach Dennis wrote:
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
35570707f6274702478656021626f6c6964796f6e602f66602478656
02e6164796f6e60237471647560216e6460276c6f62616c60257e696
4797e2a0
In article LLENJLJKHAOFKOLPKLAFGEKBCAAA.zdennis@mktec.com,
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:
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
Zach Dennis zdennis@mktec.com wrote:
“Zach Dennis” zdennis@mktec.com schrieb im Newsbeitrag
news:LLENJLJKHAOFKOLPKLAFGEKBCAAA.zdennis@mktec.com…
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.
I’d choose Ruby.
Regards
robert
Zach Dennis wrote:
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.
As a guy who made his living with writing lots and lots and lots of Perl
from about 1994 to 2002, I’ll give you my reason why I don’t use it much
anymore.
Ruby is cleaner, easier, less stressful, and faster for me to develop in
than Perl. I’m nowhere near as knowledgable about the ins and outs of
Ruby, yet, the way that I was about Perl, but even early on when I was
always looking things up my code came together faster and with fewer
errors and much greater readability than it did with Perl. So it was an
easy switch for me. The cons regarding the in some cases less than
plentifully accessible documentation and the less mature stable of
contributed code, for me, is secondary to the fact that I can get more
done in less time more easily and with greater readability in Ruby than I
can in Perl.
Matter of fact, the only place where I regularly use Perl anymore is when
maintaining some legacy code that was written in Perl (but which is going
to be replaced by a new version of the software written in Ruby and using
Iowa) and when I do the following sort of thing:
perl -p -i -e ‘s{foo}{bar}g’ *
Just because the pattern is entrenched in my head as one my fingers pound
out almost automatically, and doing that in Ruby just to use Ruby doesn’t
really get me any of the pros that are the reason why I use Ruby most of
the time.
Kirk Haines
On Thu, 29 Jan 2004, Zach Dennis wrote:
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.
Zach Dennis wrote:
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
“Zach Dennis” zdennis@mktec.com wrote in message news:LLENJLJKHAOFKOLPKLAFGEKBCAAA.zdennis@mktec.com…
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.
Hello Phil,
Thursday, January 29, 2004, 6:09:56 AM, you wrote:
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.
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.
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)
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.
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.
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.
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.
--
Best regards,
Lothar mailto:mailinglists@scriptolutions.com
Phil Tomson wrote:
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:
- 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.
Louis M wrote:
Why have you ruled out J2EE? All the concurrency and transaction and
security features you need are built into the application server.
Louis,
It’s nothing personal against Java as a language. The majority of our few
man team doesn’t like programming in Java and with the size and scale of
this project I dont’ feel that it is worth making them use Java. The list
was contrived by them and myself. And we’ve narrowed it done to the two
languages they’d prefer using. Perl & Ruby.
Zach
Louis M wrote:
Zach Dennis wrote:
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).
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).
Alan Chen wrote:
“Zach Dennis” zdennis@mktec.com wrote in message news:LLENJLJKHAOFKOLPKLAFGEKBCAAA.zdennis@mktec.com…
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.
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).