Countless times I meet developers who prefer simpler editors. And by “prefer” I mean that they have strong negative feelings towards any IDEs, especially the ones that one needs to pay money for.
Now, it’s worth mentioning that my path through coding tools over the last 20 years went like this:
Notepad -> Turbo Pascal Editor -> Delphi -> Visual Studio -> Gedit -> Sublime Text -> Vim -> Emacs -> Emacs (Evil mode) -> Atom -> Vim -> IntelliJ Idea (settled for now).
The switch to IDE had happened when I attended a Software Craft meet-up. I’ve paired with another developer who’ve shown me something that looked like magic to me at a time.
Basically, I’ve felt doubts about the tooling of my choice, since this IDE that was in front of me (in the hands of an experienced user) could allow me to do development at a 5x-10x rate of what I could currently.
Now the question is: why do we, developers, feel such negative feelings towards a paid tool that can boost our productivity so much?
Let’s discuss!
Top comments (131)
I used Eclipse, NetBeans and some form of IntelliJ.
And I'm always coming back to a more simple editor like Atom or VSCode.
I'm a web developer and usually, the extensions VSCode and other editors can give you are enough for me.
IDE's tend to be slow and don't add for me the value of having such a big monster installed on my machine.
IDE's feel more like they slow me down and are in my way instead of helping me get stuff done.
Maybe if you have a Java project or other languages where the IDE can be more helpful it makes sense.
It really depends on what field you are working on.
I’m working always fullstack (no matter which stacks included), so often, I get to work with frontend (JS/TS/React or TS/Angular). I’ve worked in IntelliJ and VSCode, and I observed people working in IntelliJ and VSCode.
My three observations:
Now, you mentioned something about slow IDE. you probably didn’t increase the amount of RAM that you allow IDE to use. The default is just too small to index 20000+ npm packages and stay fast. I usually give 8-10GB to my IntelliJ Idea and it gives me back 5-10x boost of productivity because I rely on automated imports, smart completion, and refactorings all the time. Nice ROI. RAM is (supposed to be) cheap.
I just have 8GB in total on my machine.
point 1 and 2 work great for me also in VSCode with the right plugins.
I just type something and then press tab and it will be imported.
I'm working on nodejs code and the autocompletion is pretty great
I just type spa and I get spawn or spawnSync and then I press enter and it imports the right thing from 'child_process'.
I would rather say that your problem is that you are having one project with 20000+ npm packages. I try to keep my services small.
This also helps with refactoring.
So yeah maybe if you're working on one big monolith app with a lot of dependencies everywhere it makes sense.
So yeah if your refactoring this amount of dependencies then for me something else is not correctly setup but yeah. No judgment here just guessing.
Welcome to frontend ;)
You can get these numbers just when you bootstrap a new empty codebase…
I’m not refactoring any of the NPM package dependencies. You’re too much focused on that. This is normal in frontend projects.
I’m talking about refactorings that I need to do in the normal course of the proper TDD workflow: write a failing test, make it pass with a simplest (but perhaps dirty) implementation, refactor to make the design cleaner, and then repeat over and over again.
It would be wonderful to be able to point to a YouTube (or Vimeo) video of half an hour of someone doing these amazing refactorings that one should do 20 times per hour as a part of normal development flow. It’s called continuous refactoring. But I don’t know of any at this moment. (maybe I should ask on Twitter if anybody has such a video)
Otherwise, it’s like we’re talking about different worlds.
I'm doing frontend now for over 8 years ;)
And I do 7. A little bit less than you, I guess. In the past the proliferation of packages and dependencies was not as much…
That's true.
I also try to prevent to load to much packages. When I can I just take the one functionality it of the package and just put it into the project ;)
That’s a good tactic :)
I have 16GB on personal. And at work, I have 32GB. The cost of this RAM is much lower than the potential sacrifice of developer’s productivity.
I mean this are all valid points but at the end people are different. So if it works for you good more power to you.
I just like to think first about the how I will do stuff. Even on paper and then execute. So maybe that's why I like normal editors more.
Makes sense!
Not sure when you last tried it, but for me VSCode works very well in terms of TypeScript refactorings. And the autocompletion is great.
What specifically did you find lacking?
An example of a refactor would be perfect.
I will be honest, I don't understand the first point at all. What does "expunging default exports fully contrary to community standard" mean? There are automatic import features in VSCode, but I don't use them. I don't find that any sort of automatic import management to be a productivity improvement.
I personally dislike IDEs. Or more precisely, I dislike using them. I don't dislike all IDEs in every single case but as a general rule I can say I prefer coding without one. My main reasons are:
They feel bloated. Every time I use one I feel drowned by all the features and settings and the thousands checkboxes everywhere. All those things are sometimes so overwhelming that I end up being less productive with an IDE than without.
Configuration and habit. There is no perfect IDE that can do everything and each IDE is different from the other. And I don't like that. I'm willing to learn a lot of different things when it comes to languages and techs, but when it comes to tools, I want to learn and configure one thing right and be done with it. No IDE can offer me that, but editors can, at the cost of a few features.
I don't need one. IDEs offer a lot of features but sometimes you gotta keep things simple. When I code, the only thing I care about is how clean my code is and where I did mistakes. For the former there are linters, most linters work on most editors, no need for an IDE. For the latter, the language compiler/interpreter does this job, again, no IDE is needed. And that's all I need. I don't need (nor want) autocompletion, integral VCS integration, etc...
They are bottom-less pits in terms of resource. Vim (with my config and plugins) runs everywhere I want to, from my shitty laptop to my remote server. IDEs don't. They are just eating my RAM and CPU away. I don't always work on a powerful desktop and when I don't IDEs are really painful to use.
Now, as I said, in some cases I use an IDE. When I do Java is a good example. Java and the typical Java processes and environments are something I'm not very fond of and that I'm not willing to learn too deeply (because I do Java only when I have to). So in that precise case, I enjoy using Intellij IDEA which is the only IDE I can tolerate. And I'm familiar with it from my Android Studio days. But beyond that, it still features a lot of the things I dislike about IDEs.
On point 1:
I agree with you, the learning curve is slow in that regard. Find action/find everything helps a lot to discover just the things you need right now. Also, no-mouse challenge helps tremendously.
On point 2:
I use IntelliJ Idea basically for the following list of technologies (and much more is possible):
On point 3:
How do you refactor? How often? What kind of refactoring you do? How much time does it take?
By the way, continuous refactoring is the best way I know to keep code clean. And linters won’t help you with software design and architecture of your application.
On point 4:
Depends on your ROI. I put 8-10GB of RAM into IntelliJ, and I get 5-10x developer productivity boost because I refactor and transform code all the time, instead of typing it too much. Saves me time, and protects me from RSI syndrome. I think this is a great deal. RAM is cheap.
On the final point, you should try to use IntelliJ with other languages that you use. It works great for the ones I listed above (and +some).
I refactor by hand, that's how I actually learn how to do good code by myself, I don't need an IDE to tell me what to do.
Indeed, but you don't need an IDE for that, just some common sense and knowledge. People did good code before IDEs even existed.
Even so, IDEs don't bring anything new to the table, they are just an aggregation of tools and good practices you can use/apply via other means/by yourself.
10Go is what I allocate to the Virtual Machine I work with daily. 10Go for an editing program is simply insane, no desktop software should take as much. Ever.
That's irrelevant, I work with the hardware I'm given, I don't buy nor choose what's in my enterprise computer.
(And actually, RAM pricing is through the roof since several months, so "cheap" might be relative)
I just explained why I don't. I'm not trying to convince you of anything, just stating why I personally don't like IDEs. I've been coding for nearly 10 years and tried several and always preferred editors over IDEs, I think it's pretty safe to say it works pretty well for me.
I don’t let my IDE tell me what refactoring to perform too. In fact—it doesn’t have such a feature.
It only automates what I would otherwise have done by hand. And it’s faster this way after you already learned about the refactoring and can do it by hand.
Especially, it’s quite good when you want to perform a complex refactoring that consists of 10-15 simpler refactoring steps, you have two choices:
With a simple editor, I’d be skewed towards the first option. The problem is that this would cease to be a refactoring by definition of the word refactoring. It’s going to be a rewrite, and it can lead to small hard-to-notice mistakes that will leave me debugging for minutes/hours.
With IDE, I’d be skewed towards the second option, because it’s easy to perform these simple steps—they are at the tips of your fingers. And this would be a true refactoring because it performs small simple steps that go from one GREEN step to another GREEN step. The likelihood to need debugging after such refactoring goes down to ~zero.
Sure, no problem. I think my original question is imbuing too many assumptions about refactoring and how people (should) program. With these assumptions, it just doesn’t make sense to not use IDEs when they are present.
Maybe I ought to ask questions about how people program first :)
Your question was ok (and I hope my answers didn't seem too... curtly, I just tried to be concise) but these kind of things are indeed related to how people code more than just whether or not IDEs are good and why (because they are of course, they are awesome tools).
Also, even though IDEs can indeed increase productivity, that's a relative thing. Some will get a huge productivity boost, some others won't (for various reasons). The fact is: most people who code are also passionate about it, so they need to actually enjoy it. I know I enjoy more coding with my preferred editor rather than IDE and I want to keep it that way simply for the sake of it, I don't care about the potential (and most likely small) productivity loss.
Thank you for reminding about this!
Everyone is passionate about their own things. My passions force me to find ever-more efficient, cleaner and successful ways to develop high-quality software. This is what brings me joy.
Others find joy in other things. Very well, thank you, I’ll keep this in mind.
I think IDEs are often an overkill. If I'm building something small, I don't need a heavy IDE. If I'm building something larger, I prefer using the same tools I do for smaller ones because I have learned them.
I also like an Unix-like philosophy of small tools that do one thing well and then I get to combine my toolchain from different tools based on my preferences. And I prefer to run my apps, commands, tests, etc from the command line because they then integrate nicely with other command line tools.
Sure, both my Vim and VS Code are heavily customized and extended with extensions and plugins. But that's the way I love it: I'll only have things I need and piece by piece I can make it better. Instead of having a large thing that does everything but makes small things sometimes hard.
Another reason that came to mind from reading other people's replies: I do programming in many languages. I do Typescript, Javascript, PHP, Python, Ruby, Bash, and occasionally something else as well. Most of the IDEs are designed for a single or couple of languages and just don't feel good with other ones.
I use IntelliJ Idea Ultimate and I do all the listed languages in this IDE. So this seems to be a fallacy, or it’s just a unique IDE that beats all others, I’m not sure, I didn’t use other IDEs. Platforms/languages that I use in a single IDE with the same shortcuts and behaviors:
Java/Kotlin for Backend/Android;
Javascript/ES6/Typescript for Backend/Frontend;
Python and Ruby for Scripting/Backend;
Objective-C/Swift for MacOS/iOS;
Golang for CLI/high-performance-backend;
PHP for backend or plugin dev.
I used to try Eclipse and PyCharm back in the day and even though I could build Python things in Eclipse, it felt like it was built for writing Java and vice versa. Sure, I have not used IntelliJ Idea Ultimate so maybe my experience is just outdated.
Does the IntelliJ Idea Ultimate have functionality for build tools, running tests, etc that are equally good for all languages or does it feel bit biased to one direction?
Yes, it generally does. I can switch seamlessly between different languages and run my build/test with the same shortcuts. Main refactorings are present in most of the languages. As well as auto-imports.
Of course, Java/Kotlin has top-notch support. Then Ruby/Python/Php has 2nd-place support because they are dynamic. Then you have all the other languages with medium-level support: Golang, Swift, etc.
Basically, Ultimate edition contains all the other JetBrains product inside of it in a form of a plugin you can install. Used PyCharm/RubyMine/PhpStorm/WebStorm/Goland/etc?—that’s a Python/Ruby/Php/Javascript-Typescript/Golang/etc plugin in Ultimate.
Of course, if you need something simple, a text editor would do. I use Atom for these things nowadays all the time.
While I love the UNIX philosophy I also know that most IDEs are plugin-based where you can disable 90% of the monster and leave only 10% of what you need, and then add few plugins on top of that. You could say that IDE has its own little “UNIX” inside of it.
The difference between a plugin-based text editor and IDE is that one is based on text and the other one is based on the code Abstract Syntax Tree. Refactorings in the latter are much faster and robust. Which is what I value personally a lot, as I do them every 2-5 minutes as part of the TDD cycle.
You can use vim style editing with Jetbrains and also have a database client, terminal, outline viewer, etc. open side by side or not.
I think my problem comes as soon as I hit my first snag. VCS not displaying what I'd expect? Poke around in dialog boxes for a while. Try turning it off and on again. Then... open up a terminal and fix it.
For me, I feel comfortable knowing what's going on.
I'm used to IDEs as wrappers for command-line tools, and I'm used to most of those command-line tools. When a GUI tries to make things simpler, it usually means hiding 1/3 of the options in an "advanced" menu somewhere and not implementing another 1/3 of the options at all. It's all very opinionated.
If I was developing in something like Java, I'd probably use an IDE. But I'm not.
For a couple of years I used Netbeans and PHPStorm and I've dallied with VSCode. I recognise they're good products. I've got VSCode installed and keep meaning to give it another go.
There's not much an IDE gives me over Vim, but I'm aware of a couple of things I'm missing out on:
On the other hand, we have terminal Vim, where my mind gets around my workflow. I have multiple Vims running, some of them backgrounded, some in tmux session and some on remote systems. I imagine an IDE proponent would think this was messy and disorganised, but it's my setup and I know what's going on. My bookshelves at home have a system, too. No visitor can understand it but it works for me.
I see pros and cons to each, and think they can co-exist in my life.
Surely they can coexist. I use Vim for simple text editing tasks (configuration files, just checking something quickly), and I use IDE for actual development.
You didn’t mention “refactoring” in things that you’re missing when using Vim instead of IDE. Why is that? Are you doing refactoring by hand? How often are you refactoring? What kind of refactorings do you do?
Refactoring for me is generally done inside a single module. The stuff and IDE gives me... if I change the method names that are used externally I have a couple of helper mappings to sort that out for me: I hit
//to find uses of the currently-being-edited function in all files and the reciprocalgDto go to its definition. I can then just do a simple search and replace.That sounds quite tedious. A good name is on average achieved on the 9th try.
I want to rapidly rename methods, classes, variables, etc. so that I and my pair can work through at least half of these 9 tries very quickly.
I guess, instead of thinking about the name for a while, I love to just change it on impulse and then analyze how well it reads in the location where I was renaming it.
Without the need to do additional actions except for typing a new name, I can really iterate quickly through different names as I discuss them with my pair.
Now, what about other refactorings? Like: move method from one object to another, extract variable/method, inline variable/method, extract delegate object, extract parameter object, pull up/pull down methods along the hierarchy chain, etc.?
Vim can do all of that either out of the box, through plugins, or through custom functions.
The closest thing that I could find is this: github.com/apalmer1377/factorus
It’s bearable but it doesn’t have all of what I need. Are there any other plugins that enable this?
Also, it’s not supported for a lot of languages: JS/TS, Kotlin, Swift, Ruby are missing
There also seem to be this plugin: github.com/Valloric/YouCompleteMe — it looks pretty cool, unfortunately supports only rename refactoring…
I'm by no means allergic to IDEs but as I have recently switched from IntelliJ to VS Code, I might add my two cents.
My initial reason to give up on IntelliJ was frustration. I had to work with files over 500k lines for a few weeks and got frustrated with IntelliJ freezing and exploding a few minutes later. I probably could've just used another editor for just these files but I wasn't thinking clearly and decided to give VS Code a go.
My experience with VS Code has been overwhelmingly positive. It's fast, it looks good (can't say that about IntelliJ, sorry), and it's quite powerful. After installing a bunch of plugins and learning a few keyboard shorcuts, I feel nearly as productive as if I were using IntelliJ.
To be 100% fair, let's explain the "nearly" part of the previous sentence. Refactoring capabilities of VS Code are nowhere near the ones in IntelliJ. A file-scoped rename or method extraction work most of the time but that's about it. In this area, IntelliJ is still close to my heart. The reason it hasn't swayed me back so far is probably that my project involves a lot of research and experimentation lately, so I'm more in "need for speed" than "need for a code tank".
I understand you.
500k SLOC files require quite a bit of refactoring…
But the right tool to perform such refactoring can’t handle them 😅
I’m practicing continuous refactoring because I apply proper TDD. I’m refactoring every 2-5 minutes, so I can’t generally live without it.
If I needed to tackle 500k SLOC files, I’d use a separate tool as well. And I would also push for separating them into multiple ones whenever we touch them. It’s hard work, but worth it. And it guarantees the more often we touch them—the more refactored they’ll be.
These ain't code files, it's a job's output to be processed by another system ;)
Oh, sorry for the misunderstanding…
I wouldn’t even try to open these in IDE. This is clearly a job for a robust text editor like Vim, Emacs, Atom, Sublime or Code.
That wouldn’t trigger a full switch for me personally, I’d just open another tool, do what I have to there, and switch back.
In fact, on my previous project, we always had IDE + TextWrangler open at the same time, because we had to work with some huge input/output files as well.
No probs.
Looking back, I'd say that making a full switch was somewhat an overreaction. I inherited this nasty project with giant SQLs producing gigantic XMLs and on top of that the tool I'm working with is blowing up (despite the fact is supposedly supports large files by disabling certain features). I was sad, I made the switch and I'm pretty happy. Probably as soon as I need to spit out some production-grade Java/Kotlin I'll be back to rocking IntelliJ.
Makes sense to me!
IDEs or text editors are just tools in my tool box.
I use the tool that I consider suitable for my task at that time.
If I want to edit my Linux configuration I usually use simple editor like nano or vim because they always available and can be used through ssh.
When I'm creating Java project, I'm using IDEs like IntelliJ or Netbeans, because I can directly start to code without having to configure the build system.
For R project I also use IDE (RStudio).
I'm very comfortable using VSCode or Atom for web app projects.
Just pick the one that you feel comfortable with and suitable for your task.
I agree so much with your comment.
What should I do if I disagree with the best tool for some of the jobs?
For example, doing JS/TS for web frontend projects is much better and more efficient in IntelliJ/Webstorm. But you have to break community guidelines concerning the import structure because you don’t manually manage imports/exports anymore and you let the tool do it for you (just like in Java/Kotlin, imports just happen automatically).
I mean, I really cringe when I see people crafting their
export * from './somefile.js'inside ofindex.jsinside of the package directory, so that it is available under a cute import, that will be easier to manage manually later.Time wasting.
I don’t have to spend time on that whatsoever. Just create a bunch of JS files grouped into package/directories and never use
export .. from ..construct, and never use default export.That is of course when I write apps. With libraries the story is different.
Though I generally prefer IDEs due to them usually being more out-of-the-box when it comes to features needed to start programming, but I assume people dislike how bloated they might become.
For example, if I'm using VS Community + Resharper, formatting a script takes several seconds, as opposed to liteIDE which (through go format) can format in less than a second.
And countless of IDE's I've had graphical bugs or features that don't work until I restart the IDE, as opposed to most simple text-editors where such issues occur much less, and mostly only when opening a too big file.
I definitely can agree that with larger codebases I need to restart my IDE from time to time. I guess, for me, I became accustomed to that and started tolerating it. That is because I still get tons of value from complex automated refactorings because I use TDD and I need to refactor in small atomic steps every few minutes.
The famous quote “Have you tried to restart it?” works well here.
What I did notice is that when you have a simple editor, or library, tool, or framework, whenever such blasphemy happens, we, as developers, go to GitHub (or another tracker) and report an issue. We also help with all the details for the developer, and engagedly help them fix the problem.
I see myself (and others) do that much less with a paid tool for some reason even though the support (that we’re paying for) is exactly for this purpose.
Why do you think is that?
I think it's a mindset when we engage with Big Companies vs. individual developers. Smaller open source projects like simple text editors feel like individual devs we'd like to help, because we know the struggle if being a dev getting their project bug free. Large IDEs that we pay for feel more like anonymous companies that don't deserve our help. I've seen a change of my mindset toward some of the Jetbrains IDEs: I've met a few of the people behind CLion, and I'm much more inclined to file bugs and provide repro steps for that IDE, but not for others.
Yes. This!
The people behind it are small teams of developers. If they don’t have the feedback loop closed—there is no way that the bugs will be fixed. And also, in this complex world, it’s not possible to write bug-free applications from the get-go without the feedback loop.
Usually when I have a problem with a bigger tool the issue tracker points to a several years old issue that's either marked as solved or wontfix. In addition, some are hard to describe or recreate, and it feels strange to complain about a project not being optimized enough.
Though I must admit I'm often too lazy to report issues, so I can't really answer your question well :-P
Because you see developers clicking buttons and not knowing what they do. I've seen someone be flabergasted about a situation where tests were passing locally but not on CI - turned out his heavy IDE was set to run a different type of test suite. And it wasn't obvious.
Because people who like Unix and Bash like spending time in a (non-integrated) terminal.
Because you learn the languae through the IDE vs learning the language raw and being able to use Sublime/Atom/VSCode/Vim/whatever.
Because most people who don't like IDEs very much are also not very fond of those verbose, enterprise language that require an IDE - otherwise most devs would be useless.
Because it means that my life and my work is staring at something which is out of my control.
We like freedom.
Yes, I hear your point: to be a well-rounded developer you need to master both IDE and non-IDE way. IDEs exist there to boost the productivity of what you already can do without them. It’s not a good idea to use IDE to perform what you can’t do without them.
I was lucky as I started out in an environment where I could do a lot of in-terminal work, learning all the Unix tools, using powerful text editors, etc. When I came to IDE world, I’ve seen only benefit, because they supplement my existing skills and automate what I’m bored to do manually.
What if I'm not developing in a JVM language, C# or XCode? You're not wrong - a good developer should learn all the tools. But your question was "why do devs dislike IDEs", and if I'm writing Ruby, Python, Golang, Elixir, JS, and many other languages then you really have to prove to me that using this ridiculously heavy tool is worth it.
"Hacker" types don't necessarily dislike IDEs, but every single non "hacker" type is wholly locked into their IDE. It's all they ever see.
If a random developer comes along and shows off something new he/she did over the weekend, what would you bet that they're not an "IDE person"? I'd bet on it.
If I was working on a huge Java codebase I'd have to use an IDE. As long as I don't have to I won't. There are different types of developers with different goals, and if I had to point at someone and say, "I'd like to be like that", then it would be somoene like Gary Bernhardt. And falling in love with an IDE simply isn't part of that path.
If you really enjoy working in an IDE then awesome for you.
"(IDEs) automate what I’m bored to do manually."
Right. Well that sounds like generating classes. That doesn't exist in many languages. Clicking into classes through call paths are super useful, but such code is (again) a symptom of the languages that require these features.
I’m using IntelliJ Idea Ultimate heavily for Ruby, Python, Golang, and Javascript. Works almost as well as for Java/Kotlin/Swift/Typescript/etc (from my humble polyglot developer experience).
Sorry, no. I automate imports, syntax sugar suggestions, cycle through alternative forms of the same code (different syntaxes of lambda, if <-> case/when, add/remove code block, change signature of the function etc.). And most importantly I use automated refactorings every few minutes.
I did such refactorings manually when I was coding in the powerful text editor. The problem is that you can’t do a lot of them, because they are tedious, especially if the codebase is anywhere big enough.
80% of these refactorings can be automated, and what might’ve taken minutes of search/replacing + hours of debugging what I’ve missed, now takes just seconds. That enabled me to use higher-order refactorings—a sequence of small atomic transformation that can take me from design A to design B, and all the tests will pass after each small step. Also, every step takes seconds to perform.
Well, that’s a wonderful note. What is the problem with classes and objects? Most of the languages that you’ve listed above will have those (except Elixir).
Yes. IDE is not used like this. On the work machine, I would usually launch it and never close it for the next 2-6 weeks.
Great points of using IDE is to let go of handling imports/exports on your own manually, and safe automated refactorings.
Start freelancing as soon as you can, and whenever people have wrong assumptions, you can tell them that this is actually your passion, and you’re coding to make your clients happy—you’re a small business owner. I think the respect will bump up higher immediately.
There are several reasons.
if you consider paid software, it usually means privative software, that you cannot modify when you encounter a bug or a need for a modification or a new feature. You are prisoner of the vendor's whim. (compare that with emacs where you have all the sources, and that you can easily modify while working on it, with emacs lisp).
Each target platform has its own IDE, with of course, different features, different key bindings, etc. So their high level refactoring and editing tools might be good and nice, but having to a different cockpits leads to cockpit errors, and slower workflow than when you can use the same environment to do everything, including all your programming whatever the target. This is further compounded by the ease of customizing, which is usually abysmal (compared to say, emacs).
Composed with the above two factors is the temporal stability of the tool. Vendor's IDE will change every year or two. Not fundamentally, but sufficiently to be quite irritating (new features to learn, but foremost features you used and like that disappear!). Compare that with eg. emacs, which is basically the same environment since 1983 (of course, it has a lot of new nice features, but the custom commands and customizations you could have written in 1983 will still run the same to day and in the future).
Already, you have here very strong points: instead of being a newbie at an IDE that changes every time you get a new project or the vendor feels the marketing need to provides a reformed IDE, you basically start over being a newbie at the IDE again. Some people become experts at being newbies. Compare that with eg. emacs, where you eventually get to have 20, 30, perhaps 40 years of experience, and accumulated personal tools running on it. (and then, there's org-mode!).
But the question is not specifically emacs vs. editor, but also simple editors. And here, there's a more fundamental question that has not really been studied AFAIK. While it is very nice to have for example a structured editor, being able to work at the level of characters, which is a lower level than the syntactic level you would think you'd like to work to edit programming languages seems to be very important and the differentiating feature. Yes, IDE let you edit text too, but their stress is on high level refactoring tools, and with automatic code completion, validation, insertions of whole statements, or code template, etc. They don't have the same powerful tools to manipulate the text at the character level as normal simple editors (and much less emacs) have.
I guess the importance of the character comes from some advantage it has. Compared for example to ideograms (or emojis!), because there are a small number of them (unicode non-withstanding), and that you can combine them easily to make words and other symbols. So the freedom you have normally at the syntactic level, you get it also at the lexical level, which let you switch to different languages using always the same tools, the same character-based editor.
For example, this will let you start from a specification document or some data table, and by editing it and transforming it semi-automatically (search-and-replace, regexps, etc), end up with some program in some language very easily. (Even more easily when you can add on the run your own semi-automatic or automatic transformation code in emacs lisp).
Which is not to say that structural editing is not nice; we have a few such mode in emacs; but it's important to be able to fall down to the character level easily.
Working with an IDE is like playing with meccano or with construction toys like The Source, where you have pre-defined blocks that can be combined only in pre-designed ways. Working with more simple editors at the character level is like playing with play-do (or basic lego blocks) where you can sculpt and model your code in funnier and more various ways.
Oh, and there is also the antagonism between the "Integrated" part and the open side of normal editor, and even emacs retains it (after all, compilers apart from the emacs lisp compiler are not integrated into emacs). This is the big win of the unix philosophy: to have simple tools that you can combine easily one with another to perform your work. So with simple editors, unix is your "IDE", and it's open to all the programs and tools you can have available on your system, while it's usually mode difficult to use external with IDE (some of them are more open than others, but it still doesn't feel all that easy, and foremost, it's always change from one version to the other).
Ankush Thakur Github logo
1) How often do you actually find yourself modifying the source for emacs? If you never do it, then it's not really important. And if you DO, then perhaps paid software, with a dedicated team of full time developers, provides a more stable experience out of the box that requires no editing. I have never felt the need to modify the source of an IntelliJ IDE, but much of it is open source anyway. And I can always write plug-ins.
2) IntelliJ has an IDE for everything. I use:
And they all work the same. They have the same right click menus and keyboard shortcuts.
3) I started using IntelliJ products 5 years ago when Android forced the switch from Eclipse to Android Studio. I have NEVER, in 5 years, experienced what you mentioned. Not from the IDE. I HAVE, however, had third party libraries completely depricate their public API to replace it with something entirely different on numerous occasions (I'M LOOKING AT YOU FACEBOOK.) And in those instances, with an IDE, it was trivial to refactor my code to handle the underlying change. Even when the community switches gear entirely, IDEs help. When Android switched to Kotlin, Android studio added various options for converting your code from java, piece by piece. Sure the resulting code wasn't optimized, but it was good enough to work from. You're not going to get any of this from emacs.
I use vim daily to modify text files and remote source files, don't get me wrong. But an IDE of some sort would benefit most developers. From static code analysis that prevents runtime errors, to point and click breakpoints, to code coverage highlighting, to code macros, autocomplete, automatic PEP8 formatting, right click refactor, alt enter for auto import, spell check, etc. These are just everyday features that every developer could benefit from. Some of which can be made available in emacs or vim via plug-ins or using other tools, but it's far simpler to have everything in one place.
I work in the same IDE (IntelliJ Idea) with the same experience and shortcuts for different environments, languages, and frameworks. Let’s see… This includes:
I’m using IDE for about 3 years now, and I didn’t have this problem. So far it seems like new features only get added. Old ones that I like—stay. Maybe 3 years is not enough, let’s see what happens in 5-10 years time frame. Also, is it a huge issue? I mean our libraries and frameworks change much more often than that.
About the high-level blocks: interestingly enough that these blocks correspond very well to Simple Patterns and Atomic Refactorings. These didn’t change much in the last 15-20 years. So actually, I like these “rails” that allow for the smoother application of what is proven to work well.
I don’t want to have a “custom-crafted style” of my codebase design. The poor new team member who’ll have to understand this unique style…
Good point about the Unix philosophy!