4 ms·
I’m in a codebase now that dynamically generates functions, as if ruby/rails wasn’t hard enough to debug with its insistence on autoloading. The whole stack is
by qudat 2y ago
I’m in a codebase now that dynamically generates functions, as if ruby/rails wasn’t hard enough to debug with its insistence on autoloading.
The whole stack is a dumpster fire filled with footguns.
Where “show me where this function is defined” turns into an impossible task.
- irjustin 2y agommmm this is a problem of the engineers not the language though =\ Overuse of dynamically generated functions is possible in any high level language. The worst offender that I had seen was a PHP wordpress plugin that stored a custom function per row in the DB brought to life via `eval`. Those were the days.
- chowells 2y ago> Overuse of dynamically generated functions is possible in any high level language. A large number of high-level languages resolve functions at compile time, rejecting programs containing references to functions that don't exist.
- dragonwriter 2y agoNo language in which dynamically generated functions exist does so, because if it did it would be impossible to use them. I will agree that dynamically generated functions are not overused in languages in which they cannot be expressed at all, but...
- zdragnar 2y agoAfter years of programming against REST(ish) APIs backed by statically typed languages, I'm now fighting one built by a team that loves ruby/rails. It's a terrible experience. No auto-generated specs. Can't even look at the code to know what some request parameters are supposed to be (had to go digging through pagy docs for that one). One day, a value in a response that is normally a string was suddenly an array on certain queries. The whole approach is so haphazard move-fast-nobody-cares that it grinds my gears and I'm not even contributing to their code, just consuming it. My kingdom for a better experience.
- herbst 2y agoSounds like a bad API and not specifically Ruby issues.
- zdragnar 2y agoThe lack of openapi anything is a weakness of the ecosystem, as there's a ton of tooling that's left on the table. Even Python has a bit of a leg up here. On top of that, the number of bugs that could have been avoided with static types is a bit depressing- the only true way to avoid them entirely is duplicating what you get from a static language, but manually with extra unit tests. There's plenty of really nice things about Ruby and rails, but you don't actually get features faster without sacrificing something. The team puts out code at more or less the same pace as I would have expected from teams working with other languages, though I haven't seen so many nil errors since working with a bad Java code base.
- nasmorn 2y agoJust added open api to a rails API with rswag. It works by making the definition and then running your request specs against it. That certainly can make a lot of sense for your consumers
- lta 2y agoHow is grep not solving this problem ? I've met this pattern across many codebases but a simple call to grep (or equivalent) usually answers those questions pretty quickly
- seattle_spring 2y agogrep doesn't help much when the codebase is full of subclasses that implement the same generically named method of some uber-super-class.
- rezonant 2y agoI assume (since such practice is fairly common in Ruby metaprogramming) that the methods are generated at runtime, so there is nothing to grep.
- qudat 2y agoFirst, you cannot grep when the function is generated at runtime. Second, what happens when the code is in a different repo and there are zero imports so you have no clue where it’s getting loaded from? We’ve got multiple gems and microservices so I can’t even grep one codebase, I basically have to grep our entire gh org to find the function because ruby has terrible tooling to help with “go to definition”.