From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Amirouche Newsgroups: gmane.lisp.guile.user Subject: Re: How to make GNU Guile more successful Date: Wed, 1 Mar 2017 20:21:52 +0100 Message-ID: <3a0a18c5-0110-8e19-33fc-4be07c53b36b@hypermove.net> References: <87lgtajpkc.fsf@web.de> <87vasdaeha.fsf@web.de> <8760kc5ucw.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1488396142 19759 195.159.176.226 (1 Mar 2017 19:22:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 1 Mar 2017 19:22:22 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 Cc: "guile-user@gnu.org" To: Arne Babenhauserheide , Panicz Maciej Godek Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Mar 01 20:22:14 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 1cj9pE-00049E-0f for guile-user@m.gmane.org; Wed, 01 Mar 2017 20:22:12 +0100 Original-Received: from localhost ([::1]:48346 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cj9pJ-0004fb-JI for guile-user@m.gmane.org; Wed, 01 Mar 2017 14:22:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cj9oy-0004eh-CU for guile-user@gnu.org; Wed, 01 Mar 2017 14:21:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cj9ow-00062U-D0 for guile-user@gnu.org; Wed, 01 Mar 2017 14:21:56 -0500 Original-Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:58122) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cj9ow-00061l-3R for guile-user@gnu.org; Wed, 01 Mar 2017 14:21:54 -0500 Original-Received: from [IPv6:2a01:e35:2ef3:d930:1cb1:4034:54ae:968f] (unknown [IPv6:2a01:e35:2ef3:d930:1cb1:4034:54ae:968f]) (Authenticated sender: amirouche@hypermove.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 19FDA1720E5; Wed, 1 Mar 2017 20:21:50 +0100 (CET) In-Reply-To: <8760kc5ucw.fsf@web.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4b98:c:538::196 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:13370 Archived-At: Le 14/02/2017 à 22:35, Arne Babenhauserheide a écrit : > 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 :) 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 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