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).
About open/close software. The IDE that I’m using is paid, but the major part of the IDE is open-source as in IntelliJ Platform and Idea Community Edition. Which means that your statement would only be partially true—for the paid features.
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:
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.
Now, I’m pretty sure I could use even more languages/platforms, I just don’t need them. To me, it seems like the assumption that one IDE per platform seems weak here… For me, it’s single IDE for every platform (that I ever need(ed) to work with).
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…
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:
Pycharm for python
Webstorm for javascript
Datagrip for sql
Android Studio for Android
CLion for c++
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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
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!
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.