http://www.perlmonks.org?node_id=971611


in reply to Ruby vs Perl vs LISP; the killer feature lacking in Ruby

But there are killer features in Ruby. Plenty actually. Features that kill it, that is. Its cryptic error messages. Its fragile and incorrectly designed statements-end-on-newline-or-maybe-not and leading-whitespace-matters syntax. The names of almost all list related built-ins. The syntax sugar for methods accepting one block/closure - the syntax in itself is silly, but the worst thing is that it restricts you to just one such parameter unless you jump through hoops even most "seasoned" Ruby developers are not aware of. The cool and meaningless names of even the most basic libraries (guess, without looking, what's hpricot for!). The fact that not only you can't force yourself to declare variables, there's simply no way to declare one even if on a specific place you did want to be sure you are working with a new X ("hey, a method should have no more than five lines. There's no need to declare variables." - "Sorry, I've got five hundred methods already, I've run out of names!").

Jenda
Enoch was right!
Enjoy the last years of Rome.

  • Comment on Re: Ruby vs Perl vs LISP; the killer feature lacking in Ruby

Replies are listed 'Best First'.
Re^2: Ruby vs Perl vs LISP; the killer feature lacking in Ruby
by jdporter (Paladin) on May 21, 2012 at 14:00 UTC
    it restricts you to just one such parameter unless you jump through hoops even most "seasoned" Ruby developers are not aware of

    Is it easy to do this in Perl? It's not possible at all, afaik. 

    multifoo
    { $_ * 2 }
    { foo($_) }
    @things;

    [download]
    I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
[reply]
[d/l]

      As well as Jenda's suggestion, it's also possible to declare a little wrapper like this:

      sub also (&;@) {
  return @_;
}

      [download]

      Enabling you to do this:

      multifoo { $_ * 2 }
    also { foo($_) }
         @things;

      [download]

      This is what Moose does for its type constraints system, providing little wrappers like via, where and message so you can write code like:

      subtype 'ModernDateTime'
   => as 'DateTime'
   => where { $_->year() >= 1980 }
   => message { 'The date is not modern enough' };

      [download]
      perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
[reply]
[d/l]
[select]
      multifoo sub { $_ * 2}, sub { foo ($_) }, @things;

      [download]
      hoopsy hoops, right?

      And now the method body: 

      sub onefoo {
 my ($reasonably_named_sub, @params) = @_;
 whatever;
 for my $foo (tweaked @params) {
  $reasonably_named_sub->($foo);
 }
}

sub multifoo {
 my ($toDo, $filter, @params) = @_;
 whatever;
 for my $foo (grep $filter->(), tweaked @params) {
  $toDo->($foo);
 }
}

      [download]
      Yieieiaield anyone?

      There is a little syntactic sugar for functions (not methods) in Perl, but the difference between using the sugar and not is tiny. If I need to pass two "pieces of code" into my subroutine, I pass them, I name them and I call them the same way I would if I had just one.

      In Ruby, if your method gets a single block/closure parameter, you do not get to name the parameter, you use the ill-named statement yield and it kinda, behind the scenes, maybe, works. If you need to pass two you are, basically, screwed. But then 640KB ought to be ... I mean one block ought to be enough for anybody.

      Jenda
      Enoch was right!
      Enjoy the last years of Rome.

[reply]
[d/l]
[select]

In Section Meditations