[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Imports / inclusion of s.el into Emacs

From: chad
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Sun, 3 May 2020 17:12:00 -0700

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,

On Sat, May 2, 2020 at 8:11 AM João Távora <address@hidden> wrote:

On Sat, May 2, 2020 at 4:04 PM Dmitry Gutov <address@hidden> wrote:
On 02.05.2020 17:18, João Távora 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🐍🐍" 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,

My position is: work on the manual.  Make it prettier, better organized, etc.
Parsimoniously add new names if that really helps.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]