Hacker News Reader

Comment by stevebmark | Hacker News Reader

This is a good reminder as to why Ruby is often called "the bad parts of Perl." I really appreciate other programming language ecosystems (almost any modern ones besides Ruby) that have abandoned things like this as bad practice, while Ruby continues to double down on it.

View on HN

That's funny, I usually hear Ruby referred to as "the good parts of Perl" (and Google searches for those phrases suggest the same[1]) -- there's no sigil conjugation, objects are first class, and there are fewer magic variables/idiomatic usages of magic variables. I agree with the author that 2.7's new block syntax is a step in the wrong direction (and that safe navigation/method reference are a little uglier than they need to be), but I think Ruby has otherwise done an exceptionally good job of taking the best parts of Perl and combining them with the best parts of Smalltalk.

[1]: I only get 1 Google result for "the bad parts of perl" and about 1000 for "the good parts of perl".

I definitely see Ruby as Perl's spiritual successor. I would say it's one of the few languages other than Perl that can be considered "write optimized". Ruby makes it very very easy to just write code that just works. Just, a lot of code later you have huge monstrosity of rot that's almost impossible to maintain; I think that happens with all large codebases, Ruby just gets there faster.

> I definitely see Ruby as Perl's spiritual successor.

Matz has said this himself:

* "I chose the name of the language from the jewel name, influenced by Perl. Although I named Ruby rather by coincidence, I later realized that ruby comes right after pearl in several situations, including birthstones (pearl for June, ruby for July) and font sizes (Perl is 5-point, Ruby is 5.5-point). I thought that it only made sense to use Ruby as a name for a scripting language that was newer (and, hopefully, better) than Perl." (https://lingualeo.com/tr/jungle/231625)

* "Ruby inherited the Perl philosophy of having more than one way to do the same thing. I inherited that philosophy from Larry Wall, who is my hero actually." (https://www.artima.com/intv/ruby3.html)

You have a huge monstrosity if you or someone on your team is sloppy. I guess you’ve never seen a Drupal or Joomla codebase before. Or JavaScript projects that pull a myriad of junk dependencies. We have a Perl codebase which is actually quite clean. Mojolicious also helps a lot to keep it nice and tidy.

"and there are fewer magic variables/idiomatic usages of magic variables"

...although that seems to be heading in Perl's direction, with the positional block argument variables convention.

One of the good parts of Perl that Matz embraced was TMTOWTDI.

https://en.m.wikipedia.org/wiki/There%27s_more_than_one_way_...

The author of this piece seems to simply disagree that this is a feature, and that's a widely held, not unreasonable position. But the described changes are just a further expression of that long held design philosophy.

Hm. Personally, I think there's a big difference between "there's more than one way to do it" and "there are some extra, esoterically unreadable ways to do it".

I definitely don't know enough to be questioning Matz's decisions, but the burden of backwards compatibility means there is a material cost to adding features that end up not getting widely adopted, and if that cost is not accepted by folks like Bozhidar (who must now update Rubocop to recognize this syntax), it gets passed on to the Ruby community in general, who must instead deal with a decaying and fragmented language ecosystem.

Things like this which they only just introduced and you didn't know about until this article?

I'd say the strongest possible interpretation of what stevebmark said would include older additions to the language such as from this section of the article:

---------

Here’s a list of changes and additions that I certainly never needed (or wanted): Ruby 1.9 hash literals Refinements %i literals Rational/Complex literals (2/3r, 2+1i) Endless ranges (1..) Safe navigation operator (&.)

I think what drstewart is getting at is the vagueness of stevebmark's claim:

> I really appreciate other programming language ecosystems... that have abandoned things like this

He doesn't articulate what "things like this" are, and instead leans on bbatsov's critique, though it's not clear how. It seems you're suggesting he means "the particular syntax additions bbatsov doesn't like," but that doesn't make sense, either—you're telling me he means that other language ecosystems have abandoned Ruby 1.9 hash literals, refinements, %i literals, etc.?

Reply on news.ycombinator.com