From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Arne Babenhauserheide Newsgroups: gmane.lisp.guile.user Subject: Re: How to make GNU Guile more successful Date: Tue, 14 Feb 2017 22:35:11 +0100 Message-ID: <8760kc5ucw.fsf@web.de> References: <87lgtajpkc.fsf@web.de> <87vasdaeha.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1487108176 21644 195.159.176.226 (14 Feb 2017 21:36:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Feb 2017 21:36:16 +0000 (UTC) User-Agent: mu4e 0.9.16; emacs 25.1.1 Cc: "guile-user@gnu.org" To: Panicz Maciej Godek Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Feb 14 22:36:11 2017 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cdklc-00056G-8K for guile-user@m.gmane.org; Tue, 14 Feb 2017 22:36:08 +0100 Original-Received: from localhost ([::1]:37273 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdklh-0002sA-QJ for guile-user@m.gmane.org; Tue, 14 Feb 2017 16:36:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdkkx-0002pz-NL for guile-user@gnu.org; Tue, 14 Feb 2017 16:35:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cdkku-0002YW-Am for guile-user@gnu.org; Tue, 14 Feb 2017 16:35:27 -0500 Original-Received: from mout.web.de ([212.227.17.12]:53822) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cdkkt-0002XX-UU for guile-user@gnu.org; Tue, 14 Feb 2017 16:35:24 -0500 Original-Received: from fluss ([85.212.4.135]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MY6wu-1cqpfC2s6q-00Uutc; Tue, 14 Feb 2017 22:35:19 +0100 In-reply-to: X-Provags-ID: V03:K0:sceUuLu5lj9IxYkPeNciDV6IqStAYDgT1tjeDz/OBT2+kPnU6ar HrQKOtoKmegWXqZV72IFzQotz6YyGrSOlPVz8gk8MVbWwJEFQu1Qi0yKJty135YfO+ENn4H iiKUKO+cXlW76IS0qDsCbBaIGBCILZDBET2QsFVBUOuEyiyDmBGb6ZzPbTFpZR1LdtcAIQp T/PWmZvpFyeZJWmV3Jmog== X-UI-Out-Filterresults: notjunk:1;V01:K0:Q0CHjGDWFfc=:LWpo/9V6G5jS39c8LCBrQ4 /lv1IiH/CaJN4bwDfbFZhaG9BgKVCPZ8g5dqYRo8jfPKGmRVyGQrcigH5+OE7rpbSSkqsIPxB oX8N1w4Ac+pK/TPcJRM5nxPeW56fU41AkLk85aEbOYA9OYbc2udP2lbqZF9as5UWRxv+iB049 /koXtcoTa3JquoV3OYIle9x3OhknkDhtOKkjwPQwsPs2h76MbmBzcmKtMg9s8iFEq4MUWdQTv /NLxabo4EuwH1XMFU4U93v9mB5/AeRQEF9nqQlDCPwcxHpvraCAI2FewSTaW3sdNMEsw+NYeT hnjzCzFmXD2SuPQSkQC9+qLT3aczJcUaytKtEyflVd7ofMoYp5GjOJ3FIfkLJUqYgY9u1j1bQ A5OWrI8OuzqJdHQ8GyDKArSZaG47Ut8vE7QppHbOxfIazw5dF+WCJpCIhrhPP6XXQuhpMwuMP Y2hVkUs6MHzC25jSglcqoU5d3hHqM1RQrLMgdxn1x9SscyQagxm2rKXgFA9FxmYv9nLP92U+F jtMkqfqnIYY6OPgREb8HKs78XwBJO6ix8YA81XSbk7jjtInKigNeqOVY9EOdIEfZd2iStQ1GA gxlbZU9oXnXyqpsjhpCdDI0UGkOepjv0stfYuMZ4AoxMhElcSPvonVDIVsBZufNApGyyWBC8J acPY2rYrk68O5rGXQloPHJHTssqDw/Ns0HUx3/rB8bXIfMDVNg7fBsfKJHvTDJ4NBIFOF9ySA XRu5YBOXx5Ld4aX/jJdmSNZDZOXV8tb9bvVf9bBqh3ArtMvWdqNucUn1/Og= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.17.12 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13205 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Panicz Maciej Godek 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 =E2=80=94 i= ncluding >> >> expensive use of macros. >> >> > I definitely oppose. If Chez has something solved better, why not use >> > Chez? >> >> It=E2=80=99s 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=E2=80=99m 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 =E2=80=94 especially f= or 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=E2=80=99s tech= nical 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 =E2=80=94 often close to mathematics), uniformity (using the same basic structure everywhere), efficiency (solving a problem with minimal resource-consumption), ... I=E2=80=99m sure we=E2=80=99ll 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=E2=80=99s 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=E2=80=99m 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=E2=80=99s 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 maintaine= r. > 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=E2=80=99d mainly need practical examples. Tell me how I=E2=80=99d solve a= problem with (grand scheme) and how it would be solved without it =E2=80=94 showing= me why using it is better. That means: Documentation. Also I=E2=80=99d 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 l= ist > - prefer the use of match to c= ond, > 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 <=3D c) expands to (and (< > a b) (<=3D 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=E2=80=99t say anything semantic (other than that what follows uses in= fix syntax). It=E2=80=99s like an expanded equal? (if (is a =3D 5) #t #f) (cond ((is q =3D 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 =3D 5) might be closer to canonical Scheme. > I like it that you and Amirouche look a lot at the sociocultural > perspective of programming I=E2=80=99m 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=E2=80=99re 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 =2D-=20 Unpolitisch sein hei=C3=9Ft politisch sein ohne es zu merken --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYo3gRAAoJEBPvjUUkA8PrJwwQALWew8Hzz71ARPpkPFFh77Xq G3Y2MV9TlNIf7gjOYF+hAHAWthDDcG/hjsTV1yAvd1wBnhlCxlUQuTG3wPG0UOuD aSQ5fibOv0qXwvA8Z6uL7vDHs+libRsvA6ttEfXpkt/kBceEgcphvyGw3EoujNVu 1dY6hbzNbOpd/v3oLVJ+w4O3bjCuy1yUIgLIed9/abzzQWbouB1kk4IjBeTcDKPJ OVl7W5Uq9JA/iIRYPpIHOuoDbI/xEdeDr8Dc1ufY7n8DVmb63Ib4DkfcbMr90XjQ T8U/MMK4Cbky+joUJzWIgItPeOTTD6a3o8vlTML35OiU9uRr0Z+rO9ouvUMShO07 DD7RJX7vNuCS6/CFIvjTvt0CzlFrIqjoIxGtFLuVcjEHv6wIpcgMUICo+QMZmuB6 noES48M/4I9rMjQpai5QIO8AXJ/ei2iLfkeC9PcfdR+rx+nIKd8NC/UyKIkqJ3dK NsxfJh4pN71oB3joHL5JAHv8sdQpPqgsc+tjUs/GZgdmYIeBu2YpMhw34cyIHsDG dPaqrQ9k8WdAggbJ20zq6OGQBbeRR+GQOKIgFcf/ZUMHP29sowYeqVqhU25TQHIj fRsm4B4QxJ6WX/mCxRXK2T19HDZ8nAIi4HKgMmDuhkGIJsItUwDNe0lnafGe8GLk Fb5FQkf7QzVh3e7H1AJz =Nk2m -----END PGP SIGNATURE----- --=-=-=--