From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Arne Babenhauserheide Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Request for feedback on SRFI-126 Date: Thu, 01 Oct 2015 00:16:10 +0200 Message-ID: <1624973.gGP49SRqMa@fluss> References: <87zj08t5w1.fsf@T420.taylan> <2004212.koJWAIKy7V@fluss> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart144369851.5J3gdHGPvj"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1443698212 10494 80.91.229.3 (1 Oct 2015 11:16:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 11:16:52 +0000 (UTC) Cc: "guile-user@gnu.org" , guile-devel To: Panicz Maciej Godek Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Oct 01 13:16:42 2015 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zhbqr-0008Gp-Do for guile-user@m.gmane.org; Thu, 01 Oct 2015 13:16:41 +0200 Original-Received: from localhost ([::1]:48235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhbqq-0004kW-SM for guile-user@m.gmane.org; Thu, 01 Oct 2015 07:16:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhPfe-0003wy-Uk for guile-user@gnu.org; Wed, 30 Sep 2015 18:16:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhPfb-0007c0-MT for guile-user@gnu.org; Wed, 30 Sep 2015 18:16:18 -0400 Original-Received: from mout.web.de ([212.227.15.3]:54805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhPfb-0007br-Ca; Wed, 30 Sep 2015 18:16:15 -0400 Original-Received: from fluss.localnet ([85.212.86.241]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0LzJyr-1alllM2ThZ-014X04; Thu, 01 Oct 2015 00:16:13 +0200 User-Agent: KMail/4.14.8 (Linux/3.14.14-gentoo; KDE/4.14.8; x86_64; ; ) In-Reply-To: X-Provags-ID: V03:K0:aNGBnbb/x5ddLozzeinzkLr+lKZ3FDmdDJC2w59EGC2UY1bjHue etRV62wshUUOr3tdpZ70Kcd8JDYZAkwro7Af45P4BwArhY4nnHdvlqEk+miMTkkKhEmWX0Z Fb2daB9c+Cm8sZhUSdBaxVEozuA9SPYhoPmjDf/GXW4KVLvn6kUF9+PPcK4zRYHEqMnL7d6 zPdjU++DRjjCrj+gA3dEA== X-UI-Out-Filterresults: notjunk:1;V01:K0:PFQJoThG1Wg=:2hJv/1//AMHe1Z9JaEOPtG M0lOBSmpOhj90q/o3G3YmFNk03/pmmvSk9doP/0gmaf3SdfZr5y/u5Wm/kqs1X7hdQ3lbJdIG dnSilTtNl2/Xr2nM0adpNOyOUMlN74TzIDIN/F1SmEp61uMBl0hlgXpZKAwaF3yzRkgFtNdeQ /oEwFD2n2fmGnCHI1FlhcI/7QvqjrwcD8W5s2R/6JdqCAcoMmKDXbruWFHeaTi5y2NbRwRUGb O8QkB3Ny/OMbyeuMr2QZp6scZFml7cA101bjdY3ME/RuhypQimgfX62PL+cWfyjJwpwFvs5Hf NEeYJTwBFbl5C+i/POKdio2lL4CbBUBZj86Qw8YugSa7/Sm4keg0GbngTLqQ6ctmIShtXwAe7 g9eKP60lsiylyuqdOy/Nup8zDJTz7cmJOHfZc8PpD9ti1XeLHNRMbFW8Bk7kV1T7CIC3LlPgd WKqOpEjqPdwUYfajJWFa/dynHqdkVWnJrHSWwh63yjdbRJt4asbFQiwZt8kRIhur0IkxciTMe JzmV4dO8osCeKudoTs7eWroyeOyIma5s59bpcZ8crTHHoO+Rkwk4xAyhWVNWOdk+EYQatGz3y qZd3n5mmMl6ZrJY9q+6MJX1qwofSUTanAJ6jOn5pYXN0IO68kZxj8ojcPjHWUmyDc3GsxT16+ 9+vcyADT3aRTSP+grd4A0+SGQJlsUcsTPjm3Ck7Xg16/eYGI9xjH1XSVq6jGY5ijjzj+6jD1I 4MiwASbWijLPTg3SsxJRF5bfV93ihx/1V22N0aVxh+dq+RI2qXG1z7pEr8M= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.3 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 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-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:12063 gmane.lisp.guile.devel:17880 Archived-At: --nextPart144369851.5J3gdHGPvj Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Am Mittwoch, 30. September 2015, 08:39:44 schrieb Panicz Maciej Godek: > > > others), then it would be most harmful to the Scheme community, b= ecause > > > that would increase code enthropy and force programmer to make an= > > > irrelevant choice. > > > > It=E2=80=99s no more irrelevant than the choice between Guile and R= acket. >=20 > No. Guile and Racket are both experiments. I think it was a good move= on > Racket's side that they proclaimed that they are a separate programmi= ng > language, because that way they manage to avoid bad community pressur= es > like this. Do you see wisp as community pressure on Scheme implementations? > > And different from that choice, it=E2=80=99s trivial to change: > > > > for i in *.w; do guile wisp.scm $i > $(basename $i .w).scm; don= e > Converting strange syntax to Lisp is essentially what parsing does. I=E2=80=99ll cheat a bit here and pull your later answer: > This is the reason why emacs indents lisp code. This is the part of > Norvig's comparison that I particularly like: >=20 > "One of Python's controversial features, using indentation level rath= er > than begin/end or braces, was driven by this philosophy: since there = are no > braces, there are no style wars over where to put the braces. > Interestingly, Lisp has exactly the same philosphy on this point: eve= ryone > uses emacs to indent their code, so they don't argue over the indenta= tion. > Take a Lisp program, indent it properly, and delete the opening paren= s at > the start of lines and their matching close parens, and you end up wi= th > something that looks rather like a Python program." If you do that, you essentially have wisp. Being as close as possible to Scheme with just leaving out the parens you can infer from indentation is the core design principle of wisp. > Yet you loose a lot of support from your tools if you miss the assump= tions > that they were made upon. That=E2=80=99s completely, totally true. Guile itself provides almost its full support when you=E2=80=99re using= wisp, but the tool support is much weaker. The Emacs mode for wisp is much, much weaker than Geiser and there are no syntax highlighters in any code hosting service, and that doesn=E2=80=99t even start with external= code analysis tools. But you can already do stuff like this: http://draketo.de/english/wisp/shakespeare > > > It also sacrifices some of the strengths of Scheme, actually, bec= ause it > > > makes the code structure obscure. > > > > I disagree on that. The structure is still just as easy to recogniz= e > > as with parens: >=20 > It is easy for you, because you're inveted it. For everyone else it's= just > another thing they'd need to learn in order to read the code. They'd = need > to remember all the assumptions you've made. Let=E2=80=99s do that by example: define : hello world format #t "Hello ~A!\n" world hello "World" Recognizing the structure isn=E2=80=99t the problem. Tool support is a problem. And integration. And documentation. And so on. It is unlikely to be the best system for all kinds of hacking. But it might be a pretty good system for some tasks. And when you program in wisp, going to standard Scheme is really easy. You already know all the functionality, the structures, the libraries and so on. > > > The same goal could better be achieved (non-intrusively) by makin= g an > > easy > > > to use editor that would allow to display your Scheme code in the= way you > > > prefer, be it Python-style indentation or some fancy LaTeX format= ting. > > > > I consider it as problematic when programming languages need strong= > > tool support to be easy to read. With the right tools, even Java is= > > nice to use. >=20 > Raise your hands all those who don't use emacs to write their Lisp co= de. > Raise your hands all those who don't use geiser to interact with Guil= e. >=20 > I honestly think that, however clever Lisp is, it would be rather pai= nful > to edit it without proper tools. Even the aforementioned 'wisp.scm' i= s a > tool. You=E2=80=99re talking about editing right now. I explicitly talked abo= ut reading, not about editing. > Regarding Java, I think its tools have the same problem the language = has, > i.e. everything is fine as long as you stick to the path that their > developers chose for you. Replace Java with Python, and that still fits. Python even has flake8 for Emacs which checks for you whether you are following the canonical path. And people do that intentionally. I know I do. But there=E2=80=99s a reason why I started into Scheme. > > > Fine. But I don't find it disturbing that this "useful language w= ith tons > > > of great libraries" is called Racket or Guile, rather than Scheme= . > > =E2=80=A6 > > small projects, it can be a blocker. You can=E2=80=99t spend a few = days > > waiting and 1 hour porting for programs which just take 4 hours to > > write. Or rather: You can=E2=80=99t do that if you need to combine = many small > > projects into a bigger whole. >=20 > The same is true if you try to port e.g. PHP code to Guile, but then = it > only gets more difficult Sure, but that=E2=80=99s not what I would compare it to. I=E2=80=99d ra= ther compare it to the situation with C and Fortran. Porting a big codebase from one compiler to the other takes some time, but once you did it, the code works on both compilers. And you can quite easily write code which works for both compilers. There will be minor glitches, but most things will just work. > > > I will agree with you if you show me one example of successful de= ployment > > > of Guile or Racket. Like, Python has some impressive tools like D= jango or > > > Enaml. > > Can you give me clear criteria for when you would consider a > > deployment as successful? > Well, that would be a little vague, but my first shot would be that i= t runs > an app that makes money to anyone. I can work with that =E2=98=BA Best wishes, Arne =2D- singing a part of the history of free software:=20 =2D http://infinite-hands.draketo.de --nextPart144369851.5J3gdHGPvj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iJwEAAEIAAYFAlYMXyoACgkQ3M8NswvBBUhJbQQAgfbu19tCGdsQoZHgpSNTQkeu RxGwutL0IAjICHXksk1xJsmZVwoikNAQgXNL45IUDaB/7k2rV0Icnmz+6cfdhDac ahTfPP2pxPs+0s7g4aNNhRorDXqm6+ufubfJbj4BMQp7w2E9d1NAEkRq06Uf8zP9 qtC21o1V1M6OT4d3qWc= =oxeK -----END PGP SIGNATURE----- --nextPart144369851.5J3gdHGPvj--