> Interesting point. I think that could work, but wouldn't it be much easier if the language itself was self-documenting?
Maybe, but that entails changing the language, by definition. And you
will face resistance because languages are things people kinda grow
accustomed to. Imagine if I told you the French language should now
also include all the words of Portuguese, because, you know, they're
just better. Even worse with macros. It's like I told you not only you
have to learn Portuguese words, but its grammar, too.
Well I propose to add new-style APIs. People can still use the old ones.
But yeah, I'm coming to the conclusion that even adding a new-style API is too disruptive. If it happens It'll probably live outside of Emacs in MELPA.
I'm not sure I like this simplification, but there seem to be two communities of Emacs users, the "traditional" one and the "github" one. Both have their perspective on how things should be, and it seems that both communities have trouble understanding how the other community function.
It's been several time now that the "github community" proposed changes that looked "evident improvements" to them but got hit by a wall of incomprehension/complexity (I'm not saying this proposal is one of them, but what comes often is "why not gitlab? how come s.el is not in Emacs core?", etc). I'm not sure if there is a way forward on this, it just is that way. I hope that in the future we can understand each others better and find good compromises quicker, without all the noise.