Other than bungee cords for small pools/space usage, can't say I've heard of such drag methods, only of resistance training outside of the pool. Though, I didn't mean to take the analogy off-topic, maybe I got too literal.
That can be said about languages, libraries, plugins, any tools you choose to make use of. It's just about sticking to good practices and understanding what you're using instead of choosing to be a bad dev. That shouldn't require excluding everything that has the potential to be used improperly.
That's just confusing big-brand mature IDE suites as the definition for IDE though. Any dev working on an actual project is going to be using those tools with plugins/extensions, configured as an IDE.
A dev would require completely separate tools that provide that functionality to say otherwise.
The "programming text editors"/"code editors" of now that are used in place of traditional IDEs are practically always extended to, by definition, being an IDE, albeit a leaner, more custom-fit one.
Well the analogy doesn't actually allow for a starter/bad swimmer as they drown first.
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.
Poor project management != fault of IDE, it's the one responsible for choosing to configure the project in said way. That's not dismissing the fact that VS and other IDEs allow, and even recommend, nasty setups but, unless they force them, I don't see blaming optional features or poor usage of a tool as a rational reason to write off an entire toolset that can be powerful and productive.
The comments have just devolved into people arguing or confusing mature big-brand IDEs, with excessive and all-encompassing features, as the definition for an IDE.
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.
A lot of this is starting to result in talking semantics of what an IDE is. A powerful/smart code editor, extended to have the functionality most will ever use an IDE for (and definitely incorporating the base definition of what an IDE is), ends up being argued as different because the base product didn't start as an IDE or it isn't as feature-rich as the mature, big-brand IDEs people have grown up hearing. Why people are even playing semantics with this when the topic is making points against tooling, that programmers are very much using with tools like VSCode, I really don't understand.
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.
You mean when you or a team chooses to embed them into the project's workflow to that degree? Or are you talking about the worst IDEs no one should use while sounding like it is a general IDE issue with the industry standards?
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?
To be clear, this comment is about IDEs for common languages where they are a viable and general consideration as the topic is about IDEs as a whole. Platforms and/or languages where IDEs are commonly known as limited/awful, with no alternatives, are a moot point and not the root of the topic's points.
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.