I'll take overloaded operators over overloaded functions any day of the week, and I also hate overloaded operators.

Python's optional typing has come a very long way in the past few years, you might be able to mitigate this with some creative application of typing.

Edit: I read your post closer, I'm not sure typing would help with the overloaded operator issue and now I have something fun to try out later 😁

Any good inline help would run dir into your variable and discover it overloads that operator. It's a fault of your tools.

Integers are just integers in ruby, with no structure backing them. They behave like objects, but only in some respects. You can call methods on them, but you can't extend individual numbers with properties for example (which would require them to have structure).

Complicated or not, the interfaces suck. And dont have to. And that's the problem.

Obligatory Tom Scott video

timedelta marks time in days, seconds, and microseconds. It doesn't take leap years into account because the concept of years is irrelevant to timedelta. If you need to account for leap years, you need a different API.

Because what's accurate here depends on the context, and the Python example doesn't hide that from the programmer.

The same dilemma goes for month calculations: does "3 months ago" mean 90 days ago, 91.3 days ago, this many days into the target month, or this many days from the target month's end (e.g. to account for 28, 29, 30, and 31-day months)?

The comparison is somewhat awkward, because the rails example presumably produces a date, while the python one is referring to an interval of time.
Just from the meme it's not obvious which was the actual intended use, so labeling either as inaccurate requires us to make assumptions.

Personally, the concept of "10 years ago" is a bit nebulous to me. If today is February 29th, is ten years ago March 1st? Doesn't seem right. Or particularly useful.

Does the Ruby version do that though?

I haven't got it installed to check, but seeing constants like SECONDS_PER_YEAR in the documentation makes me think it's just as bad if not worse.

https://api.rubyonrails.org/classes/ActiveSupport/Duration.html

I just started a new php gig

The handful of us have moved onto Crystal Lang. It's a statically type checked and compiled dialect of Ruby. Crystal is fun to write code, but the compiler is slower (compared to go-lang/rust)... because... well it's a ruby dialect (with DSL's)... and the 3rd party libraries are limited.

Yes

I had a coworker choose RoR for a major project despite the fact that he didn't know it, nobody on his team knew it, nobody at our company knew it, and nobody in the entire state knew it. It ended as one would expect, after three years and millions of dollars spent, with the only revenue it generated being $50K from the original client that had to be refunded to avoid a lawsuit.

You probably use it everyday and didn't know it https://github.blog/engineering/architecture-optimization/building-github-with-ruby-and-rails/

Never use numbers when calculating dates. Use the data formats and constants the calendar library provides.

365.2425

Sure, if you want things at midday instead of midnight.

Yeah its a rails only thing. Rubys biggest issue is its much too intelligent for its own good. Its implicit rather than pythons explicit. Most of the time. That and it's hard to find out where Ruby starts and rails ends.

That being said I made a ton of good money on rails back about 15 or so years ago. Still excellent for starting out.

You can add activesupport (I think that’s it) to get it if you don’t want to use all of rails.

Yeah that feels like the kind of smartass thing Python would do.

Rails, ActiveSupport I believe, adds this to integers.

But I think one of the interesting things about it is the open nature of classes in ruby.

The thing that makes it possible is that you can open classes in user space and just add stuff to them. It’s a neat feature that few languages have.

The feature, like most features, has pros and cons. On the pro side it makes making DSLs and helpers like this pretty trivial. You can make really expressive ideas and apis because you can change how things you didn’t write work.

On the con side, it’s harder to discover and the methods of an object being the result of runtime mixins can make things hard to reason about.

Having worked in both python and ruby and now elixir for the past couple of years, it’s interesting to see how the languages are similar and different.

There’s an elegant beauty to ruby’s everything is an object and all method calls are messages concept. Python has always struck me as less elegant but the upside is that it can model different ideas in different ways and doesn’t have to try to make them all look like the one central idea.

Even though I find the model behind ruby more pleasing to think about, I tend to enjoy python more due to it being more explicit and easier to reason about. Although that’s pretty subjective.

In any case I think the language feature of open classes is a fascinating one and one of the really different parts of ruby that really distinguishes it from python, for better or worse.

LLM is saying...

Stop. Nothing at all past those three words is worth a damn.