From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Marko Rauhamaa Newsgroups: gmane.lisp.guile.user Subject: Re: How to make GNU Guile more successful Date: Tue, 14 Feb 2017 07:59:07 +0200 Message-ID: <87zihp48k4.fsf@elektro.pacujo.net> References: <87lgtajpkc.fsf@web.de> <878tp967p4.fsf@elektro.pacujo.net> <87shnhabln.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1487051976 20611 195.159.176.226 (14 Feb 2017 05:59:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Feb 2017 05:59:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: "guile-user@gnu.org" To: Arne Babenhauserheide Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Feb 14 06:59:28 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 1cdW99-0004of-RJ for guile-user@m.gmane.org; Tue, 14 Feb 2017 06:59:28 +0100 Original-Received: from localhost ([::1]:32886 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdW9F-0004by-Ej for guile-user@m.gmane.org; Tue, 14 Feb 2017 00:59:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47306) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdW8u-0004bt-DJ for guile-user@gnu.org; Tue, 14 Feb 2017 00:59:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cdW8s-00022i-W2 for guile-user@gnu.org; Tue, 14 Feb 2017 00:59:12 -0500 Original-Received: from [2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508] (port=51894 helo=pacujo.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdW8s-00022D-Nw for guile-user@gnu.org; Tue, 14 Feb 2017 00:59:10 -0500 Original-Received: from elektro.pacujo.net (192.168.1.200) by elektro.pacujo.net; Tue, 14 Feb 2017 07:59:07 +0200 Original-Received: by elektro.pacujo.net (sSMTP sendmail emulation); Tue, 14 Feb 2017 07:59:07 +0200 In-Reply-To: <87shnhabln.fsf@web.de> (Arne Babenhauserheide's message of "Tue, 14 Feb 2017 00:56:52 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2001:1bc8:1a0:5384:7a2b:cbff:fe9f:e508 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:13191 Archived-At: Arne Babenhauserheide : > Marko Rauhamaa writes: >> Then, there's GOOPS, which in my opinion is simply an unnatural way >> to go about object-oriented programming. It does violence both to >> ordinary OO way of thinking and classic Lisp idioms. > > GOOPS works pretty well for me where I use it (for dispatch by type). > Could you clarify your criticism: Do you think it is bad or is it just > different? GOOPS starts by defining slots. Slots are an objects internal business and should not be visible to the outside. Instead, objects should be black boxes that interact with methods. For example, the port interface is a nice, classic OO API. You don't know anything about the slots of a port. Furthermore, I think an extensive type system is un-Lisp-like. OO is not about things belonging to a type but objects interacting through methods. In fact, the concept of a "class" could be done away with. >> Continuations and multiple values are obstacles instead of enablers. > > I think multiple values are nice. But they are not well-integrated (I > have to import something to use them). Why do you think them enablers? Yes, the multiple values API is a problem in and of itself, but more generally, what does: (values a b c) give you on top of, say: (list a b c) > Why do you think that continuations are an obstacle (do you mean > general continuations or do you mean prompts)? Continuations prevent you from implementing Python's try/finally and emacs' (unwind-protect). On the other hand, I don't think any application developer would come to a point of thinking, "Hey, I know, I'll use a continuation!" >> asyncio, type annotation, > > type annotations should provide nice ways to optimize for pypy and > other more optimizing Python implementations. You can't have it bothways. A dynamic language liberates you from shackles and boilerplate even if it destroys your performance. The moment you bring in the boilerplate, you are back to Java. > Decorators are really cool to use: Have yet to find a need for one. >> dunder jungle, > > What=E2=80=99s that? >> meta-object programming, > > That=E2=80=99s needed to make some things elegant. "Different 20%"-rule a= gain. Again, I haven't yet found a need to deviate from the regular object semantics. >> Unicode illusion. (Guile has fallen into that last trap as well, >> unfortunately.) > > I=E2=80=99m using Python and Guile for physics and math (to some degree),= and > having good Unicode-support is great for that. What=E2=80=99s your practi= cal > criticism here? In Linux, all pathnames, files, sockets, environment variables and command-line arguments are, or deal with, bytes. The bytes are often encoded with UTF-8, but a programming language cannot assume that, even if LOCALE promises otherwise. It would be better to leave Unicode out of Guile's system interface and have the application encode and decode explicitly where needed. >> There's one thing Python has over Guile, still: Python's system call >> support is outstanding. For example, I managed to implement a >> full-blown shell using Python. That was the first time I ever ran >> into terminal-related system calls, and Python had them all. > > Which ones are missing in Guile? For example tcgetattr(3). (Ok, not a system call.) Missing epoll(2) is inconvenient. Not being able to transfer an open file descriptor via sendmsg(2) is really bad. Marko