From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: transient Date: Thu, 30 Apr 2020 15:46:02 -0700 Message-ID: References: <83tv12zjx1.fsf@gnu.org> <20200429172739.GB4002@ACM> <20200430115108.GA4287@ACM> <20200430123855.GA1444@tuxteam.de> <20200430185819.GC16852@tuxteam.de> <20200430205440.GB4287@ACM> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000fd397005a489d4c2" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="68709"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philippe Vaucher , tomas@tuxteam.de, Emacs developers To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 01 00:47:52 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jUHyB-000Hjo-0I for ged-emacs-devel@m.gmane-mx.org; Fri, 01 May 2020 00:47:51 +0200 Original-Received: from localhost ([::1]:55870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUHyA-0008Tb-1t for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 18:47:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36748) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUHww-0007cL-Mu for emacs-devel@gnu.org; Thu, 30 Apr 2020 18:46:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUHwk-0008C3-0o for emacs-devel@gnu.org; Thu, 30 Apr 2020 18:46:34 -0400 Original-Received: from mail-yb1-xb30.google.com ([2607:f8b0:4864:20::b30]:34724) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUHwi-00083n-If for emacs-devel@gnu.org; Thu, 30 Apr 2020 18:46:20 -0400 Original-Received: by mail-yb1-xb30.google.com with SMTP id q206so2916502ybg.1 for ; Thu, 30 Apr 2020 15:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zLfqUttKrmTFE6r6ynzrKAYpMSnlL9U2YnO2q+kO584=; b=DwxV9XiEWlv50lDf8NIg5jTJVzcBZ7XgSl94KlU6Nf0y8iWaFSdl57365919hozE2i l5ciSqcGR0vFQN18lgbKOyJajA7ULvVBZccbByZPfoSbSdfCJNWUsg3gxDjI2nbJWt+C hPjDqgc9SXEXTqf3IFitXImvMjbIWu33y/GSJ23Mxe8dL2YPwqcYLCSbBKVes+7jkDEA i/0SkeROcln0ITftcl4C1rmYDAE0/WrNUWcsk0rGfkTiV/BiAMJCLJ4KHWM+UyXPzlFM 7s2MIpdqywN+sT4R0hgSOFljHBddsCSoIgb8cwLEQC+MQgoW9eXH0b0TB2P6+CaG1vRU WKxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zLfqUttKrmTFE6r6ynzrKAYpMSnlL9U2YnO2q+kO584=; b=T7nZ/tyFhAT6r4EviWmCaiOhq7JUGXELqwfgQLwWk7WSKUxYaEY9mQoLJa0dbU4hFw ZMNGC01aJxmnZBFs/ZV8cDJIDQ93Xas+OJTpAQV3brH0tucfftIXDyNquR7SLbHpvCVf 5aX9anmigvuzCc0aCG4kQ0G/Rqr0W0WqTV00NFYLuDEAeBKxKPe5yZnPtPW24ZVOxI5s eha3fmWJmkwaTNHD8sKH7Rz469GC542fH6hzj4QzB2f0efgKgG/tnZnSSoh2Zkk5y+KG J3/rZ6QawK2r6AQDavQzDy/Bi6i+ek9mwFR6xxbt+Xf2lcK4iiAJOM8bPW7Il724nleh l/Wg== X-Gm-Message-State: AGi0PuYw7j4HI3au+tnGXkj45qoTP5vZ2YC2q0GD33gQLD2yH3GO4WiW I7yH/vabfxJcEQx8R0mJ+uTDIQQLSa5spxcvOXc= X-Google-Smtp-Source: APiQypI9kDkzAlY/q6sOsZBR/TNfHcWUp5OvGsWB3l3WBeRNP+OMN9116UEFwLYbJy7c5GWVAbORL+DLoQuO02gwS+0= X-Received: by 2002:a25:e008:: with SMTP id x8mr1770380ybg.295.1588286774391; Thu, 30 Apr 2020 15:46:14 -0700 (PDT) In-Reply-To: <20200430205440.GB4287@ACM> Received-SPF: pass client-ip=2607:f8b0:4864:20::b30; envelope-from=yandros@gmail.com; helo=mail-yb1-xb30.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2607:f8b0:4864:20::b30 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:248281 Archived-At: --000000000000fd397005a489d4c2 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 30, 2020 at 1:55 PM Alan Mackenzie wrote: > What I saw was a relative newcomer to the > group (sorry, I still don't know your past and present) proposing to turn > Emacs Lisp upside down for some uncertain benefit on an uncertain > timescale, and not about to wait on any objections. > You seem to have missed the part of the conversation where he was explicitly asked to make up an example of the sort of thing that he proposed would be helpful: On Wed, Apr 29, 2020 at 2:51 AM Philippe Vaucher wrote: > > Overall I think it's a shame that the Emacs api wasn't designed with >> discoverability/consistency in mind >> >> Would you mind elaborate on this deficiency? I don't think I quite >> understand the complaint. > > > It's hard to really criticize because Emacs was designed ages ago. > > My point is simply this one: when I look at > https://github.com/magnars/dash.el, > https://github.com/NicolasPetton/seq.el or https://github.com/magnars/s.el I > can immediately understand how the library works and how to achieve things. > I can also easily use `C-h f` to find about the function I want. > > In Emacs, parts of it are designed following the same principle, but a lot > of it isn't: ... > Addressing the point, part one: Computer languages (so far) are human languages; almost every example of such we've ever seen uses both regular and irregular rules (Esperanto exists in large part to be the exception that proves the rule). For example, in English, the vast majority of verbs are "regular verbs", and the conjugation thereof (cases, tenses, declensions, etc.) strictly follow a very orderly pattern, such as "jump". This makes them esy to learn, understand, and generate. There are also a small core of "irregular verbs", usually the most common/basic/important concepts in the language, that do not follow these patterns, and use bespoke differences for many of the conjugations. These verbs must simply be rote-learned, but their use is typically so central to communication that people memo(r)ize them relatively quickly. In English (and many other modern languages), common examples are "be", "do", and "have". Emacs Lisp, being a human language, is likely to have these same properties. Elisp in particular is subject to many of the same factors that influenced, for example, modern English, including both partial embrace and partial rejection of historical artifacts, adjustments based on common errors, eras of "fashion" (where acceptible uses shift over time), and dialects, creoles, and pidgins (ESE versus Americanized spoken English). I studied both computer science and linguistics in the past, and I believe this entirely explains why some lisps have/prefer "first" and "rest" while others "car" and "cdr". In this case, nobody is proposing to get rid of the latter, for either regular or irregular verbs. There is, however, a suggestion ("It's a shame...") that elisp might be improved by some careful application of additional words for concepts that don't seem to be core enough to be irregular (that is, that aren't so common that everyone has already internalized the irregular forms), as evidinced by the popularity _amoung new speakers_ of libraries that add such regularity, even where irregular forms already exist (dash.el, seq.el, s.el, map.ap, f.el, etc.). Specific examples were brought up not as proposals to change code, but as an explanitory aid in response to a direct request for such. Addressing the point, part two: "There are only two hard things in computer science: cache invalidation and naming things." I hope this helps, ~Chad. P.S. I actually prefer the alternative formulation: "There are only two hard things in computer science: cache invalidation, naming things, and off by one errors." --000000000000fd397005a489d4c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Apr 30, 2020 at 1:55 PM Alan Mack= enzie <acm@muc.de> wrote:
=C2=A0What I saw was a relati= ve newcomer to the
group (sorry, I still don't know your past and present) proposing to tu= rn
Emacs Lisp upside down for some uncertain benefit on an uncertain
timescale, and not about to wait on any objections.
You seem to have missed the part of the conversation where he = was explicitly asked to make up an example of the sort of thing that he pro= posed would be helpful:

On Wed, Apr 29, 2020 at 2= :51 AM Philippe Vaucher <p= hilippe.vaucher@gmail.com> wrote:
> Overall I think it's a= shame that the Emacs api wasn't designed with discoverability/consiste= ncy in mind

Would you mind elaborate on this deficiency?=C2=A0 I don't think I quit= e
understand the complaint.

It's hard to = really criticize because Emacs was designed ages ago.

<= div>My point is simply this one: when I look at=C2=A0https://github.com/magnars/dash.= el,=C2=A0https://github.com/NicolasPetton/seq.el=C2=A0or=C2=A0https://github.com/magn= ars/s.el=C2=A0I can=C2=A0immediately=C2=A0understand how the library wo= rks and how to achieve things. I can also easily use `C-h f` to find about = the function I want.

In Emacs, parts of it are des= igned following the same principle, but a lot of it isn't: ...

Addressing the point, part one:
Computer languages (so far) are human languages; almost every exam= ple of such we've ever seen uses both regular and irregular rules (Espe= ranto exists in large part to be the exception that proves the rule). For e= xample, in English, the vast majority of verbs are "regular verbs"= ;, and the conjugation thereof (cases, tenses, declensions, etc.) strictly = follow a very orderly pattern, such as "jump". This makes them es= y to learn, understand, and generate. There are also a small core of "= irregular verbs", usually the most common/basic/important concepts in = the language, that do not follow these patterns, and use bespoke difference= s for many of the conjugations. These verbs must simply be rote-learned, bu= t their use is typically so central to communication that people memo(r)ize= them relatively quickly. In English (and many other modern languages), com= mon examples are "be", "do", and "have".

Emacs Lisp, being a human language, is likely to have = these same properties. Elisp in particular is subject to many of the same f= actors that influenced, for example, modern English, including both partial= embrace and partial rejection of historical artifacts, adjustments based o= n common errors, eras of "fashion" (where acceptible uses shift o= ver time), and dialects, creoles, and pidgins (ESE versus Americanized spok= en English). I studied both computer science and linguistics in the past, a= nd I believe this entirely explains why some lisps have/prefer "first&= quot; and "rest" while others "car" and "cdr"= . In this case, nobody is proposing to get rid of the latter, for either re= gular or irregular verbs. There is, however, a suggestion ("It's a= shame...") that elisp might be improved by some careful application o= f additional words for concepts that don't seem to be core enough to be= irregular (that is, that aren't so common that everyone has already in= ternalized the irregular forms), as evidinced by the popularity _amoung new= speakers_ of libraries that add such regularity, even where irregular form= s already exist (dash.el, seq.el, s.el, map.ap, f.el, etc.). Specific examp= les were brought up not as proposals to change code, but as an explanitory = aid in response to a direct request for such.

Addr= essing the point, part two:
"There are only two hard things = in computer science: cache invalidation and naming things."
=
I hope this helps,
~Chad.
=C2=A0
P.S. I actually prefer the alternative formulation:=C2=A0"There= are only two hard things in computer science: cache invalidation, naming t= hings, and off by one errors."=C2=A0
--000000000000fd397005a489d4c2--