[lamontcg]

This almost reads more like a list of cruft which should be removed from the stdlib (obviously not benchmark.rb though). For delegation it is probably better to use forwardable and be explicit about delegated methods--delegate.rb smells like it uses method_missing magic.

[semiquaver]

You don't see much ruby anymore that uses `DelegateClass`, the primary interface to delegate.rb. It does use metaprogramming but no more than Forwardable does. Also, it's "the good kind" of metaprogramming: active at program boot only, not a whiff of method_missing. This is closer to a lisp or rust macro: code which writes code. Exactly what ruby excels at.

https://github.com/ruby/ruby/blob/afd46429fcdb83aa9fa7c193ed...

SimpleDelegator is still pretty common though, I wouldn't blink if I saw that while reviewing a PR.

[jacobsenscott]

I love method_missing - one simple method unlocks so much power and eliminates so much boiler plate.

[jdkoeck]

… and ruins the life of future maintainers, there’s a reason few languages tried to borrow features from ruby’s metaprogramming (saying this as a rubyist)

[sodapopcan]

Metaprogramming is powerful for making really nice, easy-to-use _libraries_. It shouldn't ever be used for business logic. Ever. Unless you're going to go all in and make a DSL for your business, but I don't know of anyone who actually does that.

[empthought]

Businesses are typically the ones hiring programmers (especially Ruby ones).

The smart programmers want to write libraries. This is actually a problem for businesses, because they often don't need libraries.

[sodapopcan]

I agree. That’s a whole blog post or essay worth of shit to unpack there, though.

[lamontcg]

method_missing is only one tool in the metaprogramming toolbox (just probably the worst one). i wouldn't necessarily throw out the whole toolbox, particularly with ruby.

[jacobsenscott]

Any language feature can be misused. But without it things that are easy and useful become hard.

[KerrAvon]

It really doesn’t have to. I believe this is from Smalltalk. Objective-C has something similar. It’s extremely powerful if used properly.

[phoronixrly]

I mean, no one's making you use this functionality, why should it be removed?

[jrockway]

Once things are in the standard library, they're basically impossible to remove, unless you want to break everyone's code and prevent them from updating.

If you're making a new programming language today, the standard library is a place where you should think very carefully about everything you add. Every programmer learning the language will have to be familiar with the standard library, so keeping it small is good. But too small, and programmers will always have to reach for third-party packages without maintenance or stability guarantees. For example, you don't want to have to choose among 5 different libraries to write and run unit tests; the language should define that and it should meet everyone's needs (or be extensible with a small third-party library).

I think the Rubys and the Perls of the world probably choose too much to add to the standard library, and that's where the comment you're replying to comes from. But, while it's easy to overdo the standard library, it's also bad if you underdo the standard library. Tough and sometimes under-considered aspect of language design.

[steve_gh]

Depends also on what you mean by the "Standard Library".

Back in the day Ruby had built in language features (e.g. Innumerable), and a standard library that was bundled into the distribution (e.g. GServer).

More recent versions of ruby have significantly streamlined the standard library, pushing a lot of the functionality into Gems (libraries). Given that the use of a Gemfile to list library dependencies is absolutely standard practice, the upgrade path simply involves adding a line to the Gemfile.

In practice, these changes have been very well signposted before they have happened.

[lamontcg]

This is a very good point. Things done wrong in the standard library are often done wrong permanently and forever. Particularly given the current demands from some people for perfect backwards compatibility.

Looking at the stdlib for a language like Rust it tends to feel like people who had 20+ years of experience in other languages went and thought deeply about the problem, with an understanding that accepting the design might be permanent.

[booleandilemma]

Not the parent, but my usual response to this is always "well someone's going to use it in the codebase, which means I'm going to have to end up using it too".

[lamontcg]

Yeah, code maintenance isn't actually free.