[jlarocco]

Another case where it'd be nice to have a "Why are we doing this?" section in the README.

If it's just a demo then it's neat. Interesting that it can be done.

On the other hand, if it's a real push to get people scripting Emacs with Go, then I don't see the point at all. It's solving a problem people don't really have.

[hk__2]

> It's solving a problem people don't really have.

Isn’t "I want to script Emacs but I don’t like LISP" a problem to solve?

[ajarmst]

You're postulating a population that are willing to take on the cognitive burden of learning Emacs but who are unwilling to do the same for ELisp. I think that's a smallish population, almost entirely composed of people who want a Scheme, probably Guile, instead (but, like me, are plugging along in Elisp in anticipation of Emacs-Guile potentially shipping before the Rapture). People who want to script in Go, Common Lisp, Javascript, C, Fortran or the Power of Christ are currently pretty much entirely confined to the immediate teams working on those various projects. More power to them, no one who loves Emacs should ever tell anyone 'no, that's not appropriate for Emacs' (I think we established a pretty long time ago that weird esoteric projects out of left field are basically Emacs' wheelhouse, and often turn into really important sub-projects). But, I'm not interested, and I don't know any regular users of Emacs who would be.

[kazinator]

I've actually met many programmers who used Emacs but knew zero Lisp of any kind, including Emacs Lisp. They were just happy using the available goods without looking under the hood.

I don't think it's that unusual. Emacs is quite popular. If even 25% of the user base coded in Lisp, it would be ... astonishing.

[ajarmst]

Absolutely. But I think that, when those programmers do decide "hey, now I want to write some custom code for Emacs", they don't then think "but not in Elisp".

[disgruntledphd2]

It's pretty easy to get started coding in elisp. You essentially start doing it every time you use any command, so there's a mapping from a manual change to scripting it.

Source: am Emacs user, have a few (not a lot) functions that I cobbled together from things I did all the time.

[jlarocco]

Are there many (or even any) people in that situation, though?

Who decides they want a script-able editor, but then chooses one scripted in a language they don't like and don't want to learn?

[hk__2]

> Are there many (or even any) people in that situation, though?

Probably not (except those who made that project).

> Who decides they want a script-able editor, but then chooses one scripted in a language they don't like and don't want to learn?

Mostly because the scripting language is not the first thing you think about when using an editor (just guessing here; I don’t have data on that). I started using Vim because its editing capabilities are quite powerful but its scripting language is really bad. Emacs’ LISP is great, but I can’t get used to the way Emacs commands work.

[weaksauce]

Why not? Elisp is not amazing but having a DSL and powerful metaprogramming lets you script things so much easier than a lot of languages. Viml is atrocious. There are some libraries tha use the metaprogramming to make it easier to program in as well. Vim is a good idea and makes editing text nice to use. Emacs is a good idea that everything is customizable and has a good level of abstraction to make things happen. Using evil inside Emacs makes a great editor. Spacemacs makes Emacs easier to use too with the mnemonic and ergonomic bindings and a mostly good ootb experience for how young it is.

[jakebasile]

I'd say the problem in that statement is "I don't like Lisp", and we should solve for that :)

[ue_]

A better thing to answer would be why people prefer less powerful languages to the more powerful, and what can be done about it? Framed that way,this seems like an XY problem.

[quasilyte]

Some optimizations are easier in Go than in Emacs Lisp, hence the potential quality of produced bytecode can be higher. For big packages that can be implemented in Go naturally (nearly without pain), this can be an advantage.

I found some optimizations that are not implemented inside Emacs lapcode optimizer. If I will port them to byte-opt everyone win, right (if they pass Emacs team review, of course)?

[jchw]

>why people prefer less powerful languages to the more powerful

Clearly, power is the only measure one should consider when picking a programming language. And Lisp surely has more power than Go. I'm going to guess 36.1% more power, to be exact.

>and what can be done about it

We could always start performing eugenics to get rid of them.

... Okay, I apologize for being an ass. But I hope my points aren't lost; the way you're phrasing things makes it feel like you're bitter that anyone would consider using something that's not Lisp.

[ue_]

>I'm going to guess 36.1% more power, to be exact. Where's this figure from?

>We could always start performing eugenics to get rid of them.

I meant more like what we could do to improve the more powerful languages to make them more appealing.

I'm less bitter than I am perplexed about the choice to use Go over Lisp.

[jchw]

It was sarcasm. Obviously one can't objectively measure the power of two languages. I assume you mean it has more powerful metaprogramming than Go, which is what everyone else is saying.

But I find the rhetoric quite closed-minded, because I doubt any of the people replying here who've just found out about this and are calling it a bad idea have actually tried it yet. Clearly, there are advantages to Lisp that you would lose if you tried to do something in Go. But nobody is acknowledging the reverse, that there may also be advantages in Go to Lisp that are unforeseen, even for this specific task.

All in all this is a disappointing development. I don't think it would go over the same in other text editor communities, because people seem very defensive about the use of languages in place of Lisp where they might not be so defensive about the use of languages in place of say, VimScript.

[saghm]

I think GP's idea was that having a more flexible language is specifically useful for configuring Emacs, not that Lisp is better than Go in every imaginable case.

[jchw]

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?

[armitron]

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.

[nbouscal]

'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'.