Re: How to make GNU Guile more successful

[Amirouche <amirouche@hypermove.net>]

Le 14/02/2017 à 22:35, Arne Babenhauserheide a écrit :
> 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 :)

That's a very good idea!

>
>>> 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