4 ms·
> It's typically caused by developers, not programming languages or frameworks. Best sentence in the article. I’ve worked in well-organized and reliable PHP ap
by xp84 2y ago
> It's typically caused by developers, not programming languages or frameworks.
Best sentence in the article. I’ve worked in well-organized and reliable PHP apps, and giant buggy abortions in TypeScript. Lots of Rails apps with varying degrees of quality. Languages and frameworks can’t fix disorganization, poor architecture, laziness, or most of all, ignorance of how the Web should work (and why.)
The main predictor of how good your app will be technically, is the skill level of your worst developers + how much your best developers care (or are allowed to care, which necessarily varies with business conditions). Regardless of if you’re using trendy languages like Rust, TS, etc.
Of course, while as hackers we desperately wish for the app to be of very high quality, the sad truth is that companies who always obsess over the finest details under the hood don’t tend to perform as well financially as the ones who make compromises to get things to market faster and pivot more effectively, so I think that’s why most of us have rarely worked in commercial codebases where nothing is embarrassing.
- randomdata 2y agoOf course, but the trouble remains what is stated in the very next sentence: > There are plenty of ways to nicely organize your code and you should probably spend more time refactoring. Ruby/Rails makes this a time consuming process as compared to many alternatives. If you have all the time in the world, Rails is great, but for the rest of us that also have to think about productivity...
- Linell 2y agoDo you have any examples of why RoR is more time consuming to refactor than other languages?
- rapind 2y agoIMO rails is a victim of it's own success. By being incredibly productive and easy to get things up and running, you don't have to reason about your data design as much, meaning you are more likely (not guaranteed) to throw together a bunch of badly related garbage. People love to blame the language and the framework, but in reality once you're past the proof of viability point, it's usually worth taking the time to review some of those initial decisions... except now you need to GrOw! :) The fact that it's rails is irrelevant. It could be any tool that makes you really efficient by never erecting guard rails.