I think his point is that if you were the type of developer who uses an IDE, you are willing to accept the slow start up time. You clearly are not willing to deal with that, and as such are not ever going to be happy.
Some tools take a while to warm up, use them or don't.
I am the type of developer who uses an IDE. The problem is that I would usually get my work done in Vim while waiting for the IDE to load. After a few instances of finding myself working in Vim with Eclipse loaded and idle in the background, I just stopped opening Eclipse altogether.
As a regular IDE user (Visual Studio, PyCharm, WebStorm) there is no way I would forgive a few minutes loading time. Of the IDEs I use PyCharm is the slowest at perhaps 15-20 seconds to start up, and I consider that barely acceptable. Had it not been such a great product once started up I doubt I'd be as forgiving about its start up time as I am.
> You clearly are not willing to deal with that, and as such are not ever going to be happy.
I'm pretty happy in Emacs. I'm not happy with false dichotomies, like this features/speed tradeoff. There is a real tradeoff to be made between those, but nowhere near the level I've seen in IDEs.
Many problems seem to depend on the way modules/extensions are implemented.
For example, we could implement plugins by allowing event listeners which can run arbitrary, imperative code. However, this leads to redundant computation (multiple "get(foo);" and "set(foo, bar)" calls spread across listeners), increases the chance of plugins conflicting due to race conditions, requiring very conservative scheduling, etc.
An alternative, like a hook/advice system, would have the core performing gets/sets exactly when they're needed, but give plugins the ability to override the return values using hooks (like a dynamic form of decorators). This avoids the redundancy, race conditions and scheduling issues.
Some tools take a while to warm up, use them or don't.