Email or username:

Password:

Forgot your password?
Andrew Tropin

I had a lot of talks recently with Guile hackers, explorers and
educators on the cons and pros of Guile.

One particular issue is a lack of common language idioms and best
practicies. The zoo of SRFIs and ICE-9s, 3 implementation of
exceptions, 3 of records and a bunch more.

On possible solution is a style guide, which contains idioms, best
practices for writing Guile. We can start simple as
github.com/bbatsov/clojure-sty and grow it into
something like practical.li/clojure/testing/u.

WDYT?

#guile #lisp

10 comments
Octorine

@abcdw This is a great idea. It would be amazing if Guile had something like the Rust book.

Andres Moreno

@abcdw

I have been wanting such a thing since I started learning Guile after a few years with Clojure.

Mirko Hernandez

@abcdw This is a great idea. I always have a hard time with idioms in lisp. All the common patterns seem to be already encapsulated in functions or macros so reading code is not as effective as in other languages.

Wolfgang Corcoran-Mathe

@abcdw To my mind, cookbook documents promote “copy & paste disease”: programmers see a snippet or idiom and use it without thinking and without knowing the whole story. And style guides are simply officially-blessed—and therefore more dangerous—cookbooks.

A more useful project might be a series of (meta)libraries that collects related libraries into one easy-to-install, well-documented package. This way, someone who wants to write a small network-oriented GUI program in #Guile could simply grab (easy-networking) and (gui kde), say, and skip digging through the huge pile of half-documented alternatives.

This hints at the fundamental problem: there are not enough polished, tested, and well-documented #Scheme libraries. A cookbook of simple examples of using LIBRARY is little help if LIBRARY is otherwise undocumented, out of date, or simply broken. It’s the basic problem that needs fixing. But this, I fear, is a much bigger project.

@abcdw To my mind, cookbook documents promote “copy & paste disease”: programmers see a snippet or idiom and use it without thinking and without knowing the whole story. And style guides are simply officially-blessed—and therefore more dangerous—cookbooks.

A more useful project might be a series of (meta)libraries that collects related libraries into one easy-to-install, well-documented package. This way, someone who wants to write a small network-oriented GUI program in #Guile could simply grab...

Andrew Tropin

@zipheir Agree, having #lang goodguile or prelude module, which export s a nice set of APIs similiar to clojure.core would be wonderful. However, there is gap in ecosystem to make this possible right now.

Probably, we need to move in both directions at the same time: building a "style guide" and implementing corresponding libraries to fullfil the gaps in style guide.

cc: @baleine

Noé Lopez

@abcdw As someone learning guile for guix how am I supposed to remember all those module names!!! srfi-34 ice-9, give them a name please! Also would be nice if there was some kind of prelude module that had all the common modules exported.

Jeko

@abcdw

Maybe it can help if newcomers can refer to a list of useful dependencies to start different kind of projets. Say web, cli, gui...
i.e. it would not aim to present all existing web server lib, just the one simple enough to get started. Same for databases, etc....
Kind of way to say "you can narrow your learning to this, and still be productive"

Ramin Honary
> "One particular issue is a lack of common language idioms and best practicies. The zoo of SRFIs and ICE-9s, 3 implementation of exceptions, 3 of records and a bunch more. On possible solution is a style guide, which contains idioms, best practices for writing Guile."

@abcdw I think this is a very good idea, although I would prefer the focus be more on R7RS standard Scheme more than Guile. And it will be very difficult since Scheme is not used often enough in industry.

I have been using Scheme myself to create a medium-scale application, and I have already started writing a series of blog posts about my experience, and what I have learned. I am still in the process of revising them, but I hope to publish them in the first week October, hopefully.

The thing is, I still have relatively little experience with Scheme, only about a year using it for real software engineering. So my blog posts are not really about "best practices," so much as they are about discussing the possible pros and cons of various techniques to solve problems. I have upcoming articles on the pros and cons of:

-

Scheme "environment" objects, and how the "load" procedure works across various Scheme implementations


-

Scheme "parameter" objects for dependency injection


-

Scheme monadic programming, including a discussion of SRFI 247: "Syntactic Monads"

I would also love to write articles about unit testing and type checking, but that will take some time.

@SadielEd @baleine @ekaitz_zarraga @ieugen @jeko @kakafarm @mirkoh @monkey1 @octorine @screwtape

> "One particular issue is a lack of common language idioms and best practicies. The zoo of SRFIs and ICE-9s, 3 implementation of exceptions, 3 of records and a bunch more. On possible solution is a style guide, which contains idioms, best practices for writing Guile."

@abcdw I think this is a very good idea, although I would prefer the focus be more on R7RS standard Scheme more than Guile. And it will be very difficult since Scheme is not used often enough in industry.

Go Up