Logo baseline

Logo baseline

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

Hello Guilers!

The Guile logo has this “GNU extension language” baseline.  As Guile 3
came out, this baseline felt odd to me, not quite corresponding to the
way I see Guile.

Clearly, Guile is still an extension language, with many great
applications (Gnucash, Lepton-EDA, OpenCog, GDB, etc.), and I’m sure
libguile is here to stay.  Yet, to me, “extension language” does not
accurately capture what Guile today allows for and what people have been
doing with it; since 2.0, it’s more than an extension language, even
more so with the performance afforded by Guile 3.

Thus, I’d propose changing the baseline.  Something that would describe
what Guile is to me is:

  GNU, fast, fun, functional

What’s about you?  What’s Guile to you?  :-)

Ludo’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Logo baseline

[Amirouche Boubekki]

Le sam. 18 janv. 2020 à 15:14, Ludovic Courtès <ludo@gnu.org> a écrit :
>
> Hello Guilers!
>
> The Guile logo has this “GNU extension language” baseline.  As Guile 3
> came out, this baseline felt odd to me, not quite corresponding to the
> way I see Guile.
>
> Clearly, Guile is still an extension language, with many great
> applications (Gnucash, Lepton-EDA, OpenCog, GDB, etc.), and I’m sure
> libguile is here to stay.  Yet, to me, “extension language” does not
> accurately capture what Guile today allows for and what people have been
> doing with it; since 2.0, it’s more than an extension language, even
> more so with the performance afforded by Guile 3.

I agree.

>
> Thus, I’d propose changing the baseline.  Something that would describe
> what Guile is to me is:
>
>   GNU, fast, fun, functional
>

I think the term functional is overloaded and somewhat misleading
because Guile is NOT ONLY functional.
I would rather see "multi-paradigm" and / or "batteries included".

> What’s about you?  What’s Guile to you?  :-)

Guile is a fast dynamic programming language.

Re: Logo baseline

[Linus Björnstam]

Fun I can agree with! It is what made me stick with Guile in the first place.

GNU as an adjective seems odd: I think that can better be conveyed as a part of the name "GNU Guile". It is and, if I have understood the discussions going on here, will continue to be a GNU project. Maybe treat fun as a noun: GNU Guile - fast functional fun :D

I'd leave the fine details of taglines to someone who is better versed in english than me, though.
-- 
  Linus Björnstam

On Sat, 18 Jan 2020, at 15:08, Ludovic Courtès wrote:
> Hello Guilers!
> 
> The Guile logo has this “GNU extension language” baseline.  As Guile 3
> came out, this baseline felt odd to me, not quite corresponding to the
> way I see Guile.
> 
> Clearly, Guile is still an extension language, with many great
> applications (Gnucash, Lepton-EDA, OpenCog, GDB, etc.), and I’m sure
> libguile is here to stay.  Yet, to me, “extension language” does not
> accurately capture what Guile today allows for and what people have been
> doing with it; since 2.0, it’s more than an extension language, even
> more so with the performance afforded by Guile 3.
> 
> Thus, I’d propose changing the baseline.  Something that would describe
> what Guile is to me is:
> 
>   GNU, fast, fun, functional
> 
> What’s about you?  What’s Guile to you?  :-)
> 
> Ludo’.
> 
> Attachments:
> * signature.asc

Re: Logo baseline

[Matt Wette]

On 1/18/20 6:08 AM, Ludovic Courtès wrote:
> Hello Guilers!
>
> The Guile logo has this “GNU extension language” baseline.  As Guile 3
> came out, this baseline felt odd to me, not quite corresponding to the
> way I see Guile.
>
> Clearly, Guile is still an extension language, with many great
> applications (Gnucash, Lepton-EDA, OpenCog, GDB, etc.), and I’m sure
> libguile is here to stay.  Yet, to me, “extension language” does not
> accurately capture what Guile today allows for and what people have been
> doing with it; since 2.0, it’s more than an extension language, even
> more so with the performance afforded by Guile 3.
>
> Thus, I’d propose changing the baseline.  Something that would describe
> what Guile is to me is:
>
>    GNU, fast, fun, functional
>
> What’s about you?  What’s Guile to you?  :-)
>
> Ludo’.
To me "fast, fun, functional" does not distinguish guile very much.

I'll throw this out, though I don't think this is that good either:

Guile is GNU's functional, high-performance, systems programming 
implementation.

FWIW, I still look to guile for tool extension and integration.

