RE: list of elisp primitives ?

[arthur miller]

I think you are thinking from the wrong end. As a consult I had opportunity to work with all kind of languages I never thought I would work with and of which I had no idea what APIs where available or what was idiomatic coding.

Anyway my approach was always to think in general programming terms of repetition, conditional, aggregations etc. I would then lookup what I needed to find out details of syntax and exposed libraries. 

I believe programming, and any programming language is best learned by doing. Especially when you already know how machine works and have knowledge of algorithms, data structures and program organization. 

If you have seen thevlegendaru K&R C book, then that is a bitwhat I mean. I don't think picking up some small subset of API and giving it to people and telling them to make something with it is the necessary the best approach. Probably to show them basics on small exercises and teach them how to lookup information they need further. Yes it takes time to lookup stuff, but that is the nature of the thing.

If we make an analogy with Lego bricks, then yes one can see library functions as bricks to be combined, but just as Lego bricks, and everything else in life, one has to know what one wants to make before one starts to build it, otherwise it will just be random mess.

Skickat från min Samsung Galaxy-smartphone.

-------- Originalmeddelande --------

Från: Jean-Christophe Helary <address@hidden>

Datum: 2019-12-26 18:39 (GMT+01:00)

Till: Emacs developers <address@hidden>

Ämne: Re: list of elisp primitives ?

> On Dec 23, 2019, at 2:31, Drew Adams <address@hidden> wrote:
>
>> I'm trying ... to find a limited subset of
>> functions that one can use to program in elisp
>                                ^^^^^^^^^^^^^^^^
>> and do non-trivial things but that do not
>      ^^^^^^^^^^^^^^^^^^^^^
>> involve searching the reference at all times.
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> That's not what a list of subrs gives you, at all.
> A subr is just a function coded in C, not in Lisp.
> Likewise, for other things, such as variables,
> that might be defined in C.
>
> The choice of whether to implement something in C
> has nothing to do with, and is no guide for, ease
> in learning or how often something is used in
> typical Elisp code.

I'm not suggesting that implementing lisp functions in C is related to ease of learning or anything.

My idea, which may be wrong, is that lisp code uses building blocks to provide more advanced functions and that the most basic blocks are lisp functions implemented in C.

Hence, knowing the building blocks (or a few dozen useful ones) can give a clearer idea of what to do with elisp in general.

Mind you, I too am trying to find my way around and it's not easy. My pet peeve is "discoverability" and for now despite the info/doc integration, I'm still very much struggling.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune