From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Linas Vepstas Newsgroups: gmane.lisp.guile.user Subject: Re: How to make GNU Guile more successful Date: Tue, 14 Feb 2017 13:36:59 -0600 Message-ID: References: <87lgtajpkc.fsf@web.de> <878tp967p4.fsf@elektro.pacujo.net> <87shnhabln.fsf@web.de> <87zihp48k4.fsf@elektro.pacujo.net> Reply-To: linasvepstas@gmail.com 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 1487101094 17062 195.159.176.226 (14 Feb 2017 19:38:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Feb 2017 19:38:14 +0000 (UTC) Cc: "guile-user@gnu.org" To: Marko Rauhamaa Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Feb 14 20:38:10 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 1cdivR-0004DH-NI for guile-user@m.gmane.org; Tue, 14 Feb 2017 20:38:10 +0100 Original-Received: from localhost ([::1]:36841 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdivX-0003w8-3c for guile-user@m.gmane.org; Tue, 14 Feb 2017 14:38:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdiuh-0003nv-Vu for guile-user@gnu.org; Tue, 14 Feb 2017 14:37:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cdiug-0002HP-DD for guile-user@gnu.org; Tue, 14 Feb 2017 14:37:23 -0500 Original-Received: from mail-qk0-x232.google.com ([2607:f8b0:400d:c09::232]:33633) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cdiug-0002H9-8G for guile-user@gnu.org; Tue, 14 Feb 2017 14:37:22 -0500 Original-Received: by mail-qk0-x232.google.com with SMTP id p22so40923209qka.0 for ; Tue, 14 Feb 2017 11:37:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=SGkbCSKvUGZOMC+S/b/ufv66j7EmzKxFMLxUZ+TYoFo=; b=UoKuOPu2t7fHBtvT5OEHVgnnb6yIy9Zt4Nnnm/vk+DhsRta1IoBHyowlZRVCgm+bQ+ 4+UKNJUsWmxPjTnfhcpiQkpvvos2+ctZZO+o9rmfpPFr42HyqFaSmswZJvaTjn9NQNO7 xrgMkUyL6XhrKIZbXprjUZbMiCveX/5evC/Kdu5N5QZ/S4upNIBxQ1D5gfIs+Mpwg3lv WSXrmjlXR6bSQrSoyS0yrjwfwq1fsfEiDEUHjLpqPgogY7zfn29j/dx0hC4JScniqC+U NmeRSqQgmOUFkGABt/NwyB9eBR5oHrswWwuOUBdtrRKYHPVHi3ruotU1eTijGNZOK0U4 4m5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=SGkbCSKvUGZOMC+S/b/ufv66j7EmzKxFMLxUZ+TYoFo=; b=egpx0GPdlnywTg2vsUudX1CWHeFO8APdLbBIbwhKdUg0ifrdSNk2uHxyK+FU6pALbq EeRsMC5p4ysF/LlfBOGINb+g3akW8ExFLer/40dp/OpQah1/ZkJC7iiVIelqwe58BECZ TLteOk+xiI0G9vAzaqFf6jNrIAxS+0be+9RQ/pydjghVI25488pnbampmIbGGd98Yz12 YNQjvssDIcj/WKWhBG93QgOtJzl2CjDBoqcI3CtVR6lJhR9FjL0z7eKGWUbMIFlpbZHw U/OPzo1mHnN/72xoYJ7lgVNa9wWZfqIjvBqYY/2TrzYjJndBZQyQtwYjhUaaiz2V547E n7Sw== X-Gm-Message-State: AMke39mQDGy3qRWeSIXeLc4wrGsW0Wm/xiLUT+s8kPAYX5BbPfMVjivK4Z0uancd1BrSzyNzUyOXF3+50E/q3g== X-Received: by 10.55.215.149 with SMTP id t21mr14294659qkt.196.1487101040110; Tue, 14 Feb 2017 11:37:20 -0800 (PST) Original-Received: by 10.12.174.231 with HTTP; Tue, 14 Feb 2017 11:36:59 -0800 (PST) In-Reply-To: <87zihp48k4.fsf@elektro.pacujo.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c09::232 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:13199 Archived-At: Hey, On Mon, Feb 13, 2017 at 11:59 PM, Marko Rauhamaa wrote: > > 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. Yes, but ... maybe goops should be renamed guijs ? Javascript has this ... wonderful ... ability to just attach new data and new methods to any "object" at runtime. Now, I've never used goops in any serious way, so maybe I'm quite off the mark, but it seems to me that maybe this is what slots are trying to accomplish. That is, when you say "classic OO API", it seems you really have C++ in the back of your mind. But the early days of OO had all sorts of weird way= s of saying things and thinking about things (e.g. "sending messages to objec= ts") that was a bigger, more inclusive tent. Perhaps GOOPS is just OO in this older, and now deprecated sense. My naive impression is that some javascrtipt-ish extension to guile would be very cool. Perhaps goops could be pushed further in that direction. > >> 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) +1 every time I think I need multiple values, I try it, and then back away from it. Its a cool-sounding idea that is a consistent obstacle. > > 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!" Continuations are stunningly-badly explained, almost everywhere. More or less every example I've ever seen is pointlessly obtuse and opaque, seemingly written to demonstrate how smart the author is, and how stupid the reader is. There is one place where an application programmer could say "Hey, I know, I'll use a continuation!" -- whenever they need a single "global" "OO obje= ct" with a "global variable" in it. I use them for implementing statistics printing and profiling. The idea is simple, the solution is elegant: -- I want to have a single "global" counter which I will increment by one f= rom now until forever. -- I want to have a function to increment it, and I want to call that funct= ion at any time, from anywhere at all. -- every hundreth time that it is called, it will print something like "xyz operations per second" Turns out that continuations offer a marvelously simple, easy-to-understand easy-to-use solution to this problem. You'd think that there would be som= e tutorial or some common "here's the cookbook way of implementing this" but I sure haven't seen one. But once you get the hang of the above exampl= e, one can see how it could be fleshed out into a full-fledged OO-like message-passing system, complete with frames and slots. Continuations do not need to be a swear word; its just that they're badly explained. They are a stumbling block, but that's in part because there's no analogous concept in proceedural languages; so most programmers never have to learn it. > > Decorators are really cool to use: > > Have yet to find a need for one. Sounds like gain-saying. Just because you don't need it, doesn't mean its not useful. "A typical user uses 20% of an application. The problem is, different users use a different 20%". "recall there were dozens of wikis b= efore wikipedia, dozens of search engines before google, dozens of social media sites before facebook" I conclude that the difference between a successful(popular) and a failed (unpopular) tech is often very subtle. For all I know, decorators "done ri= ght" in guile could skyrocket it to the top of the popularity ranking. Or not. = Just be careful in dismissing some of these ideas. > >> 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 prac= tical > > criticism here? Unicode support in guile remains rocky and buggy, as I once again rediscovered recently when pumping Chinese through it. > It would be better to leave Unicode out of Guile's system interface and > have the application encode and decode explicitly where needed. Huh? That would suck. Unless I misunderstand, in which case it would be great. Unicode is just a bunch of bytes that are null-terminated. Gui= le does very stupidly try to convert unicode strings into arrays of wide char= s which is absolutely idiotic, and a total bottleneck for what I do. Its a useless, pointless processing step. I keep planning on submitting a patch to fix th= is but never have time. I regularly have strings that are 10 Mbytes or more, that contain mixtures = of scheme code and chinese characters (in utf8), that I have to send to guile for eval. Anything that would make that faster would be awesome. --linas