Live data from Hacker News

Goism – Use Go instead of Emacs Lisp inside Emacs

github.com

21–30 of 78 posts

Re: Goism – Use Go instead of Emacs Lisp inside Emacs

#22
post #12
post #8

Earlier 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…

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

Re: Goism – Use Go instead of Emacs Lisp inside Emacs

#23
post #14

Earlier 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…

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.

Re: Goism – Use Go instead of Emacs Lisp inside Emacs

#24
post #16
post #11

Earlier 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…

I don't actually see the advantages for JavaScript. Seems every other month there is a new way to package it. So, everyone might know how to build with it, but few people know the same way of building.

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

#25
post #9

I 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…

I used Emacs Lisp for scripting tasks like code and data generation. It is great to have an ability to evaluate form right inside the spot you want results to be inserted. This kind of code does not require AST manipulations or macro.

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

#26
post #22
post #12

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

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.

Re: Goism – Use Go instead of Emacs Lisp inside Emacs

#27
post #21

Is it possible to have a language transpire/compile to elisp?

It is possible to emit Emacs Lisp instead of bytecode/lapcode. This was the first code generator target actually.

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

#28
post #17

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

Re: Goism – Use Go instead of Emacs Lisp inside Emacs

#29
post #17

Earlier 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…

It's a lisp. That is enough for a lot of us to want to use another language, irrespective of how much Emacs lisp improves.

Re: Goism – Use Go instead of Emacs Lisp inside Emacs

#30
post #8
post #6

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

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)?

Post reply on HN