
GNU Guile v2.9.2 – an embeddable REPL for scripting your GUI - bleair
https://lists.gnu.org/archive/html/guile-devel/2019-05/msg00030.html
======
Riverheart
Anybody know what the high level overview of embedding guile into an
application looks like?

~~~
armitron
My team tried doing it once and we decided against it after running into
problems with the number of Guile dependencies. We moved to Lua (0
dependencies) soon after. Guile may have more features but Lua (and Luajit) is
really the undisputed king when it comes to embedding and flexibility in terms
of merging it into your codebase and molding it to your exact requirements.

~~~
avar
What was the cumulative size of those dependencies when statically linked?
I've never understood why some shy away from "number of dependencies" per-se
for C projects, worst case you ship some of them with you, but perhaps the
real problem was "prohibitively large object" once it was all compiled
together.

~~~
Crinus
Each dependency increases the cognitive load for maintenance (something goes
wrong/is slow/doesn't compile in that platform or requires steps incompatible
with the rest of the project/other issue, is it me or the 20839423 libraries i
depend on? How does that library that has the issue work? How do i fix it?
These are things C programmers tend to care about) as well as reliance on 3rd
parties to stay in line with your needs (e.g. you may want to stick with C89
but a library you depend on - or a library a library you depend on depends on
- decided to raise minimum requirements to C99 "because everyone has that now"
or one of your dependencies stops development for whatever reason - in either
case you are left with the choice of dropping the dependency - and anything
that depends on it - or taking over maintenance for something you decided to
use in the first place to avoid that sort of work).

~~~
avar
Very little of what you mention would apply to the GP since they're not in the
position of maintaining guile, they're a 3rd party user who'd be packaging it
and its dependencies up for use in their own application.

Guile's list of mandatory dependencies is short, and consists of libraries
like libgmp (also used by GCC), libiconv etc., I doubt a packager would have
much issue with the stability of those. These are libraries that work on
dozens of platforms across a wide range of compiler versions:
[http://git.savannah.gnu.org/cgit/guile.git/tree/README#n20](http://git.savannah.gnu.org/cgit/guile.git/tree/README#n20)

More generally the trade-off with libraries cuts both ways, and I've seen
other programmers underestimate the maintenance burden of rolling their own
v.s. the investment in just including a well-tested third-party library. E.g.
it's very common for C programs to have their own buggy and often insecure
version of something like a string library, DNS resolver etc.

That's not free for you as a user of those programs either. E.g. the other day
I was dealing dealing with an issue in how bitlbee resolves SRV records with
its own home-grown code instead of using something like GResolver, which
wouldn't have had that issue.

~~~
Crinus
My comment was about the <<I've never understood why some shy away from
"number of dependencies" per-se for C projects>> part, not Guile itself
although it also applies to what you wrote, specifically this:

> they're not in the position of maintaining guile, they're a 3rd party user
> who'd be packaging it and its dependencies up for use in their own
> application.

...as it doesn't matter if they are using these other dependencies directly or
indirectly, they are still dependencies of their application - if anything
these are dependencies they didn't have any say over (they had say over
depending on their direct dependency - like Guile - but not on their
dependency's own dependencies which were decided by the programmers of that
dependency) so they have less knowledge on how those are used and why they are
used (knowledge they may need to gain in the case where something goes bad as
i wrote above).

Basically the more dependencies you have (not necessarily the number of
libraries you depend on but also how much of each library you are using), the
more people you invite to have a say in how your project will work and as such
the more likely to encounter friction and misaligned goals.

This is why a lot of C programmers prefer to use small single-purpose
libraries (to the point where "single header libraries" have taken off
significantly) and avoid huge "multitool" frameworks.

> its own home-grown code instead of using something like GResolver, which
> wouldn't have had that issue.

Perhaps, but it may have had other issues you (or even the programmer who
wrote that code) didn't know about.

~~~
avar
At this point we'd be better off with the GP chiming in, what I was responding
to was "after running into problems with the number of Guile dependencies".

So not the stability of the dependencies, or any specific issue with them,
just the number of them.

In practice I've encountered a lot of cases where C programmers in particular
tend to get what's best described as dependency vertigo resulting in badly re-
inventing the wheel.

I'd be much more confident in using Guile with its 10 dependencies (or
thereabouts) than some random similarly-sized C program.

Something the size of Lua or Guile isn't someone's weekend project. No matter
what other people have a say in the direction of your program. I'd argue that
you're generally better off structuring it in such a way as to make use of
already-invented wheels, and users are better off not shying away from
dependencies.

We're not talking about something like the absurd 100-line dependencies
node.js has made famous, but whether a compiler like Lua needs to implement
its own bignum handling (or as it at all), v.s. Guile doing the same via
libgmp, and thus sharing bignum behavior with something as well-tested as GCC.

If you're a Guile core developer would you rather e.g. deal with guile's home-
grown text encoding library or iconv? I know which one I'd pick both as a
developer & user.

