# Vimrc for Ruby or rubytidy **URL:** \ **Category:** ruby-talk\ **Created:** [29 January 2004 02:48 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906 "2004-01-29T02:48:38Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Ted\_Knab](https://avatars.discourse-cdn.com/v4/letter/t/e99b99/32.png) [@Ted\_Knab](https://rubytalk.org/u/Ted_Knab)\ **Post date:** [29 January 2004 02:48 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/1 "2004-01-29T02:48:38Z")
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 ? > **···** > > ## – > > ## Ted Knab Chester, MD 21619 > > 35570707f6274702478656021626f6c6964796f6e602f66602478656 > 02e6164796f6e60237471647560216e6460276c6f62616c60257e696 > 4797e2a0 ---
**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\ **Post date:** [29 January 2004 03:05 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/2 "2004-01-29T03:05:00Z")
> 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](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 ---
**Author:** ![Zach\_Dennis1](https://avatars.discourse-cdn.com/v4/letter/z/ea5d25/32.png) [@Zach\_Dennis1](https://rubytalk.org/u/Zach_Dennis1)\ **Post date:** [29 January 2004 03:25 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/3 "2004-01-29T03:25:53Z")
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 ---
**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\ **Post date:** [29 January 2004 03:27 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/4 "2004-01-29T03:27:16Z")
> > 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 ---
**Author:** ![Sam\_Roberts1](https://avatars.discourse-cdn.com/v4/letter/s/ed8c4c/32.png) [@Sam\_Roberts1](https://rubytalk.org/u/Sam_Roberts1)\ **Post date:** [29 January 2004 13:53 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/5 "2004-01-29T13:53:46Z")
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](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\](http://www.soyabean.com.au/gavin/vim/index.html%5C)). > > Thanks, > Sam ---
**Author:** ![Ted\_Knab](https://avatars.discourse-cdn.com/v4/letter/t/e99b99/32.png) [@Ted\_Knab](https://rubytalk.org/u/Ted_Knab)\ **Post date:** [29 January 2004 04:29 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/6 "2004-01-29T04:29:12Z")
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 > > ## – > > ## Ted Knab Chester, MD 21619 > > 35570707f6274702478656021626f6c6964796f6e602f66602478656 > 02e6164796f6e60237471647560216e6460276c6f62616c60257e696 > 4797e2a0 ---
**Author:** ![Ptkwt](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Ptkwt](https://rubytalk.org/u/Ptkwt)\ **Post date:** [29 January 2004 05:09 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/7 "2004-01-29T05:09:56Z")
In article [LLENJLJKHAOFKOLPKLAFGEKBCAAA.zdennis@mktec.com](mailto: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: 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 > **···** > > Zach Dennis [zdennis@mktec.com](mailto:zdennis@mktec.com) wrote: ---
**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\ **Post date:** [29 January 2004 08:19 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/8 "2004-01-29T08:19:54Z")
“Zach Dennis” [zdennis@mktec.com](mailto:zdennis@mktec.com) schrieb im Newsbeitrag [news:LLENJLJKHAOFKOLPKLAFGEKBCAAA.zdennis@mktec.com](mailto: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. - 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 ``` ---
**Author:** ![Louis\_M](https://avatars.discourse-cdn.com/v4/letter/l/d2c977/32.png) [@Louis\_M](https://rubytalk.org/u/Louis_M)\ **Post date:** [29 January 2004 12:00 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/9 "2004-01-29T12:00:05Z")
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. ---
**Author:** ![Kirk\_Haines](https://avatars.discourse-cdn.com/v4/letter/k/c6cbf5/32.png) [@Kirk\_Haines](https://rubytalk.org/u/Kirk_Haines)\ **Post date:** [29 January 2004 12:45 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/10 "2004-01-29T12:45:26Z")
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. ---
**Author:** ![Florian\_Gross](https://avatars.discourse-cdn.com/v4/letter/f/e9a140/32.png) [@Florian\_Gross](https://rubytalk.org/u/Florian_Gross)\ **Post date:** [29 January 2004 14:35 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/11 "2004-01-29T14:35:38Z")
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 ---
**Author:** ![Alan\_Chen1](https://avatars.discourse-cdn.com/v4/letter/a/b782af/32.png) [@Alan\_Chen1](https://rubytalk.org/u/Alan_Chen1)\ **Post date:** [29 January 2004 16:04 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/12 "2004-01-29T16:04:57Z")
“Zach Dennis” [zdennis@mktec.com](mailto:zdennis@mktec.com) wrote in message news:[LLENJLJKHAOFKOLPKLAFGEKBCAAA.zdennis@mktec.com](mailto: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. ---
**Author:** ![Lothar\_Scholz2](https://avatars.discourse-cdn.com/v4/letter/l/f14d63/32.png) [@Lothar\_Scholz2](https://rubytalk.org/u/Lothar_Scholz2)\ **Post date:** [29 January 2004 13:57 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/13 "2004-01-29T13:57:04Z")
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](mailto:mailinglists@scriptolutions).com ---
**Author:** ![Peter\_Hickman](https://avatars.discourse-cdn.com/v4/letter/p/ecd19e/32.png) [@Peter\_Hickman](https://rubytalk.org/u/Peter_Hickman)\ **Post date:** [29 January 2004 14:16 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/14 "2004-01-29T14:16:31Z")
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: > > 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. ---
**Author:** ![Zach\_Dennis1](https://avatars.discourse-cdn.com/v4/letter/z/ea5d25/32.png) [@Zach\_Dennis1](https://rubytalk.org/u/Zach_Dennis1)\ **Post date:** [29 January 2004 15:29 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/15 "2004-01-29T15:29:27Z")
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 ---
**Author:** ![Dick\_Davies1](https://avatars.discourse-cdn.com/v4/letter/d/22d042/32.png) [@Dick\_Davies1](https://rubytalk.org/u/Dick_Davies1)\ **Post date:** [29 January 2004 16:24 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/16 "2004-01-29T16:24:35Z")
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). ---
**Author:** ![Peter\_Hickman](https://avatars.discourse-cdn.com/v4/letter/p/ecd19e/32.png) [@Peter\_Hickman](https://rubytalk.org/u/Peter_Hickman)\ **Post date:** [29 January 2004 16:27 UTC](https://rubytalk.org/t/vimrc-for-ruby-or-rubytidy/9906/17 "2004-01-29T16:27:19Z")
Alan Chen wrote: > “Zach Dennis” [zdennis@mktec.com](mailto:zdennis@mktec.com) wrote in message news:[LLENJLJKHAOFKOLPKLAFGEKBCAAA.zdennis@mktec.com](mailto: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).