Emacs is use optimized, not learning optimized. It takes lots of time -- if you don't use it for hours a day, it is probably not worth it.
Org mode in Emacs is a good example. It took embarrassing long to learn for me -- while the GUI variants (e.g. gjots2) are trivial.
But now, I can take notes and doodle with Org mode that I could only do on paper before. It is built into my fingers in a way which IDEs/GUIs failed for lots of years.
I'd argue that Emacs is without a wall for programmers. (-: As long as you don't want to do word processing with WYSIWYG. :-)
The problems will be new areas, like how will text understanding libraries (theoretical concept, not in that area) integrate with Emacs compared to others.
You could probably do the same arguments for Perl and Lisp. But I don't know any framework I'd say the same about.
Edit: Thinking back on my life, I'll yield the point re frameworks. Not libraries, for a not too large problem (a pack of collected libraries would have a wall in a bad Big-O for complexity/time).
Edit 2: You could put my argument to be that the last decades of history shows Emacs to be, for all practical [programmer] purposes, infinitely flexible -- as long as new functionality can be integrated to the normal Emacs usage. Which is a big caveat, yes. Org isn't the first generation of that kind of note taking modes in Emacs, the evolution was afaik in much how Org was used.
Emacs might be insanely flexible, sure, but at what cost? Bloat? Infinite complexity? Heck, I get frustrated with my VIM configuration sometimes because I forget the less used keybindings when I really need them, and need to go spelunking.
So sure; if you're willing to trade the up-front investment of time (not insubstantial) Emacs will go far - and the wall is way off on the horizon and someone scribbled "complexity" on it.
Up-front investment can't be underestimated; there's a reason why things like Textmate (which starts simple, and grows out well) are so popular. Low initial investment, and plenty of ramp, and it works out well until it simply doesn't.
That low initial barrier is easier to climb, and while emacs (or even VIM) might have a wall that, when compared to Textmate's, is infinitely far away, textmate will still have fantastic adoption. The wall textmate has is further off then most people are willing to worry about.
For most people, a framework, like, say, Django or even Rails offers a wall far enough out that most people don't need to worry about it, but when they hit that wall, they're going to hit it hard, and kinda be mad.
You're mostly rewriting my points. Let's leave this for half a year and discuss it again. It seems we both need to let it fes.. think about it. :-) Or at least I know I do.
What I'm trying to say, I think, is that there is a tension between flexible/pluggable frameworks and integrated ones, like with e.g. Emacs and simple IDEs. (Yeah, there are IDEs on top of Emacs; those doesn't remove complexity.)
(The main complexity problem with Emacs isn't the code which is neat with the lisp layer (imho, I'm very far from being a real Emacs hacker). The complexity is use complexity -- lots of modes, etc. More broad than deep.)
But unless some totally new idea comes along, people will use Emacs when we both have forgotten the present frameworks...
>>I get frustrated with my VIM configuration sometimes because I forget the less used keybindings
I haven't used vi for quite a few years. There is still no good search/browsing/M-x? Never mind, some really good people use vim, so I assume there is something there.
Emacs is use optimized, not learning optimized. It takes lots of time -- if you don't use it for hours a day, it is probably not worth it.
Org mode in Emacs is a good example. It took embarrassing long to learn for me -- while the GUI variants (e.g. gjots2) are trivial.
But now, I can take notes and doodle with Org mode that I could only do on paper before. It is built into my fingers in a way which IDEs/GUIs failed for lots of years.
I'd argue that Emacs is without a wall for programmers. (-: As long as you don't want to do word processing with WYSIWYG. :-)
The problems will be new areas, like how will text understanding libraries (theoretical concept, not in that area) integrate with Emacs compared to others.
You could probably do the same arguments for Perl and Lisp. But I don't know any framework I'd say the same about.
Edit: Thinking back on my life, I'll yield the point re frameworks. Not libraries, for a not too large problem (a pack of collected libraries would have a wall in a bad Big-O for complexity/time).
Edit 2: You could put my argument to be that the last decades of history shows Emacs to be, for all practical [programmer] purposes, infinitely flexible -- as long as new functionality can be integrated to the normal Emacs usage. Which is a big caveat, yes. Org isn't the first generation of that kind of note taking modes in Emacs, the evolution was afaik in much how Org was used.