3 ms·
To each their own, but frankly your assertions sound like nonsense to me. > Ruby doesn't have functions. It only has Objects, and methods on those Objects. Gen
by CooCooCaCha 2y ago
To each their own, but frankly your assertions sound like nonsense to me.
> Ruby doesn't have functions. It only has Objects, and methods on those Objects. Generally you won't run into method nuking because generally there's no need to define the same class in different files.
I was writing a rake task and all I did was write a function above the rake task definition. That function was loaded globally and conflicted with another function. If it’s in a rake file then what object is it a part of? This goes back to my main issue about how you don’t know where shit comes from in ruby and there’s too much implicit magic.
> Rails only looks like magic in this regard because it's coded around conventions so that it can abstract away all that boilerplate
This is what I’m talking about. What you call “abstract away all the boilerplate” I call magical bullshit that makes code confusing.
> Includes/Mixins are designed to encapsulate shared functionality. Like any effective shotgun if you shoot your feet off you'll be hurting, so don't shoot your feet.
Classes already do that. I’d much rather create an instance of a helper object than magically inject methods into my class. It makes the code more explicit and discoverable too.
> I've wrangled a lot of typescript and I cannot say that having types have made me feel protected in any way.
That’s strange because types tell you what a thing is and helps you find where it comes from. It offers protection if you use the type system but to each their own.
> `return unless some_condition?` is gods greatest gift to programming and I will die on that hill.
No, just no. `return if !some_condition?` is far more readable, especially if you have other lines that use `if`. Consistency makes code more understandable. And using `if` everywhere makes it so I don’t have to invert things in my head.
> Like every language you will meet your code golfers
I’ve worked with a lot of programming languages and ruby is particularly bad. Lots of people jerking themselves off about how short their functions are and you don’t see that in other communities as much.
- gls2ro 2y ago> return if !some_condition?` is far more readable Maybe it is easier to understand the condition or the boolean logic. I could agree with that. But readable? No. It is very easy to miss the `!` when reading multiple lines of code. While missing `unless` it way hardwer. Compare: return if organisation_exists? return if team_exists? return if !user_exists? return if project_exists? with: return if organisation_exists? return if team_exists? return unless user_exists? return if project_exists? Where can you see quicker that it will exit when the user does not exists? For me I need to read twice the lines that only have `if` and I can pick at the first read the `unless`. Not saying you should use `unless` but it is a keyword, like any other keyword that you learn when you learn a new language. We should not confuse lack of familiarity with readability.
- CooCooCaCha 2y agoThe purpose of reading is to understand. And I don't know what to tell you other than when I see "unless" I have to pause for a moment to flip it in my brain. This doesn't happen with "!".
- gls2ro 2y agoI dont disagree with the idea that the purpose of reading is to understand. My assertion is that lack of familiarity (or better said lack of seeing unless used often) is the cause of the hard to understand issue and not that unless is a word hard to understand on its own. Here is a question to reflect: How come ! is easy to understand while actually "not" is better (short enough to not consume reading speed while being explicit)? But a lot of languages are using ! so it seems to be good enough for reading. My answer to this is: because it is used so much => familiarity.
- titusjohnson 2y ago> I was writing a rake task and all I did was write a function above the rake task definition. That function was loaded globally and conflicted with another function. If it’s in a rake file then what object is it a part of? This goes back to my main issue about how you don’t know where shit comes from in ruby and there’s too much implicit magic. You added a method to the base `Object` object. Everything is an Object in Ruby. Unlike Javascript, blocks in Ruby (of which Rake tasks are comprised entirely of) do not create a private context in which to hide functions. If you redefined that same function name later in the task, it would clobber your original implementation. > Classes already do that. I’d much rather create an instance of a helper object than magically inject methods into my class. It makes the code more explicit and discoverable too. You might even want to create a helper class, and include several modules by which to build out the functionality of that helper class. That class might even inherit from a baser class, providing even more functionality. All options are available to you in Ruby. > To each their own, but frankly your assertions sound like nonsense to me. It sounds like you didn't bother to learn much about the language, or framework, at all. To each their own indeed.