I haven't tried the linked package, but it seems like the idea is that it can be used alongside Lisp. If so I'm not fully understanding how this isn't a reasonable idea. Surely _being able_ to use Go is not a bad thing and not useless?
In practice, it's close to useless. A lot of the power of Emacs comes from the homogeneity and that Emacs itself is mostly written in Emacs Lisp.
There have been attempts in the past to do similar bridges to Python and Javascript IIRC, but they ended up nowhere since they didn't mesh well with the existing ecosystem.
No matter how bad people think Emacs Lisp is (an incorrect impression, Emacs Lisp has improved tremendously) it's still a powerful Lisp and only a Lisp would provide the powerful extensibility that Emacs has.
I don't think the author is challenging most of the notions here. In fact, it seems pretty well inline with this.
I think language bridges suck, but this isn't one. It transpiles Go to Lisp bytecode, making it much closer to a first class citizen.
But more importantly, the tagline of the project isn't "Let's write Emacs in Go," nor is it "Emacs Lisp is bad," it's "Not a fan of Emacs Lisp? Hack Emacs in Go!" -- that seems pretty straightforward to me. The aim of this seems to be potential Emacs users who do not code Lisp and don't like it. There are plenty of reasons to not like Lisp, not just Emacs Lisp, including the power that it possesses, just like there are plenty of reasons to not like Go. To suggest otherwise would be elitist.
The way I see it, the potential here is to open Emacs scripting up to a wider audience of people who are not necessarily all the same kind of programmers, who may prefer more typing to more magic.
I hope you're asking in good faith and don't really think Lisp is actually the best at everything.
Since you asked though, I'll go into my personal list. You'll note that much of these can just as easily be advantages depending on the situation and I'm by no means saying that this list applies to all things and all people (in fact it objectively doesn't.)
- The syntax: duh. Its elegant in how it mixes code and data, and unifies so much functionality into one syntax. But it has a number of disadvantages. One, the number of parens is cumbersome. You can get used to it, but it's still cumbersome. Two, it isn't always intuitive; sometimes infix syntax just plain feels ergonomically better, all flaws aside. This can absolutely be said about math. Lisp takes order of operations out of the picture, but the same would be true if you threw a shit to of parens into any language, so I feel that doesn't count.
- It's absolutely magical. It's so powerful that I wouldn't trust most programmers to wield it. It's so powerful I wouldn't trust me to wield it. I like programs that are obvious. One of Go's strengths is that it is very stupid, for example, leading to stupid code that is stupid readable by anyone (even if they're.. you get the idea.)
- Lisp feels like the world of wheel reinvention. I don't know if that's due to the language or the community that surrounds it, but I'd guess it's at least a little bit of both.
- Lisp is a dynamic language. By nature this is going to mean you can do less things with code statically. I'm a big fan of static typing for the obvious advantages it brings to larger projects.
- Finally, comfort. Lisp is obviously a language that has stood the test of time, but even despite that Lisp programmers are far and few in the industry. Most people are going to be familiar with imperative programming languages based off of C like syntax, or maybe something closer to Python. Either way, if you pick a random programmer off the street, you wouldn't assume they knew Lisp. (Unless their beard was really long.)
The question was in good faith and I sincerely thank you for such a well-written reply.
I think some of your points are valid, although some of them (syntax and static typing vs dynamic typing) are mostly down to preferences or getting used to different ways of working.
I think, for example, that, given the choice between those two, i'd rather have macros (lisp macros) instead of static typing.
As for the beard comment, yes, the longer the beard, the easier is to get into Lisp.
I just wanted to note, however, that Lisp is an imperative programming language, just as C or Python is. (Of course, Lisp also allows functional programming and Common Lisp allows fantastically good object oriented programming). So yes, i agree, "most people are going to be familiar with imperative programming languages based off of C-like syntax". But on the other hand, Lisp syntax is much easier to learn than C-like syntax.
If you don't like Lisp for editor programmoing, then an editor which is literally built upon a million lines of Lisp code seems to be a very bad choice. Even providing another extension language won't make the Lisp go away.
The implementation language does not matter to me - I'm not working on the code base, and have no interest in doing so. I don't care that there is lisp there, as long as I don't have to write it.
But this is the point that you're completely missing. Perhaps you have not spent a lot of time with Emacs?
The implementation language does matter a lot in this case, because the part of Emacs that is written in Emacs Lisp (~90% of Emacs) can and should be leveraged (modified, extended or used to build upon) at runtime by users. This is what gives Emacs it's tremendous flexibility and power.
Using anything other than a Lisp with semantics close to Emacs Lisp for user code that leverages what Emacs offers built-in, will be an exercise in frustration since a lot of the power I described will be so cumbersome to access and make use of. It's been tried before, multiple times by people not very familiar with Emacs Lisp, and it has never worked out.
Experienced Emacs Lisp developers immediately understand the futility and pointlessness of such endeavors which is why you never see them attempt them.
'Not useless' is not a high enough bar in software. Flexibility always adds complexity, and complexity is a cost. Sometimes that cost is worth it, but the benefit needs to be much larger and clearer than 'not useless'.
Not a high enough bar for what exactly? So far this entire thread is a lot of vague talk spawning off the idea that it doesn't solve a problem. That's the statement I don't agree with. If enough people decided to use it, that's the only bar that actually matters. But it clearly solves a problem, just not necessarily a problem every Emacs user has.
