jeffterns8
A dev would require completely separate tools that provide that functionality to say otherwise.
Also, swimmers don't swim with weights to improve technique or strength. I'd expect it would result in unorthodox or worsened technique due to trying to swim around the artificial imbalance of the weights.
Anything lesser, they're calling a simple code editor but, by actual definition, they are referring to a lighter IDE (as the ones that can be installed as base editors they have all extended with plugins/extensions to that point) and then acting like the topic is about the big-brand IDEs, even though it is making points against tooling they are all using with their "editors" just like what you're using VSCode for.
The tooling and layout of the same functionality you choose to use is something more modern tools, and product versions, have improved upon but is unrelated to what an IDE is. It also differs between tools and IDEs. For you to say you've never used an IDE with simple or fast file handling is either a lie or a severe lack of experience, as almost all decent ones have a 1 or 2-click approach via the explorer (and toolbar/hotkeys if you don't like an explorer side-pane). I actually can't think of any half-decent IDE that doesn't have the same approach for files as popular code editors, and I've used a lot of both for different platforms and languages. The only time I've had noticeable experiences is in cases via command/terminal but we're talking GUI editors here.
Worth noting, I have never in my career found myself mentioning any Eclipse-based IDE as an example of a good IDE. In fact, almost every dev I've ever met regards them as the worst IDEs they have experienced, not as a baseline standard for or expectation of IDEs. It's basically redundant to comment on x experience being bad as anyone that has ever used one already knows that is expected.
Any decent IDE doesn't enforce such things, it is something questionable devs choose to incorporate. You may inadvertently do this if you don't know an IDE, and try to use excessive features available, but that's still on you for doing so. It shouldn't have been a decision made by someone lacking in knowledge/experience, whether a junior dev or a senior selecting an unknown tool without proper evaluation.
Or are you implying such features from IDEs can somehow be attained by non-IDE toolchains that don't also ingrain you in those toolchains to make use of said features?
The points made and most of these comments are a joke. Basically bad practice and poor use of source control is being blamed on IDEs. Anyone with these problems (in modern times, old projects/approaches are products of their time) simply isn't a competent dev and/or never studied. I don't even recall any of these things being an issue in the first months of learning to code, 10 years ago.
To be a good programmer, don't learn from bad sources and don't be overly lazy to the point you develop bad habits. You can do all of that while still using an IDE. How you use the tools available is on you, not on the tools.
If a tool is so bad it enforces bad practice and has no way to avoid complicating workflow, find a better alternative. A tool is meant to streamline and improve workflow, not hinder it. I've never chosen to use an IDE that has enforced any of the issues being commented on, as if the only alternative is avoiding IDEs outright. I choose to use IDEs that are best-suited for the language I am using, are flexible and allow me to work how I like without convoluting my workflow. I also never commit IDE or user-specific files to a repository as that's just awful practice.
I'm also yet to read a complaint in comments here that claims to be a specific IDE forcing or creating problems that isn't actually about a company/team that has created a terrible dev ecosystem (or backing off an archaic one) for a project that they restricted and boxed into an IDE. Just because poor project management can make a project a nightmare to work with doesn't make the tools involved the problem.