7 ms·

> Also there's no guarantee that whatever type you observe in your particular binding.pry experiment is the only one the function receives. I honestly don't se

> Also there's no guarantee that whatever type you observe in your particular binding.pry experiment is the only one the function receives. I honestly don't see many methods where it expects a user but it can also receive a shipment or a billingInfo where tons of callers just pass all sorts of stuff to it as they feel like, and me as a dev have to keep wondering what the param is. That's not common at all because most Ruby devs just don't operate that way (Why would they? That's pretty insane). Yes it's easier to shoot yourself in the foot in Ruby but that doesn't mean we all design crap code. Static type people say your dynamic code is always littered with dozens of if param.type == 'user' else if param.type == 'baboon' etc etc. I rarely stumble into this in real life. I'd like to see some real examples (there's enough python/js/ruby open source code for us to make an intelligent discussion)

cageface 5y ago
I don't have examples at hand but I've worked in large Swift, Typescript and Rails codebases over the last seven years and the Rails codebases were the hardest to maintain and had the most errors in production. Have you done extensive work in a strongly typed language?
- joelbluminator 5y ago
  Yes I did C/C++ and Java in college and kinda hated it. It wasn't web based development work like I do now but I've written a bunch of static code in my life. I also took Spring MVC for a spin more recently and absolutely hated it with a passion. I think that the Ruby/Rails project you describe was probably classified as "legacy" and the company moved on to newer cooler tech like Swift/Kotlin/Node. That's when the Rails project becomes really fun where no one wants to touch it/improve/refactor anything and it quickly becomes a pile of shit after a few years since every change is done by someone hating that project and hating Ruby. Am I close? Otherwise I can't really understand why a skilled group of Ruby devs couldn't have refactored the thing.
  - cageface 5y ago
    C++ and Java are not going to give you the experience of working in a modern statically typed language. The issues I describe with Rails are issues I’ve seen across many different apps and teams.
notpachet 5y ago
> Yes it's easier to shoot yourself in the foot in Ruby but that doesn't mean we all design crap code. As your team grows it becomes harder and harder to prevent people from shooting themselves (and the rest of the team) in the foot in such a way, doubly so when you're working in a language that more easily permits it. To your point, if you're working in a smaller team with collaborators that you trust not to make these mistakes, that's a different situation. The inscrutable-method-input scenario that haunts me the most is the case of "options hashes" in Ruby/Rails. Someone writes a method that accepts a single hash of possible options keys, instead of an N-arity method that accepts those scalar values directly. When someone needs to modify the behaviour of that method, the short-term path of least resistance is to just throw another key onto the blob. In the most notorious example I can think of, one of our applications had an options hash with 30 (not an exaggeration) possible keys, after several years of developers deeming that the easiest way to implement whatever feature they were tasked with implementing. It was a total nightmare trying to debug situations where Key A | Key B conflicted in subtle ways with Key C & Key D. Of course there's nothing preventing that sort of scenario from emerging in a statically typed codebase, but I find there's more friction around doing so. Especially if you start out with a rigid interface (with non-nullable keys) that all your callsites must conform to. If someone tries to add a new key to the argument interface, those callsites will need to be updated to match.
- joelbluminator 5y ago
  > Of course there's nothing preventing that sort of scenario from emerging in a statically typed codebase, but I find there's more friction around doing so I actually agree with this, but there's also a bit more bloat and less flexibility. Also, I like the fact that Ruby/Rails is powerful and flexible and deserves trained hands. I kidna hate the Go philosophy of "code written by a junior and code written by a senior looks about the same". That's not for me. I wanna enjoy the progress I make in the language.

cageface 5y ago

I don't have examples at hand but I've worked in large Swift, Typescript and Rails codebases over the last seven years and the Rails codebases were the hardest to maintain and had the most errors in production. Have you done extensive work in a strongly typed language?

joelbluminator 5y ago
Yes I did C/C++ and Java in college and kinda hated it. It wasn't web based development work like I do now but I've written a bunch of static code in my life. I also took Spring MVC for a spin more recently and absolutely hated it with a passion. I think that the Ruby/Rails project you describe was probably classified as "legacy" and the company moved on to newer cooler tech like Swift/Kotlin/Node. That's when the Rails project becomes really fun where no one wants to touch it/improve/refactor anything and it quickly becomes a pile of shit after a few years since every change is done by someone hating that project and hating Ruby. Am I close? Otherwise I can't really understand why a skilled group of Ruby devs couldn't have refactored the thing.
- cageface 5y ago
  C++ and Java are not going to give you the experience of working in a modern statically typed language. The issues I describe with Rails are issues I’ve seen across many different apps and teams.

notpachet 5y ago

> Yes it's easier to shoot yourself in the foot in Ruby but that doesn't mean we all design crap code. As your team grows it becomes harder and harder to prevent people from shooting themselves (and the rest of the team) in the foot in such a way, doubly so when you're working in a language that more easily permits it. To your point, if you're working in a smaller team with collaborators that you trust not to make these mistakes, that's a different situation. The inscrutable-method-input scenario that haunts me the most is the case of "options hashes" in Ruby/Rails. Someone writes a method that accepts a single hash of possible options keys, instead of an N-arity method that accepts those scalar values directly. When someone needs to modify the behaviour of that method, the short-term path of least resistance is to just throw another key onto the blob. In the most notorious example I can think of, one of our applications had an options hash with 30 (not an exaggeration) possible keys, after several years of developers deeming that the easiest way to implement whatever feature they were tasked with implementing. It was a total nightmare trying to debug situations where Key A | Key B conflicted in subtle ways with Key C & Key D. Of course there's nothing preventing that sort of scenario from emerging in a statically typed codebase, but I find there's more friction around doing so. Especially if you start out with a rigid interface (with non-nullable keys) that all your callsites must conform to. If someone tries to add a new key to the argument interface, those callsites will need to be updated to match.

joelbluminator 5y ago
> Of course there's nothing preventing that sort of scenario from emerging in a statically typed codebase, but I find there's more friction around doing so I actually agree with this, but there's also a bit more bloat and less flexibility. Also, I like the fact that Ruby/Rails is powerful and flexible and deserves trained hands. I kidna hate the Go philosophy of "code written by a junior and code written by a senior looks about the same". That's not for me. I wanna enjoy the progress I make in the language.