3 ms·

Yeah, I think this is what a lot of people miss. When I only used dynamic languages, I told everyone that they were the greatest thing ever and they were idiot

Yeah, I think this is what a lot of people miss. When I only used dynamic languages, I told everyone that they were the greatest thing ever and they were idiots for using static languages. Then I started using static languages and would never go back to dynamic languages. (OK, I still write Emacs Lisp.) All the things I thought were great about dynamic languages were actually a huge waste of my time, but I didn't know because I never really explored the other side of the world. I have looked at modern Ruby projects, and my assessment is that I absolutely would never want to be responsible for code like that. It's all way too magical, if you see code that says something like "foo.bar", you really have no way of figuring out where the code for "bar" is. "bar" may not even appear as a literal sequence of characters in the application's codebase, or even in the libraries it includes. If you like that, that's fine, but I wouldn't touch it with a ten foot pole. I don't find it that enjoyable, even if it does save me time today when I'm typing in the code.

vlunkr 4y ago
> even if it does save me time today when I'm typing in the code IMO this is the strength of Ruby/Rails. You can have something up and running incredibly quickly, but for complex applications it can easily become a mess. It's not easy to know where something is defined, what type it is, if it can be nil, if you're unknowingly calling the database one or one hundred times with your fancy one-liner, etc. Of course you CAN structure it all nicely beforehand, and even use type systems, but that's hard to get right, and at that point, you might as well use something else.
jaredcwhite 4y ago
In Ruby, `foo.method(:bar).source_location` works like 98% of the time. There are also LSPs like Solargraph now that work pretty well in VSCode, etc. I will admit there are certain gems which metaprogram the heck out of everything and that can get annoying, but the flipside is usually those are the gems which are hugely flexible because they're so popular and widely used (I'm looking at you Devise)—and if so there's plenty of documentation and community support out there. I'm also glad `binding.irb` is a thing now for immediately jumping into a console in the midst of your running app, and the new debug.rb gem shipping with Ruby 3.1+ is awesome as well (also with a VSCode integration).
- jaredcwhite 4y ago
  Oh, also I just got a hot tip from a buddy to look into Ruby Jard, a visual (but still terminal-based) debugger with a whole slew of features. Haven't tried it yet but it looks really neat-o.

vlunkr 4y ago

> even if it does save me time today when I'm typing in the code IMO this is the strength of Ruby/Rails. You can have something up and running incredibly quickly, but for complex applications it can easily become a mess. It's not easy to know where something is defined, what type it is, if it can be nil, if you're unknowingly calling the database one or one hundred times with your fancy one-liner, etc. Of course you CAN structure it all nicely beforehand, and even use type systems, but that's hard to get right, and at that point, you might as well use something else.

jaredcwhite 4y ago

In Ruby, `foo.method(:bar).source_location` works like 98% of the time. There are also LSPs like Solargraph now that work pretty well in VSCode, etc. I will admit there are certain gems which metaprogram the heck out of everything and that can get annoying, but the flipside is usually those are the gems which are hugely flexible because they're so popular and widely used (I'm looking at you Devise)—and if so there's plenty of documentation and community support out there. I'm also glad `binding.irb` is a thing now for immediately jumping into a console in the midst of your running app, and the new debug.rb gem shipping with Ruby 3.1+ is awesome as well (also with a VSCode integration).

jaredcwhite 4y ago
Oh, also I just got a hot tip from a buddy to look into Ruby Jard, a visual (but still terminal-based) debugger with a whole slew of features. Haven't tried it yet but it looks really neat-o.