Matt

Re: Logo baseline

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

On Sat, Jan 18, 2020 at 10:14 PM Ludovic Courtès <ludo@gnu.org> wrote:

> Hello Guilers!
>

Clearly, Guile is still an extension language, with many great
> applications (Gnucash, Lepton-EDA, OpenCog, GDB, etc.), and I’m sure
> libguile is here to stay.  Yet, to me, “extension language” does not
> accurately capture what Guile today allows for and what people have been
> doing with it; since 2.0, it’s more than an extension language, even
> more so with the performance afforded by Guile 3.
>
>
That's true, "GNU extension language" is just part of its features right
now.
And the "extension language" can't define Guile anymore, because Guile is a
productive implementation of Scheme programming language,
a web development language, a system level scripting language, and a
platform to support several different dynamic languages.



> Thus, I’d propose changing the baseline.  Something that would describe
> what Guile is to me is:
>
>   GNU, fast, fun, functional
>
>
Although functional is just one of facinating features of Guile Scheme,
it's still a good selling point to introduce it to other people.



> What’s about you?  What’s Guile to you?  :-)
>
>
Guile is a modern Scheme implementation that can solve real problems in the
industry. There's a joke that Scheme is the only language that the number
of implementations
are more than the users. But I would say, Guile can help people to solve
real program in product level.
And as some people here may know, I've been always a big fan to treat Guile
as a platform for various language transpilers.
I don't know what's the proper slogan now, to me, Guile is more like a
hacking engine rather than a language.

Best regards.

[-- Attachment #2: Type: text/html, Size: 2738 bytes --]

Re: Logo baseline

[Arne Babenhauserheide]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Guilers!
>
> The Guile logo has this “GNU extension language” baseline.  As Guile 3
> came out, this baseline felt odd to me, not quite corresponding to the
> way I see Guile.
What do you mean about the logo? Do you mean tagline? Where I see a
tagline is at the website: https://www.gnu.org/software/guile/

As one point of several we have there:
"Guile is an extension language platform
 …
 Guile is the GNU Ubiquitous Intelligent Language for Extensions, and
 the official extension language of the GNU project."

That’s an important statement, one which brought me to Guile, because
this gives Guile purpose beyond only being a useful language. It is the
language to extend GNU programs.

But aside from this, the website also says:
- Guile is a programming language -> create applications (this is what it starts with!)
- Extend applications (which actually talks about implementing languages in Guile)
- Guile empowers users with "practical software freedom"

The Reference manual says
"GNU's Programming and Extension Language"
https://www.gnu.org/software/guile/static/base/img/covers/guile-reference.png

So the material already states clearly that Guile is not only for extension.

However that extending applications is part of the story is an important
point for me: This also implies that it’s easy to move parts of my
application into the fastest language I can find.

It’s unlikely that Guile will beat C for raw performance *and* memory
requirements for the most performance-critical part of an application,
so knowing that I can shift that part into C (or C++ or Rust or anything
else with C-bindings) is an important point.

Being able to easily embed Guile in a C++ application is a
distinguishing feature compared to Python. That way Guile strikes a
middle-point between Python and Lua.

Also I would love to have a way to script a Godot-game with Guile:
https://godotengine.org/

> Thus, I’d propose changing the baseline.  Something that would describe
> what Guile is to me is:
>
>   GNU, fast, fun, functional
>
> What’s about you?  What’s Guile to you?  :-)

It is the language where I can best experiment with pushing the
boundaries of programming without having to write my own compiler.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Logo baseline

[Thomas Morley]

Am Sa., 18. Jan. 2020 um 15:14 Uhr schrieb Ludovic Courtès <ludo@gnu.org>:
>
> Hello Guilers!
>
> The Guile logo has this “GNU extension language” baseline.  As Guile 3
> came out, this baseline felt odd to me, not quite corresponding to the
> way I see Guile.
>
> Clearly, Guile is still an extension language, with many great
> applications (Gnucash, Lepton-EDA, OpenCog, GDB, etc.), and I’m sure
> libguile is here to stay.

Well, you forgot LilyPond

> Yet, to me, “extension language” does not
> accurately capture what Guile today allows for and what people have been
> doing with it; since 2.0, it’s more than an extension language, even
> more so with the performance afforded by Guile 3.
>
> Thus, I’d propose changing the baseline.  Something that would describe
> what Guile is to me is:
>
>   GNU, fast, fun, functional
>
> What’s about you?  What’s Guile to you?  :-)
>
> Ludo’.

