I realise I'm probably alone in this, but this "depth of insight" is exactly one of the curses of IDEs for me.
When you write on a terminal, you are encouraged to make good choices so that your code is clean, with a well-thought-out structure and conventions that allow it to be read and processed by a number of tools as painlessly as possible.
When you're on the IDE, your code structure invariably reflects whatever workflow template has been defined for that particular IDE, and good conventions matter less because you can always use live links and stuff to inspect stuff via the IDE.
Of course, you could argue that there's nothing stopping you from following those good practices on your IDE too, or making the extra effort to configure it with good structure and conventions. But in practice, it's a bit like making the extra mental effort to choose salad when there's steamy melty pizza right in front of you every single time. The temptation to take shortcuts and not think your code out properly and just rely on the IDE to dump its defaults is just too great. In the end, when you compare (professional) well-thought out code written in a terminal vs templated code written in an IDE, I feel that the difference in quality is often palpable.
Also, I reject the idea that "tooling" is a concept unique to IDEs (or, in any case, that IDEs should necessarily imply superior "tooling"). Yes they offer the convenience of a suitethat is (hopefully) interoperable by design, but for me arguing that this makes them better tools is a bit like saying the Apple Store has better software than "the internet" and you should therefore only stick to Apple Store stuff.
I worked on the mess of make file and C dependencies created on Emacs in Sun Microsystems back in the day. You can make a mess with any tooling.
It was impossible to navigate and I spent most of my time constructing complex regexes for grep just to follow the flow. In an IDE I can right click an element to find usages/dependencies, etc. Some of them are just highlighted.
As a point in support of this comment, I recently perused the xxhash sources looking for the actual implementation of the hash functions, but it's difficult because there are like 20kloc of mostly preprocessor macros. This probably was not created using an IDE, and if it was, the IDE is not the cause of these issues...
i was able to find the xxhash core within 5 minutes, with no particular experience in xxhash or hashing algorithms.
1. google xxhash, click first result (github)
2. open xxhash.c
3. see it is mostly empty, go back and open xxhash.h. this file is 6k lines (not 20k), it probably has most or all of the implementation somewhere.
4. starting from top of file, read intro docs: "xxHash [...] is proposed in four flavors, in three families: 1. @ref XXH32_family: Classic 32-bit hash function." i will select XXH32 for illustration.
5. scroll down to examples, which calls "return XXH32(string, length, seed);"
6. ctrl-f "XXH32(", could be done in any text editor (even notepad)
7. press enter 6 times
8. see "@brief The implementation for @ref XXH32().", we have probably arrived at the core or reasonably close to it. if that didn't work, then I would try "XXH32 (", which would immediately find the XXH32 function.
of the 6k lines, about 550 are empty, about 2800 are comments, and about 800 are preprocessor directives. the comments appear to be mostly useful comments, not the "/* Frobnicate the bar. */ int Bar::frobnicate()" type which tend to be seen in IDE-overuse projects.
> When you write on a terminal, you are encouraged to make good choices so that your code is clean, with a well-thought-out structure and conventions
And then you realize you have to refactor 25% of it, or the requirements change, or a newly incorporated library suggests a naming convention change would be wise... IDEs not only show the code, you can pick a function argument, rename it, and get it renamed across all source files, comments included.
If your terminal editor does that, then you've partially transformed it into an IDE.
I get that functionality with go-guru for Go. Having powerful refactoring and static analysis tools shouldn’t require them to be integrated into a monolithic application.
You don't even need a terminal editor to do that; sed will do it fine. If you want to be pedantic about the mechanism by which you achieve the result, you can just use ctags, which even plain vi and emacs support.
What really set IDEs apart from text editors was integrated build tools and the ability to directly consume (and act on) build errors and the like. Search-and-replace long predates IDEs, as does 'code comprehension.'
An IDE is aware of the structure/meaning of the code, giving in much more power.
sed absolutely cannot rename all the occurrences of something like a class method, since it would require deep dependency graphs to find all the class instances.
In an IDE, I can do something like this:
# All three classes have a do_thing() method.
my_instances = {
1: Class1(),
2: Class2(),
3: Class3(),
}
my_instances[1].do_thing()
my_instances[2].do_thing()
my_instances[3].do_thing()
In the IDE, I can rename the do_thing method for Class2, and it will correctly change the line "my_instance[2].do_thing()" to reflect the new name, leaving the others alone. This is not possible without something mostly indistinguishable from an IDE.
You need a project view for that since it needs to go into all the files and do the "right thing" all over. It needs to verify external dependencies aren't broken as a result, etc.
I've coded in plain text editors all the way to full blown IDEs, and you're partially right, it's not the tooling that sets IDEs apart, but the seamless integration between several useful tools.
I like small editors for small jobs, but I wouldn't dream of doing a new business application without an IDE these days. With sed a simple search and replace would need to be manually checked for unintended effects, but an IDE will do it without problems in seconds, unless you go out of your way to confuse it.
This reminds me of when people say that the Visual Studio debugger is much better than gdb, or that Windows developer tooling in general is better than Linux tooling.
I believe the main reason why gdb kinda stinks is that it can be: traditional Unix-like operating systems typically have smaller components with well-defined interfaces, making them much easier to debug. Windows has too many DLLs, too many interfaces between them, and poor definition of layers. Quick, what's the difference between kernel32 and kernelbase? How do I tell which one a program is using?
This is not to say that Unix-like systems have perfect interfaces, merely that they're generally better-factored than interfaces inside Windows and Windows applications. Further comments can be made of the differences between Windows and Mac "applications" and Linux "programs": for example, the difference is not only in GUI or TUI or CLI: Firefox is an "application", but Notepad and Calculator are "programs"; Paint is a "program", but Paint 3D is an "application".
I think it's a bit naive to think that a given developer will produce better code when using an editor instead of an IDE. I believe that a certain developer will produce the same quality code whether he uses an editor or an IDE.
If you use default templates and don't really care about the structure of your code when using an IDE, you won't suddenly start to care when using an editor. If you don't care about all kinds of shortcuts and specific functionality in your editor, you won't care about learning the shortcuts (and even functionality) in your IDE.
Some people seem to think they will become better developers by learning to do their development with an editor, but I do not believe that is true. Maybe except for one thing: if you do use an editor and don't use something like LSP in your editor, you will be forced to memorise the standard libraries of your programming language; you need to memorise those to stay productive with an editor. And in general, I do believe that the pure text editing part is often more advanced in a good editor than in an IDE.
But, a good IDE is an amazing tool when you have the hardware to run it. Especially with typed languages, an IDE makes it a lot easier to refactor code and change the design of your code. This really lowers the threshold to change the design of your code when requirements change. Since the changes are simple and fast, developers are more confident to do those changes and will consider those changes in more cases. And aside from that, IDEs also often include an analysis part and warn you about fishy things in your code.
I have been an Emacs user for a very long time. I used it for C long time ago, and recently used (limited) it with an LSP server for C# (using the Doom Emacs distribution). And that is working nicely: magit is great, integration with LSP servers is great... you can get a lot of the stuff that is typical for IDEs. But when you do activate all those integrations, you will notice that it is also heavier to run and less responsive. So, in the end, when the hardware can run it, my preference is still the full-blown Rider IDE for C#. The IDE is much more complete out-of-the-box.
> When you write on a terminal, you are encouraged to make good choices so that your code is clean, with a well-thought-out structure and conventions that allow it to be read and processed by a number of tools as painlessly as possible.
This reads a little bit like a dynamic language vs a typed language. One argument for writing dynamic language is kinda similar to this.
When I write code in a typed language I have to think far less than if I write it in a dynamic language as the tooling takes care of it for me. But in my experience no matter how much I think about how to solve something in a dynamic language I make far less mistakes in a typed language.
When you write on a terminal, you are encouraged to make good choices so that your code is clean, with a well-thought-out structure and conventions that allow it to be read and processed by a number of tools as painlessly as possible.
When you're on the IDE, your code structure invariably reflects whatever workflow template has been defined for that particular IDE, and good conventions matter less because you can always use live links and stuff to inspect stuff via the IDE.
Of course, you could argue that there's nothing stopping you from following those good practices on your IDE too, or making the extra effort to configure it with good structure and conventions. But in practice, it's a bit like making the extra mental effort to choose salad when there's steamy melty pizza right in front of you every single time. The temptation to take shortcuts and not think your code out properly and just rely on the IDE to dump its defaults is just too great. In the end, when you compare (professional) well-thought out code written in a terminal vs templated code written in an IDE, I feel that the difference in quality is often palpable.
Also, I reject the idea that "tooling" is a concept unique to IDEs (or, in any case, that IDEs should necessarily imply superior "tooling"). Yes they offer the convenience of a suitethat is (hopefully) interoperable by design, but for me arguing that this makes them better tools is a bit like saying the Apple Store has better software than "the internet" and you should therefore only stick to Apple Store stuff.