Christopher Lemmer Webber writes:
> Arne Babenhauserheide writes: > >> Mikael Djurfeldt <mik...@djurfeldt.com> writes: >> >>> It was a great experience and joy for me to meet some of you at FOSDEM >>> 2019. Thank you all! >> >> Thank you, too! >> >>> Now a piece of advice. >>> >>> Everyone who works with Guile knows that it's crap and look with envy at >>> projects like Chez and Racket, right? >> >> I’ll ignore for a moment that this is a rhethoric method and answer >> directly: No, I don’t think that Guile is crap. It is actually really >> good, and while there are missing parts, I enjoy working in Guile more >> than I enjoy working in Python. Even when I use parentheses :-) >> >> [...] >> >> And seeing my scripts finish within 60ms is impressive. It’s not yet >> perl-level startup-time, but it already beats Python (by a narrow margin). > > I regret that I didn't convey the right energy at the end of my talk. > I actually think Guile is in a better space than it's ever been as far > as I've been looking at it and I see an amazing future ahead for it. > > [...] > > - I do think it's true that Guile doesn't have as good of a story as > Racket in terms of getting people new to lispy languages in the door. > But! We actually had a really nice discussion about how to maybe do > the right thing to improve things for Guile. Part of that > conversation was "Oh hey, what if we took Spacemacs as inspiration? > What if we had an emacs distribution that came that was preconfigured > for people familiar with classic IDEs and which is set up and easy to > use Guile with?" This would also allow those users to "grow into" > Emacs as an editor. (I've jokingly called the idea GuileJr in the > past but it badly needs a less diminuitive name. ;)) I think this is a really valuable next step in improving our approachability for sure. I'm very interested in this, and might start looking at this next. > - Janneke mentioned the new guile build system in guix for simpler > guile packages and I think that's pretty great. Likewise there was > some mention of some sort of you-don't-have-to-use-autotools build > system and I don't remember what it's name was. (BTW, I continue to > believe that "Guix is and should be Guile's package mangager".) I was unaware that we had a guile build system in Guix. My understanding is that the Guile experience in Guix is still a bit janky — we need to wrap binaries manually; dependencies alas must be propagated… In the past I was the one who argued strongly for the build system and for the no-autotools approach — I believe in the context of outreachy. Unfortunately I was unable to make that part a reality. Even so, I have been developing a solution that is part of this discussion in the form of Guile Hall, which is a project manager for Guile with strong integration with Guix & Autotools. I will be pushing out a new release after some bug fixes with the help of Cato and Ricardo. At that point I'm fairly happy with the usability of the project. I could imagine an Emacs interface for Hall, in a similar vein to the Guix interface, which both combined could provide a ton of the functionality that our "Spacemacs" might provide. As an aside, Hall circumvents the jankiness of Guile in Guix & Autotools by being able to generate elaborate Guix recipes and basic autotools infrastructure. As you can see, I have a horse in this race. I would be very interested in collaborating with others who feel strongly about this part of the Guile/Guix user journey — either on improvements to Hall, Guix or on other tooling. Best wishes, Alex
