4 ms·

I was about to chime in Perl but I read down to this. I'm currently using Ruby now but my first step into hacking was Perl. So I have a soft spot for it. If Per

I was about to chime in Perl but I read down to this. I'm currently using Ruby now but my first step into hacking was Perl. So I have a soft spot for it. If Perl 6 can live up to it I will not have any qualms hacking in Perl again.

jaggederest 19y ago
Ruby is so perlesque if you use all the $ variables, it's almost a push.
- SwellJoe 19y ago
  True on the surface. But Ruby's everything-is-an-object is a big difference in the way you think when working in each of the languages. Ruby definitely guides you into an OOP mindset, while Perl leaves all paths open...I don't necessarily consider this a win, but it is a pretty big difference in the way one thinks, even if the syntax of Ruby is immediately comfortable to a Perl programmer. We almost never use OO in our Perl codebase, except where bolting on OO makes a lot of sense (specifically, the UI functions, some CPAN modules that have a more natural OO interface), but in the Ruby code I've written it's all objects and it never feels forced or bolted on. Partly, it's the tasks we're doing where functional programming makes more sense, and partly it's due to having a large codebase that pre-dates Perl 5. Oh, yeah, we also have a huge swath of disparate data being passed around amongst different systems and services, and it's very natural to pass them around as arrays and treat them similarly to lists in lisp. map, grep, shift/unshift, and pop/push get a lot of use in our code. I'm pretty certain we'd do it differently in Python and we'd probably do it differently in Ruby. It'd probably take quite a bit more code in either of those languages, but it might be more readable on first (and second) glance. Perl 6 will change some of our practices (in three or four years when Perl 6 is wide-spread, anyway), but not all of them. Objects will be beautiful in Perl 6, so we won't avoid them, and argument passing will be much cleaner (right now we pass around refs to arrays a lot, which is somewhat fragile when API changes happen), so those things will change, but our treatment of data will probably remain similar. So, I agree with you about Ruby syntax. It looks very similar, and is very comfortable to me, as a long time perl coder. But when you actually start building things, the comfortable paths diverge quite a bit.

jaggederest 19y ago

Ruby is so perlesque if you use all the $ variables, it's almost a push.

SwellJoe 19y ago
True on the surface. But Ruby's everything-is-an-object is a big difference in the way you think when working in each of the languages. Ruby definitely guides you into an OOP mindset, while Perl leaves all paths open...I don't necessarily consider this a win, but it is a pretty big difference in the way one thinks, even if the syntax of Ruby is immediately comfortable to a Perl programmer. We almost never use OO in our Perl codebase, except where bolting on OO makes a lot of sense (specifically, the UI functions, some CPAN modules that have a more natural OO interface), but in the Ruby code I've written it's all objects and it never feels forced or bolted on. Partly, it's the tasks we're doing where functional programming makes more sense, and partly it's due to having a large codebase that pre-dates Perl 5. Oh, yeah, we also have a huge swath of disparate data being passed around amongst different systems and services, and it's very natural to pass them around as arrays and treat them similarly to lists in lisp. map, grep, shift/unshift, and pop/push get a lot of use in our code. I'm pretty certain we'd do it differently in Python and we'd probably do it differently in Ruby. It'd probably take quite a bit more code in either of those languages, but it might be more readable on first (and second) glance. Perl 6 will change some of our practices (in three or four years when Perl 6 is wide-spread, anyway), but not all of them. Objects will be beautiful in Perl 6, so we won't avoid them, and argument passing will be much cleaner (right now we pass around refs to arrays a lot, which is somewhat fragile when API changes happen), so those things will change, but our treatment of data will probably remain similar. So, I agree with you about Ruby syntax. It looks very similar, and is very comfortable to me, as a long time perl coder. But when you actually start building things, the comfortable paths diverge quite a bit.