This is a response to Emacs Reddit post: Help us improve the default Emacs out-of-the-box experience. I think I should post it there in its entirety, but being a new Emacs user it may be bad manners to crash in with such a long post.
I think the proponents of the idea are trying to address the wrong problem with Emacs as it is much more than an editor, and this article is rather tangential to their objectives, ie totally offtopic. But the editor boat has already sailed. I have known about Emacs for ages and approached it once or twice in the past then gave up, because it just didn't seem to make sense relative the other editors I had become used to. I am now back to it and appreciate it better because Spacemacs is highly recommended for Elixir development.
I think with Emacs the goal should not make it simply a better editor, ie an editor with a much better OOB experience, but to make it a sound all round IDE for the LISP family of programming languages, OOBE included, with the dialect it is implemented in being (one of) the best of its kind. Isn't it odd that Emacs is used to write programs in languages way less powerful than the language it is written in? It should be upgraded to a Lisp development system with itself as a good example of a complex system engineered in Lisp. Want to learn Lisp? Study the IDE you are using. But it needs to be built on a better Lisp implementation than Elisp.
And if you really need to create a new language your IDE already provides a programming language and the tools you need to create your new language till it gets to the point where it can bootstrap itself, all within the Emacs environment.
Emacs should be promoted as a solid IDE with which you can build everything in, and Elisp should be upgraded to something better as Xah argues here - https://www.reddit.com/r/emacs/comments/696pv1/rms_supports_language_ser.... You are all probably acquainted with https://news.ycombinator.com/item?id=13884322
It is time to go back to the 80s when dedicated Lisp, Smalltalk and Prolog workstations were all the rage, only in this case they are expected to be built on top of a Linux or other similar kernel, Mach perhaps, given its GNU roots. Hackers are supposed to be focused on things they want to do themselves rather than be focused on the desires of corporate masters, who over the years have done everything they can to frustrate them by getting them to shoehorn all the development effort into that energy and time sink known as the web browser. And now they have come up with WebAssembly which is supposed to enable developers to replicate all the stuff they have been doing on their desktop with their desktop tools within the browser, 20 years later.
If Emacs is not going to be the foundation and flagship application for some new fangled GNU Desktop system then at least it should evolve to be capable of being way more extensible than IntelliJ, Eclipse Atom, VSCode and Sublime are, much faster, much more reliably and with fewer resources.
An important thing I want to emphasize here is the transferability of programming code developed in Emacs Lisp. Why develop in a language you can't use easily anywhere else except within the editor itself? Transferability of skills is very important and elisp doesn't help there. All the languages which are considered to have won over languages like Lisp and Smalltalk have standard implementations with only a few insignificant differences. Develop for Emacs (or develop Emacs in) the one true Lisp which is usable everywhere for everything, and you have your winner. I think the Lisp language itself is more important than the editor itself and that should be the focus.
It won't be easy, but if the core is done right, everything else will flow from it. The need to develop a good OOBE for Emacs is important, but I sense the underlying desire is to create an Emacs experience for new users who will go on to appreciate its design. The learning curve will still be present, and the problems of grokking it well enough to customize and extend it for their needs will still exist unless the use cases warrant the effort, and that is unlikely to be the case for a lot of users. They just want to settle down and get going as quickly and intuitively as with the aforementioned competition.