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: Imports / inclusion of s.el into Emacs Date: Sun, 3 May 2020 17:12:00 -0700 Message-ID: References: <831ro2tqqx.fsf@gnu.org> <4a1fd3f4-df92-c756-9874-4d07b54148ac@yandex.ru> <3bd09dca-dcdc-7569-e5fb-f6b53397af9d@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000000c2bfc05a4c762d8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="42529"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel , Richard Stallman , Stefan Monnier , Dmitry Gutov To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 04 02:12: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 1jVOj6-000AvV-3t for ged-emacs-devel@m.gmane-mx.org; Mon, 04 May 2020 02:12:52 +0200 Original-Received: from localhost ([::1]:47028 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVOj5-0000EM-4I for ged-emacs-devel@m.gmane-mx.org; Sun, 03 May 2020 20:12:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60308) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVOiX-00089b-4D for emacs-devel@gnu.org; Sun, 03 May 2020 20:12:17 -0400 Original-Received: from mail-yb1-xb2f.google.com ([2607:f8b0:4864:20::b2f]:42627) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jVOiV-0000gH-U5; Sun, 03 May 2020 20:12:16 -0400 Original-Received: by mail-yb1-xb2f.google.com with SMTP id i16so8300462ybq.9; Sun, 03 May 2020 17:12:14 -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=GuulTkzF1Ihe76p0g0aq3MAxkk3bny+mij5SXV2uZcI=; b=PxGMcRe3k1Qkqd1D+vU4JUxk6CftlRT7EjWczv4CvsZSOoYqwUd1L4T8Da1KRwhxgT 9jt9eVeEp557jVqzpR5s2HpeKBdfCiT0NZtbEMQVJyDb7fcBL8JQvBiCBTvClLQdXk1U m+XhsES5OuvBX8rrUDr5u3651iyPhMtoACnB0Xbx12e513Ys5nTBOVkSa8KjsUecsZ7u vYt4GjUXfTUo55i1chR0HpWMtF4ALpnN4G5BrO1oe1/0gMSCVDQxIaFlHrxxAWNwpALi V6JMweqMnuKX55/HKY1iXAT46PS23txdVAkCSybmONF3x45kC5ijvU0f6+fsGOrihuWa XmTg== 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=GuulTkzF1Ihe76p0g0aq3MAxkk3bny+mij5SXV2uZcI=; b=KJ3/IrCwyLH5qyTTDMNfAK88f8A0Q4RZjI7x2F6m8bsG48FgYwcZ2Et9fK8fvX1CSN aXRBSuMtpPgRYbMHpMuJIGq//vteaIcWYnh2ZkQuxdDRZ9NUufWjZF/pGR5vt+hyYKcx 1T+8OHtp90SUwuOkXhjF6T/LGs1njQzFlfVZpGGa8irLMttcoQKeMF/4xGV4ZxdCvxBT b1KgwUmlpOfXOJyNGVyQvlfv1UvAPDAP7cnEzL3WlExEiMvmtbiz8uNlTryavV9mB8OA nHO+mAoEPWKPtblsukLgPEasxecijTIVcwidgsZY4MJTVpNcS5JFfNGCXJEE9OTW6pBQ kxFw== X-Gm-Message-State: AGi0PuZ2KTFlBg+QR86MDlq0qRUj+H2fhaLfSGa7CmO1dBWKoLhtfHdq v54VH0j27kipz2VygIRKLifoqrqkZ8th6PhIcr1rvTLW X-Google-Smtp-Source: APiQypLk5osY1iq8ZL6CFxMULGXdy79qKyeAG5Nw/Y7KEzWT1xg9ZcmL31zuoSXVmZ05de+9Yr0+bjozJX7R3yZLZKg= X-Received: by 2002:a25:d955:: with SMTP id q82mr20985767ybg.502.1588551133963; Sun, 03 May 2020 17:12:13 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::b2f; envelope-from=yandros@gmail.com; helo=mail-yb1-xb2f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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:248751 Archived-At: --0000000000000c2bfc05a4c762d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is a long-standing school of computer programmers who learn to code (not algorithms, not group communication, not conveying intention clearly, but the mechanical "coding" parts) from reading manuals and practicing with projects (real or "learning" or both). I'm from that school myself. People from this school tend (large generalization admitted) to learn a small core from a tutorial, and then glean the rest of the practice of coding (often, "how to use libraries") by reading manuals (a large part of the unix `man' tradition, for example). There is also a very large group of professional, prolific programmers who learn coding through interactive exploration of APIs. This isn't just limited to interpreted vs. compiled languages (although I believed that it comes in part from the rise of teaching via interpreted languages); it also comes out of the practice of learning via auto-complete and live documentation. It also has roots in the rise of problem solving via searching on google/stack exchange/etc. Like most communities, there are extremes: the grognard who cares why creat() lost the final `e' and thinks that X is a waste of resources might be at one end, while the front-end developer who cargo-cults together javascript frameworks might be at the other. The interesting part for the discussion here is that each represents a different tendency towards "learning coding" (which even super-experienced programmers do when approaching a new system). That some people will prefer to learn by groking a manual before opening an editor and others by skimming an overview and relying on completion and searching should not surprise us. Cruically, I would go further and say that Emacs will be poorer over-all if it insists on supporting only one part of this spectrum. I think that it's fair to say that it currently leans away from the method that a large number of new coders are demonstrating that they prefer. The question is if and how far emacs is willing to change to adapt. I hope that helps, ~Chad On Sat, May 2, 2020 at 8:11 AM Jo=C3=A3o T=C3=A1vora = wrote: > > > On Sat, May 2, 2020 at 4:04 PM Dmitry Gutov wrote: > >> On 02.05.2020 17:18, Jo=C3=A3o T=C3=A1vora wrote: >> > As Philippe himself has pointed out, there's the trade-off between >> > convey information and a long-a$$ name, for example. So we >> > _can_ use that as argument, in the opposite part of the spectrum. >> > I for one think that expecting names to tell us everything, or >> > even a lot, is naive, a losing battle. And, yes, naming_is_ hard >> > it's one of the 2 hard ones along with cache invalidation and >> > off-by-one. >> >> Can we agree, though, that 'concat' and 'append' are too far from the >> "long-a=F0=9F=90=8D=F0=9F=90=8D" end of the spectrum? >> >> I hesitate to propose a renaming because there's a lot of history, but >> just having a string-concat alias could improve the situation. >> > > Sure I'd agree to that. (though maybe its rather concat-to-string > hehehe). > That's quite different from adding a zillion new s- words because clojure= , > tho. > > My position is: work on the manual. Make it prettier, better organized, > etc. > Parsimoniously add new names if that really helps. > > Jo=C3=A3o > > > --0000000000000c2bfc05a4c762d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is a long-standing school of comput= er programmers who learn to code (not algorithms, not group communication, = not conveying intention clearly, but the mechanical "coding" part= s) from reading manuals and practicing with projects (real or "learnin= g" or both). I'm from that school myself. People=C2=A0from this sc= hool tend (large generalization admitted) to learn a small core from a tuto= rial, and then glean the rest of the practice of coding (often, "how t= o use libraries") by reading manuals (a large part of the unix `man= 9; tradition, for example).

