[rehevkor5]

It seems like the author understands, or perhaps his criteria is based on, only a thin layer of what an IDE can provide. Here's the highlights:

- Data flow to/from here (where did the value of this variable come from/go to)

- Call hierarchy (up and down)

- Class hierarchy (up and down)

- Class structure (including all inherited fields, methods)

- Checking your code against an actual database schema, perhaps one automatically launched in a Docker container

- Automatic refactoring of various kinds (rename, extract variable, extract method, inline method, extract interface, add/remove parameters, etc.)

- Build tool dependency tree inspection with filtering etc.

- Inspect code for a huge variety of potential code quality issues, with highlighting and auto-resolutions available

- Locate duplicate code, and automatically refactor it out

- Detect likely problems with nullity

- Easily navigate to lines of code in an exception call stack

- Analyze dependencies across classes & packages, detect cyclical dependencies

- Debugging, including watch windows and conditional breakpoints of various kinds

- Helpful tools for a variety of programming frameworks such as Spring

- Integration with git so you can view history, diffs, etc.

- WYSIWYG style rendering for stuff like Markdown

- Easily navigate to any class, including classes that come from your dependencies (for example I've worked with plenty of people who had no idea how to figure out how Rails worked if it wasn't in the documentation, because they didn't use an IDE which allowed them to easily browse the code)

Personally, all of that is just a huge amount of value.

[zmmmmm]

I think a lot of people's views have been influenced by their use of languages where the type system or overall language framework is either too weak (eg: Python, Javascript) or in some cases too complex (eg: C++) for more than a thin layer IDE experience to be possible. If you use those kind of languages then it's true, IDEs buy you a limited set of functionality and you don't need much more than a basic language server because that's about the limit of what you can get anyway.

[wwalexander]

I agree; before I starting writing Swift, my only IDE experience was using Eclipse in college, and I really looked down on IDEs. I thought of them as a crutch required by poorly-designed and overly-verbose languages like Java.

But the IDE experience with a language that has decent type system like Swift is really great. It truly just feels like a more efficient way to consume documentation and write code.

The analogy I would make is to texting on a numpad by repeatedly tapping a key vs. using T9 (assuming you’re in the right age range to have memories of texting on numpads). Sure, T9 might have guessed the wrong word a fraction of the time, but you never felt like it was dictating the direction of your thoughts or getting in your way.

This all depends on the programming language, the package/project scaffolding, and the IDE being tightly integrated and very thoughtfully designed, but when it works it’s a real pleasure. While I still believe that all languages should be ergonomical to write without IDEs, I definitely underrated the experience.

[viceroyalbean]

Even if an IDE is only a crutch for poorly designed languages, people still use those languages and an IDE is a useful tool in that scenario.

[winrid]

Actually, modern IDEs are super helpful with JS and Python, especially with type hints.

I can export a function or class in a big JS project, go to any file, start typing the method name, and Webstorm will suggest the import. With JavaScript!

Not as great as the Java integration but still pretty nice.

[kitd]

Completely agree.

I recently had to work on an unfamiliar JS codebase. After initially pulling my hair out trying to understand what objects were being passed where, I decided to define some types and parameters using JSDoc . VsCode picked them up instantly and it was like coding with a language server after that.

[winrid]

Also recommend this to learn a new code base which will log every function call:

https://www.npmjs.com/package/@phenomnomnominal/debug

[fuzzythinker]

The repo has zero documentation. Do you use it on client, node, or both? Does it renders the calls in a tree?

[winrid]

Oh you're right, sorry. Here's the blog post the dev wrote:

https://dev.to/phenomnominal/lazy-debug-logging-for-node-js-...

The idea is it logs every function call. Nice for picking up a new code base.

[stickfigure]

I cut my teeth with IDEs from the 90s that did a great job with C++. The article author is just ignorant.

[user3939382]

I use PhpStorm by JetBrains and am totally blown away by how powerful it is. It does all of the GP’s list and way more.

[Aeolun]

Powerfull, but sloooow. I really want a faster Jetbrains IDE.

[twothamendment]

Yes, if the next release didn't have a single new feature and was just a bunch of "x is faster, y is faster" - I'd call that a great release!

[native_samples]

Usually when people have speed problems with Jetbrains IDEs it's one of two things:

1. Heap size is too small and it's GCing a lot without the user realizing. Open IDE VM options and double the -Xmx setting.

2. Using a 4k display on macOS. Try the new JBR17+Metal builds. They aren't shipped yet but switch it to using Metal to render. Makes it a lot faster.

[Aeolun]

Huh. Nr 2 is applicable to me. Will give it a try. Can’t see how it’ll fix my permanent indexing, but maybe it’ll at least feel faster.

My heap size is already at 3GB, which I feel should be enough for opening a bunch of 5kb text files :/

[native_samples]

If you're permanently indexing something is very wrong and that will indeed break your IDE. That's just a bug. Try wiping all your caches from the menus and see if that helps. Otherwise file a bug in YouTrack.

[user3939382]

They're working on a new, faster underlying architecture with an IDE called Fleet. It looks like it may be a long-term foundational replacement for their other IDEs including PhpStorm.

https://www.jetbrains.com/fleet/

[lamontcg]

As a 30-year vi user who recently switched his C# programming to Rider over the summer of 2020, I'm a bit of an IDE convert now, for all of these kinds of reasons.

What really sold me on it is the ease of refactoring. Makes it easy to rearrange code and clarify names and things as you build the project up.

And then the code quality stuff taught me some things that I didn't know like the allocations that happen in C# with closures being passed to functions.

And then there's just the accuracy bits like greying out unreachable code which usually points out typos.

It also integrates well with the nullable checks in >C# 9.0

The IDE can teach you to be an expert and catch little gaps in your understanding of the language along making you a lot faster and doing a lot more in-editor, and letting you spend more mental effort on all the rest of software development.

Since C# is also object oriented, it also leads towards doing lots of boilerplate for interfaces and delegation which IDEs are pretty critical for (And I'd argue that Go's verbose error handling though also can benefit greatly from macros in an editor at least before anyone hops off this comment into an anti-OO rant).

[jillesvangurp]

Indeed. My attitude is that people should use tools that work for them but without compromising on code quality, productivity, or impacting other team members with their tool choices.

The latter is a big caveat when working on Kotlin/Java code bases because standards are high regarding things like code formatting, style, etc. People will notice when you skip some of the things Intellij does. The few cases I've seen of people not using the right tools for the job, they thought they were doing a great job. And then I did a code review and showed them how bad it was because clearly they were blissfully unaware of warnings, had never run a static code analyzer, were clearly not refactoring their code base, and were generally doing a lot of things that were bordering on "probably wrong; definitely not optimal".

IDEs provide several big buckets of essential functionality:

- Code criticism: warnings, static analysis, deprecations, dead code, etc. You can use external tools to stay on top of this as well. But having mistakes pointed out to you as you are making them saves a lot of time. Also, since these are preventable problems, there is zero excuse for having any of them. So, whatever you use, make sure you stay on top of this. If this is tedious, consider using better tools or fixing the ones you have.

- Intelligence and situational awareness: Syntax coloring, code navigation & documentation, find uses of, etc. When stuff doesn't work, this is a real time saver. Bottom line here is that there are things that you need to know how to find out about your code. If you can script things together using grep and other command line tools; great. As long as you are productive. But you have no excuse for ignorance.

- Automatic program transformations: This goes way beyond refactoring (which is also useful of course and for which renames are merely the simplest example) and also includes things like using quick fixes for common problems, automatically applying replacements for deprecated functions, adding all the missing branches to a when statement, managing lists of imports, converting between different syntax alternatives for the same thing (e.g. convert between when and if, invert an if, ...), etc. For languages like Kotlin and Java, there are hundreds of these and they are super useful. I use them all the time. Use them or don't use them. But you should not allow your tool choices to impact your code quality. So, if it needs refactoring, do it. Do it manually if you must. But you don't get to skip it. Edit your imports like a caveman if you must, but make sure you do it properly (no wildcards, sorted correctly, remove unused imports, etc.).

- Tool integration: Build tools, debuggers, de-compilers, code formatters/linters, etc. Nice to have that at your finger tips. If you do this via the command line, be my guest. But make sure you know how to use your tools and that you do use the tools that are available to you.

On projects I manage, I'll judge people on their code quality, not on how they produce their code. But I'm a harsh judge when it comes to that. Do it whatever way pleases you but do it right. And with some editors, that just means performing a lot of manual labor.