Re: How to make GNU Guile more successful

[Arne Babenhauserheide <arne_bab@web.de>]

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


Panicz Maciej Godek <godek.maciek@gmail.com> writes:
> There's surely many ways to approach that issue. The point is that for
> some reason, Schemers from various tribes prefer to reinvent the
> wheel, rather than use an existing one. (Not that I am any different)
> However, I also think that these CPAN-alike solutions are far from
> optimal: ideally, programming could be made an experience similar the
> game "The Journey" by thatgamecompany (where you travel to your goal
> and sometimes encounter other players heading the same direction), and
> the repository itself could look more like Wikipedia (but first we'd
> need to start perceiveing programming as a compact way of representing
> knowledge)

That sounds somehow like stackoverflow. We might already be going there :)

>> Practically put: We need Andy Wingo to nitpick the tutorial about things
>> >> which will cause overheads the compiler cannot fix easily — including
>> >> expensive use of macros.
>>
>> > I definitely oppose. If Chez has something solved better, why not use
>> > Chez?
>>
>> It’s not "why not use Chez", but rather "what should I teach new
>> people?"
>>
>> They are already learning a new language. When I now go and point them
>> towards many different implementations which differ in details of stuff
>> I teach them, I’m throwing more complexity at them. More things to
>> understand before even starting to write working code.
>>
> I totally agree. Programmers shouldn't be concerned whether they're
> using Chez or Guile or Gambit or Stalin or whatever else. Ideally, they
> should do well without even knowing that such things exist.
> There are Schemes, such as Kawa or Biwa or IronScheme, that are tied
> to their environment, but most of them just run on the PC

I think this is a point which cannot be reached, because the design of
the Scheme system itself must make certain tradeoffs — especially for
the default environment (what to present a new user). If that is too
large, then users cannot start quickly. If it is too small, then users
cannot solve problems easily. But different problem spaces require
different base tools.

Another points are the basic datastructures: If they are too complex,
then the system cannot be used easily on tiny computers.

Essentially you have to find reasons for decisions like this:
https://docs.python.org/3/faq/design.html#how-are-lists-implemented
and this:
https://wiki.python.org/moin/TimeComplexity

>> Maybe it would already help to mark the code which will work the same in
>> all (r7rs) Schemes. Is there stuff which is well optimized in all
>> Schemes? Who knows that? The r7rs benchmarks look like this is very much
>> not the case: http://ecraven.github.io/r7rs-benchmarks/benchmark.html
>>
>> (Or rather, the benchmarks would ask: "why should I *not* use Chez or
>> stalin for everything I do?" Because those are the fastest for most
>> tasks.)
>>
>> But that might mean to write less elegant or efficient code to keep it
>> cross-implementation. Should I rather teach new people to solve a
>> problem as well as possible, or teach them to solve a problem in a
>> portable way?

> I think that in principle, the programmer should only focus on writing
> most elegant code

I think there are several different kinds of elegance. There’s technical
elegance (combining existing things to build something unexpectedly
powerful with minimal effort), readability (being easy to understand for
newcomers), minimal code (solving a problem with the minimal amount of
code — often close to mathematics), uniformity (using the same basic
structure everywhere), efficiency (solving a problem with minimal
resource-consumption), ...
I’m sure we’ll find more.

Sadly these elegances contradict each other in some points.

>> In my case, I decided to use Guile by checking Scheme
>> implementations. There were three with roughly equal activity and
>> features. I chose Guile, because it’s a GNU project and it has a long
>> history of surviving changing maintainers, so my skills are most likely
>> to stay useful.

> That's interesting. I chose it by trying to add a scripting language
> to my game engine written in C++. But I guess that if I was starting
> now, I'd write the whole engine in Chez (which wasn't opensource until
> last year)

Chez becoming free software is an interesting development.

>> > The ultimate goal is not to optimize programs, but programmers.
>>
>> I’m not sure that I want to optimize them, I want to teach them tools to
>> be more efficient and enjoy their work more (and teach myself the same).
> Yeah, maybe I used a harsh word, but I meant exactly optimizing
> programmers' efficiency (or if it sounds too bad, "giving them tools
> to be more efficient")

Sounds good :)

>> I think one important point for Scheme would be to gather some consensus
>> points. The Zen of Python is part of what made that one community
>> strong. There is no reason why there should not be a Zen of Scheme,
>> along with implementation-specific Koans which extend it.
>>
>> Do you have ideas for principles which could be shared by most Schemers?
>>
>>
> It depends on the most Schemers, not me :)

That’s why its a social problem :)

Finding a set of basic koans which most Schemers agree with requires
talking to and knowing a lot of Schemers.

> However, you can have a look at the (grand scheme) glossary that I've been
> maintaining for some time:
>
> https://github.com/plande/grand-scheme

This looks interesting.

> of course, the intent is to make the glossary usable for someone else than
> me,
> and I can boast that I have at least one user distinct from the maintainer.
> You can have a look and let me know what you think. (for now it only works
> with Guile). In particular, are there any factors that could convince you to
> adapt it as a base for your library, or what would you want changed
> (I assume you won't stop at the README file).

I’d mainly need practical examples. Tell me how I’d solve a problem
with (grand scheme) and how it would be solved without it — showing me
why using it is better.

That means: Documentation.

Also I’d need to know whether some of these methods have performance
problems: Will this scale as well as the method without (grand scheme)?

>    - functions should be pure
>    - language constructs that cause side-effects should be encapsulated
>    with macros that limit the extent of those side-effects
>    - if possible, use the quasiquote macro, rather than cons, append or list
>    - prefer the use of match <http://synthcode.com/scheme/match.scm> to cond,
>    if the patterns are simple
>    - never use abbreviations
>    - use commented prepositions to separate arguments

As guidelines for easy-to-use libraries, that sounds good.

> Also, I recently added infix syntax to Scheme, but (unlike in Racket
> or David Wheeler's solutions) in the way it is still a prefix
> syntax. So for example, instead of writing (< a b), one ought to write
> (is a < b). The rationale is that prefix notation is terrible for
> non-symmetrical binary predicates, because it obscures the roles of
> respective arguments (in addition, (is a < b <= c) expands to (and (<
> a b) (<= b c))). I'm still not sure whether it is a good idea, but I
> have no reasons to think that it is bad either :] [Curiously enough, I
> think that prefix notation in arithmetic is just fine: (+ a b c) reads
> as "sum of a, b and c"]

This is an old idea, but using (is) as prefix looks
interesting. Typically the prefix was something like (nfx), which
doesn’t say anything semantic (other than that what follows uses infix
syntax). It’s like an expanded equal?

(if (is a = 5)
    #t
    #f)

(cond
    ((is q = p)
     q)
    ((is p > 5)
     p)
    (else
     q))

This seems pretty close to natural language. Can I also use (is A 5)
instead of (equal? A 5)?

Though (is? a = 5) might be closer to canonical Scheme.

> I like it that you and Amirouche look a lot at the sociocultural
> perspective of programming

I’m glad to hear that :)

> Yes, to me the ease of understanding is also crucial. (I'd even go
> further and say that undestranding is the very point of programming)

I would not go that far: We’re programming both for the future
maintainers of the code and for the computer. This restricts us in
expressing things, because we always have to keep two targets audiences
in mind (many different systems *and* many different people).

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

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