31–40 of 64 posts
I usually use Common Lisp and when I use a Scheme-like language I usually use Racket. However, projects likes Guile (great for scripting applications, the web framework is cool), Chez, and Gambit are much appreciated (I use them all, at least a few times a year).
I know that Lisp languages are not the best tool for every application, but using Lisp languages makes me happy so I try to use them whenever possible.
Is there still any work being done on Guile Emacs? As I recall it basically worked a few years ago, but it doesn't seem to be maintained. I'm curious if these 3.0 speedups would translate there too.
Is there still any work being done on Guile Emacs? As I recall it basically worked a few years ago, but it doesn't seem to be maintained. I'm curious if these 3.0 speedups would translate there too.
No, I don't think anyone's working on this. It is also very unclear if it is really worth the effort (for a good overview see https://lwn.net/Articles/615235/ from Stefan Monnier, Emacs' ex-maintainer). For speeding up Emacs Lisp, I think the current work done by Andrea Corallo using libgccjit is more promising. Another big boost would probably be to replace the current regex engine with something better.
I feel like the single most important reason Guile is not more popular is the focus on Linux. It is not even as easy to install it on Mac, afaict. I've seen unofficial binary builds for windows but they are hard to find... and probably they use cygwin? I wish Guile was readily available in other platforms (I wish their downloads page looked like this [1]...), but I'm guessing the main reason it is not is more philoso…
brew install guile
-- JavaScript/Typescript for in-browser or even some server-side stuff (e.g., NodeJS)
-- Python seems to be dominant for non-browser code that doesn't need to be fast (or which needs to call Python libraries)
-- C/C++/Rust/C# in the performance space
-- And then the workhorse Bash/ZSH etc for command-line script-fu
I am sincerely asking, what's the nice good fit for a Lisp these days? I know Emacs uses it as its internal language -- fair enough. But other than that.
Thanks and I did not mean to hurt anyone's feelings, I just really am curious.
I would like to ask a genuine question (not trying to provoke anyone!). Where is a good use case for Scheme these days (in any form?). I really love the idea of the language but I can't figure out where it really does a _better_ job that these things: -- JavaScript/Typescript for in-browser or even some server-side stuff (e.g., NodeJS) -- Python seems to be dominant for non-browser code that doesn't need to be fast (…
Is there still any work being done on Guile Emacs? As I recall it basically worked a few years ago, but it doesn't seem to be maintained. I'm curious if these 3.0 speedups would translate there too.
No, I don't think anyone's working on this. It is also very unclear if it is really worth the effort (for a good overview see https://lwn.net/Articles/615235/ from Stefan Monnier, Emacs' ex-maintainer). For speeding up Emacs Lisp, I think the current work done by Andrea Corallo using libgccjit is more promising. Another big boost would probably be to replace the current regex engine with something better.
Earlier quoted context omitted.
> [make guile extensions] Just a note from someone who was bitten by GNU make and guile integration last year. Huge numbers of systems have old make versions with no support for guile extensions¹, and many systems that do have new enough releases require a separate package² to use it. And yeah, I'd written all my fancy integrations before figuring out they'd be worthless :/ It did allow me to noodle over the build sy…
I had the same experience. I think the slow adoption of Make's Guile extension is precisely because of its larger dependency load. If Guile had the same set of dependencies as GNU Make, I bet we'd see more distros turn it on by default.
I'm not sure what that says. `apt install make-guile` vs `apt install meson` don't seem all that different, if it is just about dependencies. I think that means your point on licensing is probably the bigger issue, or that perhaps I just picked the wrong day to open a PR with a guile extension…
Earlier quoted context omitted.
I had the same experience. I think the slow adoption of Make's Guile extension is precisely because of its larger dependency load. If Guile had the same set of dependencies as GNU Make, I bet we'd see more distros turn it on by default.
FWIW, I switched that same project to meson¹ about six months later with no pushback whatsoever. I expected there to be some, but it went through review with uniform agreement. I'm not sure what that says. `apt install make-guile` vs `apt install meson` don't seem all that different, if it is just about dependencies. I think that means your point on licensing is probably the bigger issue, or that perhaps I just picke…
Make's Guile extensions will probably never see widespread use until distro packagers compile them in by default. And distro packagers don't necessarily want to do that, because it would mean a bunch of extra dependencies (including ~100MB of Guile) just to compile a core build-tool.
If `make-guile` remains an optional (and incompatible) package distinct from vanilla `make`, users like us won't be able to rely on its availability. Which means it won't see big adoption by users. And many distros aren't interested in increasing `make`'s dependency footprint to support a userbase that doesn't exist because of chicken-and-egg reasons.