Well, for me, Guile's _the_ extension language for my LilyPond.

It may be more, it may have become more.
And yes, I used Guile for some other stuff as well.
Nevertheless, it remains the language to extend LilyPond.

It feels very strange dropping said phrase.


Cheers,
  Harm

Re: Logo baseline

[Arne Babenhauserheide]

Thomas Morley <thomasmorley65@gmail.com> writes:

>> Clearly, Guile is still an extension language, with many great
>> applications (Gnucash, Lepton-EDA, OpenCog, GDB, etc.)
>
> Well, you forgot LilyPond

The one tool that uses Guile while dominating its domain.

> Well, for me, Guile's _the_ extension language for my LilyPond.
>
> It may be more, it may have become more.
> And yes, I used Guile for some other stuff as well.
> Nevertheless, it remains the language to extend LilyPond.
>
> It feels very strange dropping said phrase.

Same for me. That Guile takes effort to make extending easy
distinguishes Guile from all the just-scripting languages out there, and
also from many other Schemes.

Actually I’d love to see Guile become better at this: to make it easier
to deploy an application that uses Guile in a statically compiled
binary.

Basically to generalize what LilyPond is doing.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Logo baseline

[Ludovic Courtès]

Hello!

Arne Babenhauserheide <arne_bab@web.de> skribis:

> Thomas Morley <thomasmorley65@gmail.com> writes:
>
>>> Clearly, Guile is still an extension language, with many great
>>> applications (Gnucash, Lepton-EDA, OpenCog, GDB, etc.)
>>
>> Well, you forgot LilyPond
>
> The one tool that uses Guile while dominating its domain.

Yup, I don’t forget LilyPond!

>> Well, for me, Guile's _the_ extension language for my LilyPond.
>>
>> It may be more, it may have become more.
>> And yes, I used Guile for some other stuff as well.
>> Nevertheless, it remains the language to extend LilyPond.
>>
>> It feels very strange dropping said phrase.
>
> Same for me.

Like I wrote, Guile remains an extension language, no argument here.

However, describing it as “just” an extension language seems odd to me.
It doesn’t take into account what many have been doing with Guile, and
it doesn’t match the efforts that have gone into Guile since 2.0.

> That Guile takes effort to make extending easy distinguishes Guile
> from all the just-scripting languages out there, and also from many
> other Schemes.

I don’t find embeddability to be that much of a salient feature.  After
all, CPython, Script-Fu, Lua, ECL, GJS, etc. all fit into that category.

Other adjectives I proposed (fast, functional) don’t quite apply to
these, though.

> Actually I’d love to see Guile become better at this: to make it easier
> to deploy an application that uses Guile in a statically compiled
> binary.
>
> Basically to generalize what LilyPond is doing.

In what ways could it become “better” for this use case?

Personally, I encourage people to write more Scheme and less C, there
are lots of good reasons for that.  As a corollary, I encourage moving
from “embedding” Guile (linking your C/C++ program against libguile) to
“extending” Guile (having your main program written in Guile Scheme and
calling out to C/C++ bits as needed).  That’s been my position since the
2.0 days.

Thanks,
Ludo’.

Re: Logo baseline

[Arne Babenhauserheide]

Ludovic Courtès <ludo@gnu.org> writes:
> Like I wrote, Guile remains an extension language, no argument here.
>
> However, describing it as “just” an extension language seems odd to me.
> It doesn’t take into account what many have been doing with Guile, and
> it doesn’t match the efforts that have gone into Guile since 2.0.

I don’t think that it is described as "just" an extension language. The
website makes it very clear that Guile is also a viable application
language.

Where do you get the impression that Guile is described as "just" an
extension language?

>> That Guile takes effort to make extending easy distinguishes Guile
>> from all the just-scripting languages out there, and also from many
>> other Schemes.
>
> I don’t find embeddability to be that much of a salient feature.  After
> all, CPython, Script-Fu, Lua, ECL, GJS, etc. all fit into that category.

CPython isn’t really nice to embed. Blender managers, but otherwise I
don’t see much good integration.

Isn’t Script-Fu a tinyscheme — with much fewer capabilities than Guile?

Lua does hit the same, but has less default functionality.

> Other adjectives I proposed (fast, functional) don’t quite apply to
> these, though.

Functional doesn’t apply to Guile much better than to CPython.

>> Actually I’d love to see Guile become better at this: to make it easier
>> to deploy an application that uses Guile in a statically compiled
>> binary.
>>
>> Basically to generalize what LilyPond is doing.
>
> In what ways could it become “better” for this use case?

Currently the default way to embed assumes that Guile is provided as a
shared library. But that can be problematic when you want to ship a
binary people can test easily.

For example I’d like to be able to add Guile to a Godot-game and then
simply ship it.

It would also be nice to have an easy option to embed Guile in Android
apps. "If you use Guile, you cannot turn your program into a mobile app"
isn’t a strong pitch.

> Personally, I encourage people to write more Scheme and less C, there
> are lots of good reasons for that.  As a corollary, I encourage moving
> from “embedding” Guile (linking your C/C++ program against libguile) to
> “extending” Guile (having your main program written in Guile Scheme and
> calling out to C/C++ bits as needed).  That’s been my position since the
> 2.0 days.

I do the same, but I see that this is no viable way forward for existing
programs.

And having Guile in make has already proven useful to me.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Logo baseline

[Matt Wette]

On 1/19/20 6:11 AM, Arne Babenhauserheide wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
>> Other adjectives I proposed (fast, functional) don’t quite apply to
>> these, though.
> Functional doesn’t apply to Guile much better than to CPython.
>

I think "functional" is used in the formal sense.
The term applies to Scheme, Haskell, SML: e.g., they iterate through 
recursion.
Python, Lua, Perl, Javascript are imperative: e.g., they iterate through 
i=i+1.

Re: Logo baseline

[Arne Babenhauserheide]

Matt Wette <matt.wette@gmail.com> writes:

> On 1/19/20 6:11 AM, Arne Babenhauserheide wrote:
>> Ludovic Courtès <ludo@gnu.org> writes:
>>> Other adjectives I proposed (fast, functional) don’t quite apply to
>>> these, though.
>> Functional doesn’t apply to Guile much better than to CPython.
>
> I think "functional" is used in the formal sense.
> The term applies to Scheme, Haskell, SML: e.g., they iterate through
> recursion.
Is this also true for the do-loop in Scheme?
> Python, Lua, Perl, Javascript are imperative: e.g., they iterate
> through i=i+1.
That is a result of missing tail recursion.

I understood functional in the no-sideeffects sense — which nowadays is
more a matter of programming style than of the language, though
different languages make it easier or harder.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

Re: Logo baseline

[Ludovic Courtès]

Hello,

Arne Babenhauserheide <arne_bab@web.de> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>> Like I wrote, Guile remains an extension language, no argument here.
>>
>> However, describing it as “just” an extension language seems odd to me.
>> It doesn’t take into account what many have been doing with Guile, and
>> it doesn’t match the efforts that have gone into Guile since 2.0.
>
> I don’t think that it is described as "just" an extension language. The
> website makes it very clear that Guile is also a viable application
> language.
>
> Where do you get the impression that Guile is described as "just" an
> extension language?

This thread is about the logo baseline, which is: “GNU extension
language”.  I agree that the web site is clearer; I’m just talking about
the logo here.

>>> Actually I’d love to see Guile become better at this: to make it easier
>>> to deploy an application that uses Guile in a statically compiled
>>> binary.
>>>
>>> Basically to generalize what LilyPond is doing.
>>
>> In what ways could it become “better” for this use case?
>
> Currently the default way to embed assumes that Guile is provided as a
> shared library. But that can be problematic when you want to ship a
> binary people can test easily.

I think this is no different for Guile than for any other piece of
software: some would ship a Docker image, and I’d argue that you can use
‘guix pack’ to generate a minimal standalone tarball or Docker image.

(Though I think it’s also perfectly doable to provide a binary that’s
statically-linked against libguile.)

Thanks,
Ludo’.

Re: Logo baseline

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> What’s about you?  What’s Guile to you?  :-)

Guile is the force that binds GNU together.  Guile was intended to
extend (all) GNU programs, truly empowering the user.  You made Guile
into a great language for writing programs.  Now Guile even creates a
coherent GNU System, through Guix.

Moving from Python to Guile was a gentle path towards a more functional
approach of writing programs which reduces accidental complexity and
fits much better with how my mind works.

What puzzles me is the long road it took me to reach this point, more
than 20 years via C, C++ and Python.  When I look at GNU projects like
Glibc or GCC moving from awk/sed/perl to Python for scripts instead of
Guile I can't help thinking: Oh my, they are where I was 20 years ago;
what a long path we still have before us.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com