Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

These days I don't really work with rails codebases, so I don't have any recent examples in mind to call upon. There's just a bunch of stuff you need to know about how rails works before you can successfully read/understand rails code -- I just remember seeing all this stuff in code and I was just thinking "where the f did this come from", and then realizing that the version of rails we were on had this feature that tied together these two parts with some obscure method.

I haven't even looked at Rails 5 or worked in a recent Rails 4 codebase so I'm sure things are much better but the code I remember the feeling of being perplexed so often at how a worked in previously wasn't my own so I can't go back and remember what parts really made me angry.



How is that different from any new codebase you have to look at? If anything Rails reduces the confusion because it has a set of agreed to conventions. I can’t think of any decently complex codebase I’ve ever come across that didn’t have it's own weird abstractions that aren’t immediately clear.

Disliking Rails’s built in abstractions seems to come down to only liking abstractions your own devs created which sounds like not invented here syndrome.


It's more which tools are used to make abstractions -- I find that rails uses and encourages implicit (auto-created methods, stuff injected into a method's scope) abstraction creation rather than explicit (functions/higher-order functions) abstraction creation.


Interesting. I've honestly never heard the complaint about "magic" and abstractions made so concrete. I still believe many of auto-created methods are a good thing and generally done with the thinking that if you do X in 80% of cases the same developer also wants Y. Which makes perfect sense to me but I can also see how that would be surprising and/or annoying.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: