Re: Imports / inclusion of s.el into Emacs

[chad <yandros@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3314 bytes --]

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ão Távora <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ã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,
> tho.
>
> My position is: work on the manual.  Make it prettier, better organized,
> etc.
> Parsimoniously add new names if that really helps.
>
> João
>
>
>

[-- Attachment #2: Type: text/html, Size: 4222 bytes --]