There is also a very large= =C2=A0group of professional, prolific programmers who learn coding through = interactive exploration of APIs. This isn't just limited to interpreted= vs. compiled languages (although I believed that it comes in part from the= rise of teaching via interpreted languages); it also comes out of the prac= tice of learning via auto-complete and live documentation. It also has root= s in the rise of problem solving via searching on google/stack exchange/etc= .

Like most communities, there are extremes: the g= rognard who cares why creat() lost the final `e' and thinks that X is a= waste of resources might be at one end, while the front-end developer who = cargo-cults together javascript frameworks might be at the other. The inter= esting part for the discussion here is that each represents a different ten= dency towards "learning coding" (which even super-experienced pro= grammers do when approaching a new system). That some people will prefer to= learn by=C2=A0groking a manual before opening an editor and others by skim= ming an overview and relying on completion and searching should not surpris= e us. Cruically, I would go further and say that Emacs will be poorer over-= all if it insists on supporting only one part of this spectrum.=C2=A0 I thi= nk that it's fair to say that it currently leans away from the method t= hat a large number of new coders are demonstrating that they prefer. The qu= estion is if and how far emacs is willing to change to adapt.=C2=A0=C2=A0

I hope that helps,
~Chad
=
= On Sat, May 2, 2020 at 8:11 AM Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com> wrote:=


= On Sat, May 2, 2020 at 4:04 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
On 02.05.2020 17:18, Jo=C3=A3o T= =C3=A1vora wrote:
> As Philippe himself has pointed out, there's the trade-off between=
> convey information and a long-a$$ name, for example. So we
> _can_=C2=A0 use that as argument, in the opposite part of the spectrum= .
> I for one think that expecting names to tell us everything, or
> even a lot, is naive, a losing battle.=C2=A0 And, yes, naming_is_=C2= =A0 hard
> it's one of the 2 hard ones along with cache invalidation and
> off-by-one.

Can we agree, though, that 'concat' and 'append' are too fa= r from the
"long-a=F0=9F=90=8D=F0=9F=90=8D" end of the spectrum?

I hesitate to propose a renaming because there's a lot of history, but =
just having a string-concat alias could improve the situation.

Sure I'd agree to that.=C2=A0 (though maybe its= rather concat-to-string hehehe).
That's quite different= from adding a zillion new s- words because clojure,
tho.

My position is: work on the manual.=C2=A0 Make it pr= ettier, better organized, etc.
Parsimoniously add new names if th= at really helps.

Jo=C3=A3o


--0000000000000c2bfc05a4c762d8--