Re: Ruby Before Perl? Nah.
by rovf (Priest) on Jun 04, 2008 at 08:09 UTC
|
Having done projects in Ruby and in Perl as well, maybe I can contribute a few personal impressions:
In both languages one can see the intent of the authors to make it practical to use. Larry and Matz both seem to prefer writing short, concise code over long winded ones (as you maybe would end up when using Java).
In both languages you find obscure and dark corners, but the ugly parts of Ruby are very different from the ugly parts of Perl. This comes to no surprise, as Matz, when inventing Ruby, had a deep Perl background and tried specifically to avoid the weaknesses of Perl.
Also, as always, what is ugly for me might be great for others. I dislike the Ruby feature to make it easy to define aliases for functions (where you can call the very same function by a variety of names), but others find it handy.
When it comes to writing programs (as opposed to reading them) I found both Perl and Ruby easy to learn. You come quickly to a point where you can produce useful code. In this respect, I find Ruby a bit easier, but this too is just my personal impression.
And, if you came (like me) from Perl to Ruby, you will feel familiar with many standard modules (Net::FTP etc.), because their design is patterned after their Perl equivalent.
I enjoy working with various languages. When I do shell scripting, I like to use both bash and zsh. When I do serious programming, I like to do both Perl and Ruby. I would be interested in doing somethin in Python, or Haskell, too. If you are like me in this respect, it might be worth giving Ruby a try...
--
Ronald Fischer <ynnor@mm.st>
| [reply] |
Re: Ruby Before Perl? Nah.
by Fletch (Bishop) on Jun 03, 2008 at 21:57 UTC
|
As to the lack of sigils and arrays and hashes both being indexed with square brackets, that gets more into the Ruby tendency to favour interface polymorphism (or as it's often referred to, "duck typing"). So long as what you're calling the [] method on responds to that method, everything is hunky-dory and it allows for some nice flexibility. I think the example given in one of the books was code which was using a string IO instance with << to build up something for output and the temporary objects were killing performance; they swapped to passing in an array which also groks << (and then called join afterwards once) and the app went from terrible multiuser performance back to acceptable (or something along those lines).
Not that this approach doesn't also have issues (e.g. you call method zorch expecting the object to do foo, but instead it does bar and wipes your hard drive . . .), but there is a rationale behind it.
And also there is a more traditional looking for loop, but it's really (mostly) syntactic sugar for calling each:
for var in iteratable
puts "Frobnicated: #{var.frobnicate}"
end
## is pretty much just the same as this . . .
iteratable.each { |var| puts "Frobnicated: #{var.frobnicate}" }
But really that's like persisting to use C-style loops in Perl . . . :)
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply] [d/l] [select] |
|
Not that this approach doesn't also have issues (e.g. you call method zorch expecting the object to do foo, but instead it does bar and wipes your hard drive . . .), but there is a rationale behind it. I'm used to seeing posts like this explaining Ruby's object system when it's being contrasted to C++ or Java, but is this really noticably different from Perl's OO system? How does foo.zorch in Ruby differ from $foo->zorch in Perl? If it looks like duck typing and quacks like duck typing... ;) Indeed, I believe we could use Perl's OO support and operator overloading to do exactly the same things as Ruby does, right down to accessing arrays and hashes with the same kinds of bracket. The reason we don't is twofold:
- Abstraction on the "everything is an object" scale is inefficient. Perl hackers prefer to save it for where it makes their code easier to read and write, instead of religiously abstracting everything just because we can.
- Code is more maintainable when different things look different. Arrays and hashes have very different semantics.
| [reply] [d/l] [select] |
|
Good points.
The wikipedia article I referenced says "Perl's runtime method call mechanism naturally supports duck typing.". The thing is I think people writing Perl don't tend to think "the duck typing way" (if one might posit such a thing) to the extreme that Ruby encourages it. Not to mention that if you really want to in Ruby you can individually override / extend a single instance at runtime to implement an interface if need be (of course with Moose and friends you can do similar in Perl, so . . . ).
And yes, there's overhead to the smalltalkesque everything's-an-object everything's-done-sending-messages model. Ruby's still got speed issues, but it's still got lots of elegant points. I'll often whip first passes of CSV munging together using Ruport because Ruport::Data::Table allows some really succinct code; if speed's an issue then it's time to drop back to Text::CSV_XS or Tie::Handle::CSV.
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply] |
|
Re: Ruby Before Perl? Nah.
by kyle (Abbot) on Jun 03, 2008 at 20:26 UTC
|
Have you, by chance, put this up at a Ruby-focused site? I'd be interested to read comments on it from entrenched Ruby folks.
In any case, thanks for sharing. I haven't ventured outside Perl much since PHP, but if I were going to explore for the sake of exploring, I might sally forth into Ruby territory. I appreciate your scouting.
On the topic of variable appearance: I've been thinking for a while that Perl's references obscure the old useful sigils. That's just my hobby horse, however.
| [reply] |
|
Have you, by chance, put this up at a Ruby-focused site? I'd be interested to read comments on it from entrenched Ruby folks.
I would be too... my (brief) encounters with the Ruby community so far have only turned up rampant fanboi-ism. Actually, it's one of the things that's put me off pursuing Ruby further. I'm sure it's just a case of bad luck, altho I do suspect that the average Rubyite is a bit more defensive than the averager Perler (I think Perl coders are just used to abuse nowadays). Would be interesting to compare the quality of responses to a post on a Ruby site to those on this site (which are all excellent so far).
| [reply] |
|
| [reply] |
|
It won't trigger any interest in Perl among Rubist. You won't be able to trigger any interest of Hillary among Obama supporters. See what's going on? Generation differences.
| [reply] |
|
Triggering interest would be nice, but mostly I was asking out of my own interest, already triggered. Much like other subjects (including politics), I find it interesting to read the perspectives of those who hold opinions different from my own. How do the Rubists "hear" the opinions of the Perl folks who've visited? How do they view those same features themselves? With enough discussion, sometimes it's even possible to trace opinions back to the core values that support them. That is interesting—more interesting than Ruby is to me, and probably more interesting than Perl is to a Rubist.
| [reply] |
Re: Ruby Before Perl? Nah.
by Jenda (Abbot) on Jun 04, 2008 at 00:17 UTC
|
I don't mind that you don't have different sigils for scalars, arrays and hashes (the number of characters is rather restricted compared to the number of different types you might want to distinguish like that), what I do mind is that there are no sigils at all which combined with the fact that you CAN'T declare variables is rather ... nice.
In Perl I can say HEY DUDE THIS IS A NEW VARIABLE no matter what variables exist elsewhere. In Ruby you can't and the usual response of faithful Rubyists is that it doesn't matter because all methods should be at most up to five lines anyway. Which 1. is not always possible and 2. forces you to be very inventive when nameing them. Plus due to the missing sigil it's not just variables that can clash. So you may define something several months later several pages away and voila, your local variable is no longer local variable. If you are lucky it's not a variable at all and you use it in some way that'll cause a syntax error. Oh, I forgot, you are supposed to have tests for everything so nothing bad can happen anyway right? I don't need the seatbelts, I'm a good driver, right?
| [reply] |
Re: Ruby Before Perl? Nah.
by starbolin (Hermit) on Jun 03, 2008 at 21:08 UTC
|
Thanks for a well written and balanced treatment. ++
Question: Perl OO being blessed references gives preference to creating HAS-A relationships whereas Ruby's 'everything is an object' should gives preference to creating IS-A relationships. Did you find this to be true? In other words, theory says that Inheritance should be cleaner in Ruby while Aggregation should be cleaner in Perl. For myself, I don't have any experience with Ruby so I would appreciate any insight you can give.
s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s
|-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,,
$|=1,select$,,$,,$,,1e-1;print;redo}
| [reply] |
|
Short answer: yes.
Slightly more long winded answer: Inheritance in Ruby is a perfectly natural thing to do from the Java OOP's perspective. The syntax is different, of course, but the fundamentals of non-multiple inheritance remain the same. There are Java-like interfaces available to fake multiple inheritance, but the project I was working on wasn't complicated enough to need them.
After reading your post, I think I understand *why* I've found OO in Perl to be as cumbersome as I have; I have a tendency to think about objects in ISA terms. For what it's worth, the initial specs for the project were looking at modeling from a HASA perspective (a top down approach). This quickly proved cumbersome, and it made more sense to look at it from the ISA perspective, which is a lot more bottom up.
I can't say if this speaks more to my personality or my programming ability than it does to the nature of the language though. I'm sure modeling the HASA relationships would have been easier to do if I had more of a background in UML or Perl OO rather than Java, but the inheritance features of Ruby certainly make ISA modeling straightforward and easy to do.
Hope I managed to give you an intelligent answer somewhere in there :)
| [reply] |
Re: Ruby Before Perl? Nah.
by MistaMuShu (Beadle) on Jun 03, 2008 at 23:43 UTC
|
Just a small typo in "Appearance of Variables". In Ruby, @ signifies an instance variable and @@ signifies a class variable. Switching between Perl and Ruby often makes me mistype '@' for array :)
I definitely agree with the community support. PerlMonks is by far the most helpful and best moderated site I've seen. I feel that the popularity of Rails has attracted fanboys and flamers who are detrimental to Ruby's image. I try to stay out of the "I'm better than you" arguments.
What impresses me most is Ruby's metaprogramming support. I don't know that many languages, but Ruby is the first one that I've seen it so well integrated into the syntax and language. It's not cumbersome to use, and is widely used in Rails and other libraries.
| [reply] |
Re: Ruby Before Perl? Nah.
by samizdat (Vicar) on Jun 04, 2008 at 13:10 UTC
|
| [reply] |
Re: Ruby Before Perl? Nah.
by stvn (Monsignor) on Jun 04, 2008 at 07:07 UTC
|
| [reply] |
|
| [reply] |
|
Take a look at http://www.iinteractive.com/moose/ in the "articles" section are two nice Linux Mag articles that merlyn wrote, and an interesting comparison of Moose to Ruby by Barry Walsh. You might also want to look in the "presentation" section as well, some of the talks are kind of tutorial-ish. And if you are going to YAPC::NA this year in Chicago I will be giving a tutorial on Moose there this year. And lastly, if you are on IRC, feel free to stop by #moose on irc.perl.org the community there is pretty helpful.
| [reply] |
Re: Ruby Before Perl? Nah.
by educated_foo (Vicar) on Jun 04, 2008 at 02:58 UTC
|
There is no CRAN, and there are no Ruby Monks. That's not to say that Ruby doesn't have it's own module system (rubygems.org), but it's nowhere near as robust as CPAN.
The real turd here is that gems isn't just a package repository, but is required at runtime in your script, and imposes significant overhead. It amazes me that Ruby has adopted it.
| [reply] |
Re: Ruby Before Perl? Nah.
by almut (Canon) on Jun 03, 2008 at 21:15 UTC
|
There is no CRAN
Actually, there is ... but it's something else :)
| [reply] |
Re: Ruby Before Perl? Nah.
by bilfurd (Hermit) on Jun 04, 2008 at 08:32 UTC
|
Ruby does take some getting used to. "Rails" is pretty slick, though the differences between v1.x and v2.x are enough to drive you mad. The "objectiness" of the language has a certain charm. A different feel to the language, if that makes any sense.
The lack of sigils and line terminators does bug me, though I can get into the groove after a while.
I'm just glad they Mats didn't follow Guido with the whitespace...
When all is said and done, Ruby does not have a Perl Monks. Until there is an established, non-fanboy "Ruby Monks", it will be a lot easier to get things done with Perl. | [reply] |
Re: Ruby Before Perl? Nah.
by Your Mother (Archbishop) on Jun 04, 2008 at 18:32 UTC
|
This is, I think, a reflection of the relative maturity of Perl to Ruby. With a decades long head-start, Perl...
To clarify, Perl was released 1987, Ruby 1995. 8 years does not decades, or even decade, make. To a large degree, Perl's maturity is an outgrowth of its incredibly broad usefulness. It fits into so many problem spaces that its user base brought a tacit maturity almost from the beginning.
| [reply] |
|
3 months in human years = 1 year in computer years?
Or alternatively, by decades I meant cumulative hours of development time?
No, just had the date wrong. Thank you for the correction :)
| [reply] |
Re: Ruby Before Perl? Nah.
by bart (Canon) on Jun 09, 2008 at 20:18 UTC
|
Ruby, Perl, Python...
Those are all the usual suspects.
And despite their differences, I still feel that they're actually more alike than different.
Are there any other languages, that are usable in the same way as Perl/Python/Ruby, that you consider interesting as alternatives, but that are not (constantly) in the spotlight, and that may be worth looking into?
| [reply] |
|
I've been meaning to take a look at Lua for a while now. It looks syntactically similar to Ruby, and is designed to be primarily an extension language for C/C++; but that's from a cursory examination of the manual. It's worth mentioning that there is also a Java interface available, and the same folks who produced that have developed a web application framework to support Lua. If it really is as fast as the hype indicates, maybe it's worth looking into. Otherwise, it's probably just another mouse trap.
| [reply] |
|
I looked at lua a few months ago, and this is what I found:
- It's a neat, small language
- Variables are global by default (like in perl), but no use strict
- The "A hash and an array are the same thing" concept really needs some time to adapt
- Simple things aren't always easy, hard things not always possible
Especially the second and the last point of that list convinced me not to adapt it as a general purpose programming language.
However for the area it was designed for (being embedded in other applications) it sure is very cool and useful.
| [reply] [d/l] |
Re: Ruby Before Perl? Nah.
by spurperl (Priest) on Jun 13, 2008 at 04:46 UTC
|
| [reply] |
Re: Ruby Before Perl? Nah.
by parv (Parson) on Jun 09, 2008 at 21:58 UTC
|
After reading the title "pearls before swine" jumped immediately in my mind. (Mind that I am not implying any relation(s) among Ruby|Perl and pearls|swine. I should rent an asbestos suit in any case.) | [reply] |