I use the same argument for IDEs versus fancy text editors like EMACS. Sure, you might prefer the specific keyboard shortcuts, but IDEs objectively make developers more productive through features like source code integration, debuggers, and refactoring capabilities.
Use whatever you like on your home projects, but at work you should be using whatever is most efficient.
And interestingly, your argument also falls apart in the same way as the framework argument. It might make the average developer more productive on an average project. But most projects are not average, and neither are most developers. Everyone has some unique combination of strengths, just like every project has special cases that don’t fit within the box of a framework.
A framework is great if you don’t know much about the domain and just want to get something together quickly. But if you’re working on anything novel, then eventually you’ll bump against the walls of the framework. Hopefully you designed the project in such a way that you can break out of the framework for these inevitable special cases.
And I like frameworks! I’ve used a few in various languages and think they do a good job organizing the code for the basic cases. But every professional project I’ve worked on has eventually been trapped by piling workarounds on top of the framework to make it work for some unsupported or complex case, or an inevitable architecture fail which the framework has not considered an escape hatch for.
Just like developers and their tools. I have an IDE and nvim at work. The IDE has a lot of power for major refactoring and hinting features, and it’s reasonable enough for an untrained dev.
But it is very slow for the other 99.8% of my job where I’m not doing a big “find and rename all instances”. I am usually wading through a large project and jumping between files to try to understand a complex system. Once I understand it, I’m jumping between those files again to make my changes. All of that is much faster in a lightweight editor than an IDE. But I still open up the IDE every now and then to double-check some change that I made, or do those big fancy refactors.
You could argue that it's specifically true for projects, but the definition of average absolutely doesn't require that.
If for example you had 100 projects were 50 of them were built by expert teams who poured love into their work, and 50 were made by 12 year olds who spent one day on their projects before giving up, the "average" quality of the 100 would be a long way from either the great or the shit products.
Likewise if a group of ten people has five CEOs earning a million a year, and five waiters earning minimum wage including tips, none of the ten are "by definition" earning half a million a year.
Of course in my data sets there is a kind of "normal distribution" such that most objects are near the mean, but that needs to be found out not assumed.
I have no idea how many tech products are near the mean as opposed to near one extreme or the other, and doubt anyone could guess without bias and without actually researching the question.
> Most projects are average by definition. Otherwise that wouldn’t be the average.
You're assuming outliers in both directions don't dominate the process.
As an example, let's say we have 10 projects, that have some property that can be rated on a scale from 1-10. Difficulty to accomplish is the first thing coming to mind. If we have 5 projects that are a 1 on this scale, and 5 projects that are a 10, the average is going to be 5.5 despite none of the projects being anywhere close to that.
There’s way too much variance in projects for the average to be meaningful, in my opinion. They will have some or many average parts, but they will also have some number of parts that are special.
It might be normally distributed, but across tens/hundreds/thousands of dimensions. For example, some axes might be
Like, if you want a terminal-based UI and don’t need SQL access, then you definitely shouldn’t use Ruby on Rails.
Some of those dimensions are obvious at the start of a project but some aren’t. You might not find out until later that you need something that your framework doesn’t support. And when that happens, you can end up in a situation of hacking together the feature working around the framework, especially if there’s a deadline.
Like I said, frameworks are great if you are very careful with their limitations.
It's a really weird sentence. I think most people would consider IDEs are the "fancy" ones, compared to emacs. I have to read your comment 3 times to ensure I didn't read it wrong.
Plus the comparison doesn't work at all. When you use your home-made framework to solve a common problem, you make it harder to maintain for others. When you use emacs you use emacs.
Emacs and IDEs are tools, but frameworks and libraries (and programming languages) are not merely tools. They're tools AND raw materials.
"I actually wrote a vim versus IDE comparison. Do you know how much faster vim was? 4.3 seconds! 4.3 seconds I saved every day! All those months learning were totally worth it."
Use whatever you like on your home projects, but at work you should be using whatever is most efficient.