Goism – Use Go instead of Emacs Lisp inside Emacs
21–30 of 78 posts
Re: Goism – Use Go instead of Emacs Lisp inside Emacs
#22Earlier quoted context omitted.
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.
>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…
>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.
Re: Goism – Use Go instead of Emacs Lisp inside Emacs
#23Earlier quoted context omitted.
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?
> 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 becaus…
Re: Goism – Use Go instead of Emacs Lisp inside Emacs
#24Earlier quoted context omitted.
I don't think inferiority of language is a strong argument either. JavaScript is pretty inferior as a programming language but that doesn't seem to have affected its popularity much.
I think that's neither here nor there. JavaScript has a lot of strengths that few other languages can claim at this point, thanks to how universal it is. Many people understand it, it can be used to build everything from desktop apps to mobile apps to servers, and it has one of the largest package repositories out there. I'm far from a JS fanboy but I think your point lends credence to the idea of using JS more than…
Similarly, the package repository is not exactly inspiring. Similar patterns of many packages doing the same thing. Often not bringing new advantages to the table, so much as revising old weaknesses. Many rooted in choice of language.
Which is actually not too complain of JavaScript. I do like it. And I love that people are empowered to try things. Even if they were previously done. I do wish people knew more options, though. Including myself.
Re: Goism – Use Go instead of Emacs Lisp inside Emacs
#25I haven't taken an incredibly close look at this, but it seems like a pretty bad idea. Elisp is definitely not a great language, and I'd like an alternative as much as the next Emacs user. But I feel pretty strongly that any alternative has to be a Lisp, or very close to one. Code-is-data/data-is-code is very important for the more "config-file" aspects of configuring Emacs. Being able to use and write DSLs to succin…
Also, some of my projects that become bigger than 1000 LoC could benefit from static typing and (subjectively) better tooling.
By the way, I think extending Emacs in Racket would be great; just do not have an idea on how to implement that integration smoothly.
Re: Goism – Use Go instead of Emacs Lisp inside Emacs
#26Earlier quoted context omitted.
>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…
>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.
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.
Re: Goism – Use Go instead of Emacs Lisp inside Emacs
#27Is it possible to have a language transpire/compile to elisp?
Easier to debug, simpler to trust (for the end user) and not that hard to generate.
The problem is that it is harder to implement some features of Go in terms of Emacs Lisp without going down to the virtual machine level. Best examples are arbitrary return statements (can be emulated by throw/catch) and goto.
Re: Goism – Use Go instead of Emacs Lisp inside Emacs
#28Earlier quoted context omitted.
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 tremen…
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.
Re: Goism – Use Go instead of Emacs Lisp inside Emacs
#29Earlier quoted context omitted.
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 tremen…
Re: Goism – Use Go instead of Emacs Lisp inside Emacs
#30Earlier quoted context omitted.
> 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?
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.
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)?