guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FOSDEM 2019


From: Alex Sassmannshausen
Subject: Re: FOSDEM 2019
Date: Wed, 06 Feb 2019 13:46:54 +0000
User-agent: mu4e 1.0; emacs 26.1

Christopher Lemmer Webber writes:

> Arne Babenhauserheide writes:
>
>> Mikael Djurfeldt <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]