unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Christopher Lemmer Webber <cwebber@dustycloud.org>
To: Arne Babenhauserheide <arne_bab@web.de>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: FOSDEM 2019
Date: Tue, 05 Feb 2019 16:25:17 -0500	[thread overview]
Message-ID: <87ef8mc4hu.fsf@dustycloud.org> (raw)
In-Reply-To: <87o97sv51q.fsf@web.de>

Arne Babenhauserheide writes:

> Mikael Djurfeldt <mikael@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 :-)
>
> The talk by Christopher Webber basically described the importance of
> shiny — all the bits other people already polished. A similar argument
> cuts for using Python, and even Java.
>
> This does not make it invalid: Chris is right that shiny is important;
> but it is not all-important, especially not in the long run. And
> different from many other projects, Guile takes the long run seriously.
>
> 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 stand by that there are a bunch of cases where catching up to
Racket appears hard, but one thing we didn't catch on camera
unfortunately is the great conversation we had in the cafeteria on
Sunday about Guile and Racket and where their strenths are and how to
learn from and collaborate with each other more.  So allow me to provide
an addendum to my talk, based on the conversations we had:

 - Guile and Racket may sometimes have some different domains where
   they're excelling, and that's okay and good

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

 - Wingo put forward that Mes and Guix are examples of projects that are
   already pushing Guile's community in the right direction.  And it's
   clear that Guile is growing a lot.

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

There's a lot of reason for optimism.  I'm sorry if I applied too much
"stop energy", that's not what I meant to do.  If you watched or will
watch my talk, rather than consider it a "Guile is over, Racket is the
future" type talk, I'd prefer it to be interpreted as "here are some
experiences from an external community that might help us think how
Guile could improve itself and think about where its most useful role
is".

But BTW, I do agree with Janneke's interpretation of my talk about
"shiny matters".  Plenty of sources of glossy finishes we can apply
to our work, so that too is an opportunity for improvement to excite
newcomers more than anything else.

 - Chris



  parent reply	other threads:[~2019-02-05 21:25 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-03 21:34 FOSDEM 2019 Mikael Djurfeldt
2019-02-03 23:13 ` Arne Babenhauserheide
2019-02-04  5:21   ` Nala Ginrut
2019-02-05 21:25   ` Christopher Lemmer Webber [this message]
2019-02-06 13:46     ` Alex Sassmannshausen
2019-02-06 15:22       ` Amirouche Boubekki
2019-02-06 15:33         ` Amirouche Boubekki
2019-02-06 15:42         ` Alex Sassmannshausen
2019-02-06 21:03           ` Ricardo Wurmus
2019-02-06 22:09             ` Alex Sassmannshausen
2019-02-26  8:57             ` swedebugia
2019-02-06 20:40         ` Arne Babenhauserheide
2019-02-05 21:26   ` Christopher Lemmer Webber
2019-02-04 13:06 ` Amirouche Boubekki
2019-02-04 14:44 ` Ludovic Courtès
2019-02-04 18:01   ` Jan Nieuwenhuizen
2019-02-05 11:09   ` Amirouche Boubekki
2019-02-05 16:58     ` Ludovic Courtès
2019-02-06  0:31       ` Nala Ginrut
2019-02-06 12:59         ` Ludovic Courtès
2019-02-06 19:09           ` Amirouche Boubekki
2019-02-06  0:37       ` Matt Wette
2019-02-06  0:56         ` Nala Ginrut
2019-02-06  1:40       ` Amirouche Boubekki
2019-02-05  2:30 ` Matt Wette
  -- strict thread matches above, loose matches on Subject: below --
2018-08-21 13:33 Manolis Ragkousis
2018-08-21 17:57 ` Ricardo Wurmus
2018-08-22 16:27   ` Andy Wingo
2018-08-22  2:33 ` Mike Gran
2018-08-23  0:08 ` Mike Gran
2018-08-24 12:23 ` Christopher Lemmer Webber
2018-08-29 21:08   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ef8mc4hu.fsf@dustycloud.org \
    --to=cwebber@dustycloud.org \
    --cc=arne_bab@web.de \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).