Emacs website, Lisp, and other

Emacs website, Lisp, and other

[Jeremy Bryant]

Reviewing the Emacs website, and previous discussions on this list below
(admittedly not recent, but still relevant).  It seems important to add
some text on Lisp which is not currently there, as per ideas of RMS and
Eli summarised below.

Where is the repo for the Emacs website?
What do people think?



Previous discussions on the subject:
https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00356.html
RMS:
"
> We don't want to set Lisp up against other languages.
> We do want to get across what it offers that benefits
> an editor and environment such as Emacs.

Yes we do, to some extent.  The Emacs web site should say this:

Lisp is the most powerful and elegant of programming languages.  If
you want to see how powerful and elegant a programming language can
be, you need to learn Lisp.  It will give you standard for measuring
other languages.
"

https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00335.html
RMS:
"
Calling Emacs Lisp "python-like" is derogatory to Emacs Lisp.
Python has some of the characteristics that make Lisp superior,
but not all of them.  

Lisp is the most elegant and powerful programming language.  That is
what we should say.  In Lisp, programs are structured data and it is
easy to write other Lisp programs to operate on them.

Programmers that don't know Lisp do not realize what is missing in
other prograamming languages.
"

https://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00200.html
Eli:
"
I believe the same could be true with other aspects.  E.g., is it such
a preposterous assumption that someone might be interested in coding
in Lisp, instead of all the ad-hoc extension languages invented by
other editors?
"

Re: Emacs website, Lisp, and other

[Emanuel Berg]

Jeremy Bryant wrote:

> Lisp is the most powerful and elegant of programming
> languages. If you want to see how powerful and elegant
> a programming language can be, you need to learn Lisp.
> It will give you standard for measuring other languages.

Ah, I don't know, that kind of boasting. Powerful and elegant
are both immeasurable things, well, maybe in electrical
engineering one can measure it.

> Calling Emacs Lisp "python-like" is derogatory to Emacs
> Lisp. Python has some of the characteristics that make Lisp
> superior, but not all of them.

Okay, then everyone should know this is a controversial thing
to say. No one, or very few, would recommend Emacs Lisp as an
alternative to Python 2024.

It will sounds like we are a bunch of fanatics boasting from
our own echo chamber were, inside it, we all are fantastic and
high on Lisp.

Lisp's superiority is a myth.

To me it is more like a drug :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs website, Lisp, and other

[Emanuel Berg]

> Lisp's superiority is a myth.

Most pleasant to the people who have that inclination (they
don't have to be similar in other areas).

It is also Emacs, doing a file for some compiler in some other
Lisp is fun, but not half as fun.

Anyone remembers the Python editor Idle?

That was so incredibly boring I still remember it!

More fun, faster, more integrated, more to do, more variation.
I think one can say. We can say that instead?

But it's just a suggestion, if boasting about the programming
language is what one should do, do it, I'm not bothered with
it - on the contrary. And we can make it better, possibly.

              ______________________________
             //````````````````````````````\\
             $.       new word order        %
             $.       --------------        %
             $.                             %
             $. string proximity by words   %
             $. as a non-strict total order %
             \\____________________________//
              `^^^^^^^^^^^^^^^^^^^^^^^^^^^^`

-- 
underground experts united
https://dataswamp.org/~incal

Emacs website, Lisp, and other

[Christopher Dimech]

> Sent: Monday, August 05, 2024 at 10:55 AM
> From: "Emanuel Berg" <incal@dataswamp.org>
> To: emacs-devel@gnu.org
> Subject: Re: Emacs website, Lisp, and other
>
> Jeremy Bryant wrote:
>
> > Lisp is the most powerful and elegant of programming
> > languages. If you want to see how powerful and elegant
> > a programming language can be, you need to learn Lisp.
> > It will give you standard for measuring other languages.

It all depends on the specific work one is doing.  In some instances
the indented style and excessive use of () makes working with lisp
code harder than other languages.

> Ah, I don't know, that kind of boasting. Powerful and elegant
> are both immeasurable things, well, maybe in electrical
> engineering one can measure it.
>
> > Calling Emacs Lisp "python-like" is derogatory to Emacs
> > Lisp. Python has some of the characteristics that make Lisp
> > superior, but not all of them.

Many people are being forced to use Python especially in many university
graduate schools.  Lisp has always been a choice.

I have no problem with Python.  But many graduate schools whose main aim is
getting as many graduates as they can and publishing as many papers as they
can, have been using Python in ways intended to maximize task completion time,
to the detriment of everything else.  In other words, education for these
graduants has educated them out of education.  The best education one can get
today is by self discovery.  Schools are not the way.

> Okay, then everyone should know this is a controversial thing
> to say. No one, or very few, would recommend Emacs Lisp as an
> alternative to Python 2024.

There is nothing controversial, one simple has to see how things
are in specific situations.

> It will sounds like we are a bunch of fanatics boasting from
> our own echo chamber were, inside it, we all are fantastic and
> high on Lisp.
>
> Lisp's superiority is a myth.
>
> To me it is more like a drug :)

The designers of Lisp had to deal with much more things.  Hence its design has
been very well thought out by extremely good designers.  Today there are many
programmers, but good system designers are rare despite the increase in systematic
education strategies.

> --
> underground experts united
> https://dataswamp.org/~incal
>
>
>

Re: Emacs website, Lisp, and other

[Emanuel Berg]

Christopher Dimech wrote:

> It all depends on the specific work one is doing. In some
> instances the indented style and excessive use of () makes
> working with lisp code harder than other languages.

After writing just a few programs in Python I wrote it pretty
fluently with very few syntax errors and very few stop - if
ever - to just look at the code and figure out - ???. Yet
after doing all this Elisp for all this time both in terms of
intensive hours _and_ many years for it to "assimilate" if you
will I can honestly/regretfully say I'm nowhere close to my
Python fluency after just a few short programs. Well, now
I have lost that as well, of course. And a lot of code even in
Emacs is very difficult to understand. It is the same language
but a completely, many completely different styles.

> Many people are being forced to use Python especially in
> many university graduate schools. Lisp has always been
> a choice.

Hardly. If anywhere, Lisp is stronger at universities.
And around Emacs. Everywhere else it is completely
marginalized. And if you think about what the universities
are, and what Emacs is - Lisp has underperformed grossly if
one assumes it is more expressive and powerful than any other
language. If it is, then it is a joke. But it isn't and it
isn't, it is just a marginalized programming language, like
boxing is a fringe sport or whatever. It still exists, all
is good.

> The best education one can get today is by self discovery.
> Schools are not the way.

They actually do give classes in philosophy.

>> Okay, then everyone should know this is a controversial
>> thing to say. No one, or very few, would recommend Emacs
>> Lisp as an alternative to Python 2024.
>
> There is nothing controversial, one simple has to see how
> things are in specific situations.

Very controversial, if it is boasting like hockey talk or
self-PR it is okay but we can't say that with a straight face
to the youngsters. Not many of us anyway.

> The designers of Lisp had to deal with much more things.
> Hence its design has been very well thought out by extremely
> good designers. Today there are many programmers, but good
> system designers are rare despite the increase in systematic
> education strategies.

I don't know the details of the history but I doubt it
happened that way.

As for educated people, the skills today and the volume of
people doing technology including programming is astronomical
compared to 1958 and also to 1985.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs website, Lisp, and other

[divya]

> Hardly. If anywhere, Lisp is stronger at universities.

Hello, I've been reading the last few exchanges and this strikes to me 
as intriguing. Which univerisities are you aware of, other than the 
places where Felleisen, Friedman et.al (Racket folks) have been active 
to have a serious Lisp-based approach? You no longer have that in MIT in 
any serious capacity either, except a few grad PL Theory classes, one 
doesn't really interact with Lisp in any considerable capacity. And this 
is not really news, even Sussman (co-author of SICP, taught at MIT) 
acknowledged the wave of changing to Python from Lisp[0].

I find this dishonest in the least, to not acknowledge the existing 
conditions as they are.

Regards,

Divya

[0]: 
https://cemerick.com/blog/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program.html

Emacs website, Lisp, and other

[Christopher Dimech]

> Sent: Monday, August 05, 2024 at 10:43 PM
> From: "Emanuel Berg" <incal@dataswamp.org>
> To: emacs-devel@gnu.org
> Subject: Re: Emacs website, Lisp, and other
>
> Christopher Dimech wrote:
>
> > It all depends on the specific work one is doing. In some
> > instances the indented style and excessive use of () makes
> > working with lisp code harder than other languages.
>
> After writing just a few programs in Python I wrote it pretty
> fluently with very few syntax errors and very few stop - if
> ever - to just look at the code and figure out - ???. Yet
> after doing all this Elisp for all this time both in terms of
> intensive hours _and_ many years for it to "assimilate" if you
> will I can honestly/regretfully say I'm nowhere close to my
> Python fluency after just a few short programs. Well, now
> I have lost that as well, of course. And a lot of code even in
> Emacs is very difficult to understand. It is the same language
> but a completely, many completely different styles.

For machine learning etc... the proper thing is using C, not Python.

> > Many people are being forced to use Python especially in
> > many university graduate schools. Lisp has always been
> > a choice.
>
> Hardly. If anywhere, Lisp is stronger at universities.

But mostly for the old-school programmers.  Today, most groups
employ Python.  Go check for yourself if you do not trust me.

For instance, see

2021. Inguva Pavan, Bhute Vijesh, Cheng Thomas, Walker Pierre; "Introducing
students to research codes: A short course on solving partial differential
equations in Python".  Education for Chemical Engineers, Volume 36, Pages 1-11.

> And around Emacs. Everywhere else it is completely
> marginalized. And if you think about what the universities
> are, and what Emacs is - Lisp has underperformed grossly if
> one assumes it is more expressive and powerful than any other
> language. If it is, then it is a joke. But it isn't and it
> isn't, it is just a marginalized programming language, like
> boxing is a fringe sport or whatever. It still exists, all
> is good.

As outlined, the focus should be on C.  Just knowing and using
a single language is the strategy of fools.

> > The best education one can get today is by self discovery.
> > Schools are not the way.
>
> They actually do give classes in philosophy.
>
> >> Okay, then everyone should know this is a controversial
> >> thing to say. No one, or very few, would recommend Emacs
> >> Lisp as an alternative to Python 2024.
> >
> > There is nothing controversial, one simple has to see how
> > things are in specific situations.
>
> Very controversial, if it is boasting like hockey talk or
> self-PR it is okay but we can't say that with a straight face
> to the youngsters. Not many of us anyway.

One simply has to look at things the way they are.  If one does
that, there is no controversy.  The youngsters should not look
up to anybody, not even to us.

> > The designers of Lisp had to deal with much more things.
> > Hence its design has been very well thought out by extremely
> > good designers. Today there are many programmers, but good
> > system designers are rare despite the increase in systematic
> > education strategies.
>
> I don't know the details of the history but I doubt it
> happened that way.
>
> As for educated people, the skills today and the volume of
> people doing technology including programming is astronomical
> compared to 1958 and also to 1985.

But the number of world renowned system designers has gone down.
Certainly few of the caliber as Richard Stallman, Guy Steele,
Leslie Lamport, Edsger Dijkstra, etc.

> --
> underground experts united
> https://dataswamp.org/~incal
>
>
>

Re: Emacs website, Lisp, and other

[Eli Zaretskii]

> From: Jeremy Bryant <jb@jeremybryant.net>
> Date: Sun, 04 Aug 2024 23:27:39 +0100
> 
> Reviewing the Emacs website, and previous discussions on this list below
> (admittedly not recent, but still relevant).  It seems important to add
> some text on Lisp which is not currently there, as per ideas of RMS and
> Eli summarised below.

Why is this important?

> Where is the repo for the Emacs website?

You can find the directions on the Savannah Emacs project page.

> What do people think?

I think it's a relatively minor issue, not worth arguing about.  But
it looks like we are up for such a discussion anyway...

Emacs website, Lisp, and other

[Christopher Dimech]

> Sent: Monday, August 05, 2024 at 11:37 PM
> From: divya@subvertising.org
> To: emacs-devel@gnu.org
> Subject: Re: Emacs website, Lisp, and other
>
> > Hardly. If anywhere, Lisp is stronger at universities.
>
> Hello, I've been reading the last few exchanges and this strikes to me
> as intriguing. Which univerisities are you aware of, other than the
> places where Felleisen, Friedman et.al (Racket folks) have been active
> to have a serious Lisp-based approach? You no longer have that in MIT in
> any serious capacity either, except a few grad PL Theory classes, one
> doesn't really interact with Lisp in any considerable capacity. And this
> is not really news, even Sussman (co-author of SICP, taught at MIT)
> acknowledged the wave of changing to Python from Lisp[0].

I fully agree.  But, the use of Python in universities is also misguided.
In the sense that python codes emanating from universities have hardly any
value, other than the productivity by which new code gets completed.  You
might think that because so much code is being generated, and so many people
have these high degrees, most of them are just servants to the interests
of their advisors.  This is the new idea of the university.  Stay away from
it if you can.

> I find this dishonest in the least, to not acknowledge the existing
> conditions as they are.

If not dishonest. it is misguided.

> Regards,
>
> Divya
>
> [0]:
> https://cemerick.com/blog/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program.html
>
>

Re: Emacs website, Lisp, and other

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 5 Aug 2024 11:23:13 +0200
> 
> > > Calling Emacs Lisp "python-like" is derogatory to Emacs
> > > Lisp. Python has some of the characteristics that make Lisp
> > > superior, but not all of them.
> 
> Many people are being forced to use Python especially in many university
> graduate schools.  Lisp has always been a choice.
> 
> I have no problem with Python.  But many graduate schools whose main aim is
> getting as many graduates as they can and publishing as many papers as they
> can, have been using Python in ways intended to maximize task completion time,
> to the detriment of everything else.  In other words, education for these
> graduants has educated them out of education.  The best education one can get
> today is by self discovery.  Schools are not the way.

Please, everybody, take the Lisp vs Python argument off this list, it
is off-topic here.  If you must discuss this, please use the
emacs-tangents@gnu.org mailing list instead.

Re: Emacs website, Lisp, and other

[Eli Zaretskii]

> Date: Mon, 05 Aug 2024 11:37:24 +0000
> From: divya@subvertising.org
> 
> > Hardly. If anywhere, Lisp is stronger at universities.
> 
> Hello, I've been reading the last few exchanges and this strikes to me 
> as intriguing. Which univerisities are you aware of, other than the 
> places where Felleisen, Friedman et.al (Racket folks) have been active 
> to have a serious Lisp-based approach? You no longer have that in MIT in 
> any serious capacity either, except a few grad PL Theory classes, one 
> doesn't really interact with Lisp in any considerable capacity. And this 
> is not really news, even Sussman (co-author of SICP, taught at MIT) 
> acknowledged the wave of changing to Python from Lisp[0].
> 
> I find this dishonest in the least, to not acknowledge the existing 
> conditions as they are.

Once again, please don't discuss these issues here, they are
off-topic.  We have the emacs-tangents mailing list for this purpose,
please use that instead.

Re: Emacs website, Lisp, and other

[Dr. Arne Babenhauserheide]

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

Emanuel Berg <incal@dataswamp.org> writes:

> Christopher Dimech wrote:
>> The best education one can get today is by self discovery.

I tried that while at school. Luckily my teachers trusted my skills
enough to let me step out of chemistry class for half a year and learn
by myself. And prove my knowledge afterwards.

My takeaway was:

I could learn Chemistry myself. It worked.
But it took three times as much time as learning it in school.

So, having actual, tested experience with both styles of learning,
I disagree. As long as your teachers are somewhat competent, learning in
school is far more efficient than learning only by self discovery.

And if you take it seriously, you develop deeper understanding than when
you only do self discovery (and take that as seriously).

>>> Okay, then everyone should know this is a controversial
>>> thing to say. No one, or very few, would recommend Emacs
>>> Lisp as an alternative to Python 2024.

Having gone from Python to Guile Scheme around 2013, I also disagree ☺

But having said that: I do consider indentation style code more readable
than using mostly parentheses.

After reading people say things like

«allows people to see code how Lispers perceive it. Its structure
 becomes apparent.»,
«it makes Scheme way more “approachable”», and
«I have actually found it insanely useful to getting stuff done»,

I think I have a point.

> I don't know the details of the history but I doubt it
> happened that way.

There is a thread of thoughts by Beka Valentine from just these days
about how hackers tend to mix up who got popular with who is better,
because they don’t like to accept that languages usually do not grow
widespread by Logical Truth. I suggest reading that, before continuing
this discussion.

https://rollenspiel.social/@beka_valentine@kolektiva.social/112905007985491839

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Emacs website, Lisp, and other

[Dr. Arne Babenhauserheide]

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

Hi Eli,

I only saw your "please, emacs-tangent" argument now (didn’t pull new
emails before).

Will keep it off-list.

Sorry for the noise.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Emacs website, Lisp, and other

[Christopher Dimech]

Have opened a thread on emacs-tangents@gnu.org called "Lisp, Python, and other comparisons"
to continue the discussion there.

https://lists.gnu.org/archive/html/emacs-tangents/2024-08/msg00000.html

> Sent: Tuesday, August 06, 2024 at 1:16 AM
> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> To: emacs-devel@gnu.org
> Subject: Re: Emacs website, Lisp, and other
>
> Hi Eli,
> 
> I only saw your "please, emacs-tangent" argument now (didn’t pull new
> emails before).
> 
> Will keep it off-list.
> 
> Sorry for the noise.
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein,
> ohne es zu merken.
> draketo.de
>

Re: Emacs website, Lisp, and other

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Date: Mon, 05 Aug 2024 14:56:14 +0200
> 
> Emanuel Berg <incal@dataswamp.org> writes:
> 
> > Christopher Dimech wrote:
> >> The best education one can get today is by self discovery.
> 
> I tried that while at school. Luckily my teachers trusted my skills
> enough to let me step out of chemistry class for half a year and learn
> by myself. And prove my knowledge afterwards.
> 
> My takeaway was:
> 
> I could learn Chemistry myself. It worked.
> But it took three times as much time as learning it in school.
> 
> So, having actual, tested experience with both styles of learning,
> I disagree. As long as your teachers are somewhat competent, learning in
> school is far more efficient than learning only by self discovery.
> 
> And if you take it seriously, you develop deeper understanding than when
> you only do self discovery (and take that as seriously).
> 
> >>> Okay, then everyone should know this is a controversial
> >>> thing to say. No one, or very few, would recommend Emacs
> >>> Lisp as an alternative to Python 2024.
> 
> Having gone from Python to Guile Scheme around 2013, I also disagree ☺
> 
> But having said that: I do consider indentation style code more readable
> than using mostly parentheses.
> 
> After reading people say things like
> 
> «allows people to see code how Lispers perceive it. Its structure
>  becomes apparent.»,
> «it makes Scheme way more “approachable”», and
> «I have actually found it insanely useful to getting stuff done»,
> 
> I think I have a point.
> 
> > I don't know the details of the history but I doubt it
> > happened that way.
> 
> There is a thread of thoughts by Beka Valentine from just these days
> about how hackers tend to mix up who got popular with who is better,
> because they don’t like to accept that languages usually do not grow
> widespread by Logical Truth. I suggest reading that, before continuing
> this discussion.
> 
> https://rollenspiel.social/@beka_valentine@kolektiva.social/112905007985491839

This is off-topic here, please use the emacs-tangents list instead.

Thanks.

10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Emanuel Berg]

Eli Zaretskii wrote:

> Please, everybody, take the Lisp vs Python argument off this
> list, it is off-topic here. If you must discuss this, please
> use the emacs-tangents@gnu.org mailing list instead.

Sure, but we are allowed to discuss how to make Elisp better?

Since Python has had enormous success, and Lisp hasn't - or if
it had, it lost it - it might be a good ide to analyze what
they (Python) did good.

You might think this is some bängalow discussion just because
certain people are in it. But it doesn't have to be like
that, it can be very hands-on.

Ten things that are annoying with Emacs Lisp from the holster,
and what to do about them:

10. Moving point around all the time. Whatever program, what
    you do is, it feels like, not solving your problem
    algorithmicly, you are just doing endless

    (goto (point-min))
    (prong (end-of-paragraph) (current-column))
    (pos-eol -1)

    (setq exists-after-point (unless (re-search-forward re nil t) (point)))

    Frustration: What has this to do with my problem and
    proposed solution? I understand Emacs grew around its
    function as a text editor, but "everything is in the
    buffer" and "the buffer is the data structure of Emacs",
    that has goon too far and we see a lot of code being
    virtually a very, very long traversal of buffers moving
    around point. So what ought to have been a tolerable
    exception, has become the norm and hailed model to the
    point, as I said earlier, interfaces toward programming
    are so weak it is considered normal that ispell can't even
    to (spell "word") without first outputting it somewhere
    and to the operation on that surface.

    Solution: MVC-ish separation of the interface, the
    computation, and the presentation of the result. To solve
    a problem, get the data into modern data structures with
    modern access methods, apply known algorithms by the book
    known specifically to help this problem rather than
    "Everything goes" Elisp hackin. (Yes you find that stuff
    in libraries, often. Apply on data in data structures, not
    on data as it appears in Emacs buffers.) But how ever well
    one does, it is gonna be _a lot_ of of moving point around
    in Emacs Lisp, so don't worry :)
   
Example of problem from my favorite part of Emacs, ispell.el:

(defun ispell-mime-multipartp (&optional limit)
  "Return multipart message start boundary or nil if none."
  ;; caller must ensure `case-fold-search' is set to t
  (and
   (re-search-forward
    "Content-Type: *multipart/\\([^ \t\n]*;[ \t]*[\n]?[ \t]*\\)+boundary="
    limit t)
   (let (boundary)
     (if (looking-at "\"")
	 (let (start)
	   (forward-char)
	   (setq start (point))
	   (while (not (looking-at "\""))
	     (forward-char 1))
	   (setq boundary (buffer-substring-no-properties start (point))))
       (let ((start (point)))
	 (while (looking-at "[-0-9a-zA-Z'()+_,./:=?]")
	   (forward-char))
	 (setq boundary (buffer-substring-no-properties start (point)))))
     (if (< (length boundary) 1)
	 (setq boundary nil)
       (concat "--" boundary)))))

Moving point around, looking, searching, seeing or not seeing.
This is boring and error prone to write, and error prone to
take over from someone else, or return to after x years.

You don't think in terms of the problem, or the solution for
that matter, you are just somewhere in the buffer and
according the the map you are completely lost!

That is why I have, at place 10 annoying things about Elisp,
excessive movement of point around the buffer, often involving
manual retrieving and editing data from a buffer that, in
execution, might not even look like what you thought it would,
and that was 25 lines ago!

Okay, I know - if only I could be passionate about it.

-- 
underground experts united
https://dataswamp.org/~incal

Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Mon, 05 Aug 2024 18:27:35 +0200
> 
> Eli Zaretskii wrote:
> 
> > Please, everybody, take the Lisp vs Python argument off this
> > list, it is off-topic here. If you must discuss this, please
> > use the emacs-tangents@gnu.org mailing list instead.
> 
> Sure, but we are allowed to discuss how to make Elisp better?

Yopu could try, although it is usually not a useful discussion.

> Since Python has had enormous success, and Lisp hasn't - or if
> it had, it lost it - it might be a good ide to analyze what
> they (Python) did good.
> 
> You might think this is some bängalow discussion just because
> certain people are in it. But it doesn't have to be like
> that, it can be very hands-on.
> 
> Ten things that are annoying with Emacs Lisp from the holster,
> and what to do about them:
> 
> 10. Moving point around all the time. Whatever program, what
>     you do is, it feels like, not solving your problem
>     algorithmicly, you are just doing endless
> 
>     (goto (point-min))
>     (prong (end-of-paragraph) (current-column))
>     (pos-eol -1)
> 
>     (setq exists-after-point (unless (re-search-forward re nil t) (point)))
> 
>     Frustration: What has this to do with my problem and
>     proposed solution? I understand Emacs grew around its
>     function as a text editor, but "everything is in the
>     buffer" and "the buffer is the data structure of Emacs",
>     that has goon too far and we see a lot of code being
>     virtually a very, very long traversal of buffers moving
>     around point. So what ought to have been a tolerable
>     exception, has become the norm and hailed model to the
>     point, as I said earlier, interfaces toward programming
>     are so weak it is considered normal that ispell can't even
>     to (spell "word") without first outputting it somewhere
>     and to the operation on that surface.

There's nothing more natural than an editor analyzing text in a
buffer.  Why it frustrates you is beyond me.

Emacs Lisp is not a general-purpose programming language.  It is a
language for implementing Emacs and Emacs extensions.  Thus, comparing
it with Python is, in general, simply wrong.  We can compare a few
specific aspects, but not the languages as a whole, and definitely not
their success rate: the scope of Emacs Lisp is limited to Emacs, which
is orders of magnitude more narrow than the scope of Python (or any
other general-purpose programming language).

Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Emanuel Berg]

Eli Zaretskii wrote:

> There's nothing more natural than an editor analyzing text
> in a buffer. Why it frustrates you is beyond me.

Sure, as is analyzing chemical substances in chemistry.

And it is well known that instead of using machines and
well-known methods from the outside to do the job, the
chemists are swimming around in the substances mucking around
with individual molecules giving explicit instructions what
should happen for each case?

Oh, no, all computing is the same, basically, we have of
course specific problems and applications here, but instead of
doing the old thing we should move up one level of abstraction
and be there instead, and focus not on "getting the job done"
but instead getting it done in a way that is much better than
what we - to a large extent - have been doing so far.

Everyone has a problem domain with specific characteristics
that isn't the same as do stuff on the detail level,
"everyone" doesn't do that if that is what you thought.

> Emacs Lisp is not a general-purpose programming language.

It doesn't matter what it is, it can be better, we should aim
for that.

> It is a language for implementing Emacs and Emacs
> extensions. Thus, comparing it with Python is, in general,
> simply wrong.

Yes, Python is incomparable to Emacs Lisp and would probably
win quite even against the collective Lisp world, I'm afraid.

Lisp would probably loose to some other languages as well.

> We can compare a few specific aspects, but not the languages
> as a whole, and definitely not their success rate: the scope
> of Emacs Lisp is limited to Emacs, which is orders of
> magnitude more narrow than the scope of Python (or any other
> general-purpose programming language).

Emacs is the bastion of Lisp, if we care about Lisp we should
do what we can to make Elisp more competitive altho we should
focus on getting better, and not compare us to other languages
as we are way too far behind in many areas, I'm afraid.

-- 
underground experts united
https://dataswamp.org/~incal

Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Yuri Khan]

On Mon, 5 Aug 2024 at 23:31, Emanuel Berg <incal@dataswamp.org> wrote:

> 10. Moving point around all the time.[…]
>
>     Frustration: What has this to do with my problem and
>     proposed solution? I understand Emacs grew around its
>     function as a text editor, but "everything is in the
>     buffer" and "the buffer is the data structure of Emacs",
>     that has goon too far and we see a lot of code being
>     virtually a very, very long traversal of buffers moving
>     around point.

In a differently designed API, you[^*] would have iterators into
buffers. And you would want from an iterator everything that is
available from the point, just that there could be many of them
simultaneously and that they wouldn’t affect the real user’s point.
And you would want iterators to be visible in the buffer text when
debugging.

In Elisp, you have save-excursion which protects the user’s point, and
markers which provide multiplicity.

[^*]: I.

Re: 10 problems with Elisp, part 10

[Dr. Arne Babenhauserheide]

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

Emanuel Berg <incal@dataswamp.org> writes:

> Eli Zaretskii wrote:
>
>> There's nothing more natural than an editor analyzing text
>> in a buffer. Why it frustrates you is beyond me.
>
> doing the old thing we should move up one level of abstraction
> and be there instead, and focus not on "getting the job done"
> but instead getting it done in a way that is much better than
> what we - to a large extent - have been doing so far.

After having seen how I could write interactive indentation highlighting
in wisp-mode in a few hours of hacking and a few dozen lines of code,¹ I
disagree with the implication here that the current way is a bad way to
get things done.

If you want to see how Emacs actually outshines other environments, you
need to look no further than the talk Lisp for Everyone — starting at
24:00 if you want the context, or directly into the Emacs at 26:45:
https://archive.fosdem.org/2022/schedule/event/lispforeveryone/

¹ https://hg.sr.ht/~arnebab/wisp/browse/wisp-mode.el?rev=b9f2fb2b4333#L414

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1121 bytes --]

10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Christopher Dimech]

> Sent: Tuesday, August 06, 2024 at 5:03 AM
> From: "Emanuel Berg" <incal@dataswamp.org>
> To: emacs-devel@gnu.org
> Subject: Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)
>
> Eli Zaretskii wrote:
>
> > There's nothing more natural than an editor analyzing text
> > in a buffer. Why it frustrates you is beyond me.
>
> Sure, as is analyzing chemical substances in chemistry.
>
> And it is well known that instead of using machines and
> well-known methods from the outside to do the job, the
> chemists are swimming around in the substances mucking around
> with individual molecules giving explicit instructions what
> should happen for each case?
>
> Oh, no, all computing is the same, basically, we have of
> course specific problems and applications here, but instead of
> doing the old thing we should move up one level of abstraction
> and be there instead, and focus not on "getting the job done"
> but instead getting it done in a way that is much better than
> what we - to a large extent - have been doing so far.
>
> Everyone has a problem domain with specific characteristics
> that isn't the same as do stuff on the detail level,
> "everyone" doesn't do that if that is what you thought.
>
> > Emacs Lisp is not a general-purpose programming language.
>
> It doesn't matter what it is, it can be better, we should aim
> for that.
>
> > It is a language for implementing Emacs and Emacs
> > extensions. Thus, comparing it with Python is, in general,
> > simply wrong.
>
> Yes, Python is incomparable to Emacs Lisp and would probably
> win quite even against the collective Lisp world, I'm afraid.

Python is not great.  But people can believe what they want.

Sometimes we discover unpleasant truths. Whenever we do so, we
are in difficulties: suppressing them is scientifically dishonest,
so we must tell them, but telling them, however, will fire back on us.
If the truths are sufficiently impalatable, our audience is psychically
incapable of accepting them and we will be written off as totally
unrealistic, hopelessly idealistic, dangerously revolutionary, foolishly
gullible or what have you.

Most Computer Science Departments have opted for the easy way out, to
pretend that problems do not exist.  Programming is one of the most
difficult branches of applied mathematics; most mathematicians should
better remain pure mathematicians.

It is practically impossible to teach good programming to students that
have had a prior exposure to Python, as potential programmers they are
mentally mutilated beyond hope of regeneration.

In the good old days physicists repeated each other's experiments, just
to be sure. Today they stick to Python, so that they can share each
other's programs, bugs included.

> Lisp would probably loose to some other languages as well.
>
> > We can compare a few specific aspects, but not the languages
> > as a whole, and definitely not their success rate: the scope
> > of Emacs Lisp is limited to Emacs, which is orders of
> > magnitude more narrow than the scope of Python (or any other
> > general-purpose programming language).
>
> Emacs is the bastion of Lisp, if we care about Lisp we should
> do what we can to make Elisp more competitive altho we should
> focus on getting better, and not compare us to other languages
> as we are way too far behind in many areas, I'm afraid.
>
> --
> underground experts united
> https://dataswamp.org/~incal
>
>
>

Re: 10 problems with Elisp, part 10

[Dr. Arne Babenhauserheide]

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

Christopher Dimech <dimech@gmx.com> writes:

> It is practically impossible to teach good programming to students that
> have had a prior exposure to Python, as potential programmers they are
> mentally mutilated beyond hope of regeneration.

Having learned Scheme after learning Python, I strongly disagree — both
to your point and to your ugly portrayal of people.

You point: Python helps to understand Scheme because it provides
fundamentals to structure reasoning. To separate concerns. To test with
low overhead. To access data in common formats. To do the task you care
about instead of adhering to ceremony. Going from Python to Scheme isn’t
hard. suggest reading "The Adventures of a Pythonista in Schemeland":
http://www.phyast.pitt.edu/~micheles/scheme/

Your portrayal: this dehumanizing language has no place in a discussion.
Badmouthing people does a disservice to any point you want to make.

> In the good old days physicists repeated each other's experiments, just
> to be sure. Today they stick to Python, so that they can share each
> other's programs, bugs included.

Replace "Python" with whatever programming language they use.

If you think, Physicists do not share C++ code, or matlab code, or (yes)
Fortran-code, where did you get this notion? Did you work with them?
(I did)

Did you read code of large weather models?

Meteorologists who prove the deviations of a model down to phase shifts
before they write the first line of code (do you do that before you
write a program?) are still happy to share code. They know what they get
and what they share.
Theoretical meteorology (at least in a faculty that works with that) is
an eye-opener for how primitive software development of typical business
software often is (this is not derogatory: business software has other
main challenges, like staying maintainable in the face of constantly
changing requirements).

Physicists who write a Python tool and then add a Cython part compiled
to C to get native performance and who test this in detail against
different existing tools using multitudes of parameters and datasets
will still happily share code.

Physicists who write a Python model that binds complex atmospheric
transport Fortran code know what they do: they keep the
non-performance-critical parts in Python, because that enables them to
spend more time on the actually critical parts.

Don’t go badmouthing other people.

The disdain spread among software developers against Fortran caused me
to lose a lot of time during my PhD until I finally understood how
misguided it is.

Please don’t repeat that mistake with Python.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

10 problems with Elisp, part 10

[Christopher Dimech]

> Sent: Tuesday, August 06, 2024 at 7:30 AM
> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Emanuel Berg" <incal@dataswamp.org>, emacs-devel@gnu.org
> Subject: Re: 10 problems with Elisp, part 10
>
> Christopher Dimech <dimech@gmx.com> writes:
> 
> > It is practically impossible to teach good programming to students that
> > have had a prior exposure to Python, as potential programmers they are
> > mentally mutilated beyond hope of regeneration.
> 
> Having learned Scheme after learning Python, I strongly disagree — both
> to your point and to your ugly portrayal of people.
> 
> You point: Python helps to understand Scheme because it provides
> fundamentals to structure reasoning. To separate concerns. To test with
> low overhead. To access data in common formats. To do the task you care
> about instead of adhering to ceremony. Going from Python to Scheme isn’t
> hard. suggest reading "The Adventures of a Pythonista in Schemeland":
> http://www.phyast.pitt.edu/~micheles/scheme/
> 
> Your portrayal: this dehumanizing language has no place in a discussion.
> Badmouthing people does a disservice to any point you want to make.

Telling one they are wrong is considered dehumanising in universities these 
days.
 
> > In the good old days physicists repeated each other's experiments, just
> > to be sure. Today they stick to Python, so that they can share each
> > other's programs, bugs included.
> 
> Replace "Python" with whatever programming language they use.
> 
> If you think, Physicists do not share C++ code, or matlab code, or (yes)
> Fortran-code, where did you get this notion? Did you work with them?
> (I did)
> 
> Did you read code of large weather models?
> 
> Meteorologists who prove the deviations of a model down to phase shifts
> before they write the first line of code (do you do that before you
> write a program?) are still happy to share code. They know what they get
> and what they share.

Meteorologists cannot predict the weather.  No matter how clever they think 
they are.  Natural disasters cannot be predicted either.  And more than
half of mathematics papers have mistakes.

> Theoretical meteorology (at least in a faculty that works with that) is
> an eye-opener for how primitive software development of typical business
> software often is (this is not derogatory: business software has other
> main challenges, like staying maintainable in the face of constantly
> changing requirements).
> 
> Physicists who write a Python tool and then add a Cython part compiled
> to C to get native performance and who test this in detail against
> different existing tools using multitudes of parameters and datasets
> will still happily share code.
> 
> Physicists who write a Python model that binds complex atmospheric
> transport Fortran code know what they do: they keep the
> non-performance-critical parts in Python, because that enables them to
> spend more time on the actually critical parts.
> 
> Don’t go badmouthing other people.

We immediately found the audience psychically incapable of accepting truths
Dr. Babenhauserheide !
 
> The disdain spread among software developers against Fortran caused me
> to lose a lot of time during my PhD until I finally understood how
> misguided it is.
> 
> Please don’t repeat that mistake with Python.

My mistake was trying to use Python written by others.  I do not use it
and I reject it. 
 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein,
> ohne es zu merken.
> draketo.de
>

Re: 10 problems with Elisp, part 10

[Emanuel Berg]

Dr Arne Babenhauserheide wrote:

> After having seen how I could write interactive indentation
> highlighting in wisp-mode in a few hours of hacking and
> a few dozen lines of code [...]

Excellent, now have a look at ispell.el - 4 323 lines - or
flyspell.el that is 2 393 lines - you can reduce it a lot,
I take it.

See below, core Emacs seems to consist of 2 117 217 lines of
Elisp so there is a lot for you to reduce.

BTW "doc", I am working on a new Emacs package as we speak :)
This one is gonna be even better :)

Emacs files and lines by the command:

  $ wc -l **/*.el

    1207 admin/admin.el
    1944 admin/authors.el
      69 admin/charsets/mule-charsets.el

         [...]

     182 test/src/xdisp-tests.el
      57 test/src/xfaces-tests.el
      57 test/src/xml-tests.el
 2117217 total

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs website, Lisp, and other

[Dr. Arne Babenhauserheide]

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

Christopher Dimech <dimech@gmx.com> writes:

> Have opened a thread on emacs-tangents@gnu.org called "Lisp, Python, and other comparisons"
> to continue the discussion there.
>
> https://lists.gnu.org/archive/html/emacs-tangents/2024-08/msg00000.html

To subscribe, if you aren’t yet (as I weren’t):
https://lists.gnu.org/mailman/listinfo/emacs-tangents

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: 10 problems with Elisp, part 10

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: Emanuel Berg <incal@dataswamp.org>,  emacs-devel@gnu.org
> Date: Mon, 05 Aug 2024 21:30:18 +0200
> 
> Christopher Dimech <dimech@gmx.com> writes:
> 
> > It is practically impossible to teach good programming to students that
> > have had a prior exposure to Python, as potential programmers they are
> > mentally mutilated beyond hope of regeneration.
> 
> Having learned Scheme after learning Python, I strongly disagree — both
> to your point and to your ugly portrayal of people.
> 
> You point: Python helps to understand Scheme because it provides
> fundamentals to structure reasoning. To separate concerns. To test with
> low overhead. To access data in common formats. To do the task you care
> about instead of adhering to ceremony. Going from Python to Scheme isn’t
> hard. suggest reading "The Adventures of a Pythonista in Schemeland":
> http://www.phyast.pitt.edu/~micheles/scheme/
> 
> Your portrayal: this dehumanizing language has no place in a discussion.
> Badmouthing people does a disservice to any point you want to make.
> 
> > In the good old days physicists repeated each other's experiments, just
> > to be sure. Today they stick to Python, so that they can share each
> > other's programs, bugs included.
> 
> Replace "Python" with whatever programming language they use.
> 
> If you think, Physicists do not share C++ code, or matlab code, or (yes)
> Fortran-code, where did you get this notion? Did you work with them?
> (I did)
> 
> Did you read code of large weather models?
> 
> Meteorologists who prove the deviations of a model down to phase shifts
> before they write the first line of code (do you do that before you
> write a program?) are still happy to share code. They know what they get
> and what they share.
> Theoretical meteorology (at least in a faculty that works with that) is
> an eye-opener for how primitive software development of typical business
> software often is (this is not derogatory: business software has other
> main challenges, like staying maintainable in the face of constantly
> changing requirements).
> 
> Physicists who write a Python tool and then add a Cython part compiled
> to C to get native performance and who test this in detail against
> different existing tools using multitudes of parameters and datasets
> will still happily share code.
> 
> Physicists who write a Python model that binds complex atmospheric
> transport Fortran code know what they do: they keep the
> non-performance-critical parts in Python, because that enables them to
> spend more time on the actually critical parts.
> 
> Don’t go badmouthing other people.
> 
> The disdain spread among software developers against Fortran caused me
> to lose a lot of time during my PhD until I finally understood how
> misguided it is.
> 
> Please don’t repeat that mistake with Python.

This is all again off-topic here.  Please take this sub-thread to
emacs-tangents.

Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Emanuel Berg]

> 10. Moving point around all the time. Whatever program, what
>     you do is, it feels like, not solving your problem
>     algorithmicly, you are just doing endless
>
>     (goto (point-min))
>     (progn (end-of-paragraph) (current-column))
>     (pos-eol -1)

It isn't even "end-of-paragraph", is is
`end-of-paragraph-text'.

This brings up another interesting aspect, namely if moving
point around in a future buffer - if that is our whole
business model and everyone tries really hard to convince
themself it is what everybody does - which is completely wrong
by the way - then answer me, how is is that we have so poor
tools to do it?

Just look above.

There isn't even a way to go to the beginning of the buffer
without combining not "goto" (should be `goto-char' of course)
with `point-min'. `pos-eol' is the only one to my liking of
those I just mentioned as they came up, then.

It does say `current-column' but it doesn't matter because
(end-of-paragraph-text) doesn't return point. Such, and many,
many other examples are why Elisp is filled with constructs
such as

( save-mark-and-excursion ( progn ( move the point somewhere )
(point) )

If anyone really believed in that idea, all such cases would
have been streamlined into single functions ages ago instead
of having programmers put together those meaningless towers
all the time just to retrieve information from what is
supposed to be one of our native methods to do just that.

I can complete the list (9 more) but I don't know, maybe leave
the whole thing at that? I don't want to be too negative.
But the endless moving around point in a future buffer one
envision while typing code - yeah, it is a crazy idea

-- 
underground experts united
https://dataswamp.org/~incal

Re: 10 problems with Elisp, part 10

[Dr. Arne Babenhauserheide]

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

Emanuel Berg <incal@dataswamp.org> writes:

> Dr Arne Babenhauserheide wrote:
>
>> After having seen how I could write interactive indentation
>> highlighting in wisp-mode in a few hours of hacking and
>> a few dozen lines of code [...]
>
> Excellent, now have a look at ispell.el - 4 323 lines - or
> flyspell.el that is 2 393 lines - you can reduce it a lot,
> I take it.

That’s not my point.

My point is that the buffer as abstraction is already pretty good.

If you forgo that, you add a lot of complexity with finding the right
entry points, defining how elisp should interact with text — all while
increasing the separation from regular editing, so creating a package
requires a higher up-front investment to find the right APIs.

As a counter-point: An example of a higher level of abstraction is the
org-mode API. But thinking back how long it took me to get that to
actually do what I needed, I doubt that that’s the model I want for most
packages. But I agree that without this, what I wrote would have been
more brittle.
Another example for specialized APIs that are used by others, too, are
completion APIs — auto-complete or company.


Currently Emacs is the environment I know that has the lowest barrier of
entry for writing a package. To check my memory on that, I now looked at
an IntelliJ plugin that just does replace-regex, and that clocks in at
about 200 LOC, using specialized entry points. To get another sample, I
checked a VS-code extension that just flashes the region on copy. To
implement the equivalent of
    (if mark-active (list (point) (mark)) '())
it needs 20 lines of code.


That said: going by the example of the orgmode API and completion APIs,
building specialized APIs for certain tasks and releasing them as
packages could be a way to move forward to experiment with abstractions.
If similar APIs prove useful for very different tasks, and other people
start using them, that would build a case that generalizing them and
integrating them in Emacs and elisp as a default API could be a good way
forward.


Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Org mode API (was: 10 problems with Elisp, part 10)

[Ihor Radchenko]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> As a counter-point: An example of a higher level of abstraction is the
> org-mode API. But thinking back how long it took me to get that to
> actually do what I needed, I doubt that that’s the model I want for most
> packages. But I agree that without this, what I wrote would have been
> more brittle. ...

May you elaborate a bit on the problems with Org mode API?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Org mode API

[Dr. Arne Babenhauserheide]

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

Ihor Radchenko <yantar92@posteo.net> writes:

> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>
>> As a counter-point: An example of a higher level of abstraction is the
>> org-mode API. But thinking back how long it took me to get that to
>> actually do what I needed, I doubt that that’s the model I want for most
>> packages. But I agree that without this, what I wrote would have been
>> more brittle. ...
>
> May you elaborate a bit on the problems with Org mode API?

I use it to gather all entries for a kanban table and it took me a long
time to understand the match and scope and to find what exactly I get
from org-map-entries,¹ how to get the filtering and scope right, and how
to post-process the elemets.²

And it’s not efficient, because org-map-entries actually gives me far
more than what I need — what I’d actually need is to get the nth org
element matching match and scope for which the passed function does not
return nil.

(the linked code is the result of a lot of tinkering)

Best wishes,
Arne

¹ https://hg.sr.ht/~arnebab/kanban.el/browse/kanban.el?rev=29a36f508ffc#L192

² https://hg.sr.ht/~arnebab/kanban.el/browse/kanban.el?rev=29a36f508ffc#L142
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

      > Solution: MVC-ish separation of the interface, the
      > computation, and the presentation of the result. To solve
      > a problem, get the data into modern data structures with
      > modern access methods, apply known algorithms by the book
      > known specifically to help this problem rather than

That is very abstract and does not propose any change concretely enough
that we could consider it.

I am guessing that "MVC" refers to some Microsoft editor.  Please
don't expect us to have seen it.  Emacs is older than Windows.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: 10 problems with Elisp, part 10

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Date: Tue, 06 Aug 2024 09:14:57 +0200
> 
> Emanuel Berg <incal@dataswamp.org> writes:
> 
> > Dr Arne Babenhauserheide wrote:
> >
> >> After having seen how I could write interactive indentation
> >> highlighting in wisp-mode in a few hours of hacking and
> >> a few dozen lines of code [...]
> >
> > Excellent, now have a look at ispell.el - 4 323 lines - or
> > flyspell.el that is 2 393 lines - you can reduce it a lot,
> > I take it.
> 
> That’s not my point.
> 
> My point is that the buffer as abstraction is already pretty good.

Indeed.  As is looking-at and beginning-of-line, btw.

10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Abraham S.A.H. via Emacs development discussions.]

> Moving point around

I thought it's the strengh point of Emacs.  
Why “Everything being a buffer” is bad?  Other than being tired of it?

Sounds like people who talk about their frustration with Unix's “everything is a file” concept.

Can you explain this with more logics and examples?

10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Abraham S.A.H. via Emacs development discussions.]

> Since Python has had enormous success

Just in being popular you mean right?

I would not learn it otherwise. 

Re: Emacs website, Lisp, and other

[Jeremy Bryant]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jeremy Bryant <jb@jeremybryant.net>
>> Date: Sun, 04 Aug 2024 23:27:39 +0100
>> 
>> Reviewing the Emacs website, and previous discussions on this list below
>> (admittedly not recent, but still relevant).  It seems important to add
>> some text on Lisp which is not currently there, as per ideas of RMS and
>> Eli summarised below.
>
> Why is this important?

It appeared to be an outstanding documentation item to add to the
website, using the summary text written from RMS.

I personally believe it is important and useful in the context of an
introduction to Emacs such as the website.  For new users, or indeed
new contributors, Emacs Lisp may appear an intriguing choice, and that
summary offers a compelling reason for Lisp.


>> What do people think?
>
> I think it's a relatively minor issue, not worth arguing about.  But
> it looks like we are up for such a discussion anyway...

Right, it may not be an issue at all -- up to you -- only a suggestion for
documentation improvement.

Emacs supports many languages, and on this is getting better thanks to eglot,
tree-sitter etc.

I thought the thread implicitly related to Emacs Lisp.  As the elisp manual says:
"The great power of the Lisp language makes it ideal for
other purposes as well, such as writing editing commands."

I should apologise as my initial thread was in retrospect too short on
context.  It wasn't meant to start a sort of flamewar, sorry it has
caused you to respond to many tangents.

Emacs website, Lisp, and other

[Christopher Dimech]

> Sent: Wednesday, August 07, 2024 at 7:09 AM
> From: "Jeremy Bryant" <jb@jeremybryant.net>
> To: "Eli Zaretskii" <eliz@gnu.org>
> Cc: emacs-devel@gnu.org, rms@gnu.org
> Subject: Re: Emacs website, Lisp, and other
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Jeremy Bryant <jb@jeremybryant.net>
> >> Date: Sun, 04 Aug 2024 23:27:39 +0100
> >>
> >> Reviewing the Emacs website, and previous discussions on this list below
> >> (admittedly not recent, but still relevant).  It seems important to add
> >> some text on Lisp which is not currently there, as per ideas of RMS and
> >> Eli summarised below.
> >
> > Why is this important?
>
> It appeared to be an outstanding documentation item to add to the
> website, using the summary text written from RMS.
>
> I personally believe it is important and useful in the context of an
> introduction to Emacs such as the website.  For new users, or indeed
> new contributors, Emacs Lisp may appear an intriguing choice, and that
> summary offers a compelling reason for Lisp.
>
>
> >> What do people think?
> >
> > I think it's a relatively minor issue, not worth arguing about.  But
> > it looks like we are up for such a discussion anyway...
>
> Right, it may not be an issue at all -- up to you -- only a suggestion for
> documentation improvement.
>
> Emacs supports many languages, and on this is getting better thanks to eglot,
> tree-sitter etc.
>
> I thought the thread implicitly related to Emacs Lisp.  As the elisp manual says:
> "The great power of the Lisp language makes it ideal for
> other purposes as well, such as writing editing commands."
>
> I should apologise as my initial thread was in retrospect too short on
> context.  It wasn't meant to start a sort of flamewar, sorry it has
> caused you to respond to many tangents.

Flamewars begin when discussions employ inflated descriptions of a language
For instance, a statement like "The great power of the Lisp language makes it
ideal for other purposes, such as writing editing commands" can be seen as
provocative. Irking those who prefer other languages or who have experienced the
limitations of Lisp in their work.

Understanding the historical context of Emacs Lisp (Elisp) helps mitigate
misunderstandings. Elisp's development was influenced by Richard Stallman's
experiences at MIT, where Lisp was widely used. Stallman chose Lisp for Emacs
because of its flexibility and his familiarity with the language, gained from
working on the Incompatible Timesharing System (ITS) and the Lisp Machine
Operating System.

Words like "great power" are subjective and can be interpreted differently by
different people. Some might view them as an accurate reflection of Lisp's
capabilities, while others might see them as an overstatement, leading to
disagreements.

To avoid flamewars, documentation should strive for balanced and factual descriptions,
providing historical context.

A balanced documentation example would be

Emacs Lisp (Elisp) is a dialect of the Lisp programming language, chosen by
Richard Stallman for its flexibility and his familiarity with it from projects
like the Incompatible Timesharing System (ITS) and the Lisp Machine Operating
System at MIT.

Emacs's design aimed to be compatible with Unix, enhancing its portability and making it
accessible to Unix users.  While Elisp's power and versatility make it well-suited for
writing editing commands, it's important to recognize that different languages have their
own strengths and may be better suited for other specific tasks.

This approach provides necessary background information without making exaggerated claims,
reducing the likelihood of sparking heated debates among users.

RE: [External] : Emacs website, Lisp, and other

[Drew Adams]

> A balanced documentation example would be:
> 
>  Emacs Lisp (Elisp) is a dialect of the Lisp
>  programming language, chosen by Richard Stallman
>  for its flexibility and his familiarity with it...
>
>  While Elisp's power and versatility make it
>  well-suited for writing editing commands, it's
>  important to recognize that different languages
>  have their own strengths and may be better suited
>  for other specific tasks.
> 
> This approach provides necessary background
> information without making exaggerated claims,
> reducing the likelihood of sparking heated debates
> among users.

While I agree with general advice to avoid inflated
language / hyperbole, IMO that description is not
only too subdued, it misses the reasons why Elisp
is important for Emacs:

 > Lisp programming language, chosen by Richard
 > Stallman for its flexibility and his familiarity
 > with it

Flexibility: Certainly, but without some support
that's just a weasel word - unhelpful, near
meaningless.

And RMS didn't choose Lisp because it was what he
was familiar with.  There's a little more to it -
and to Lisp - than you suggest there.  RMS has,
himself, written about it.  You can take him at his
1981 word about why Lisp is important for Emacs.

https://www.gnu.org/software/emacs/emacs-paper.html

  Comprehension of the user's program reaches its
  greatest heights for Lisp programs, because the
  simplicity of Lisp syntax makes intelligent
  editing operations easier to implement, while
  the complexity of other languages discourages
  their users from implementing similar operations
  for them. In fact, EMACS offers most of the same
  facilities as editors such as the Interlisp editor
  which operate on list structure, but combined with
  display editing. The simple syntax of Lisp,
  together with the powerful editing features made
  possible by that simple syntax, add up to a more
  convenient programming system than is practical
  with other languages. Lisp and extensible editors
  are made for each other, in this way. We will see
  below that this is not the only way...

  An on-line extensible system must be able to accept
  and then execute new code while it is running.
  This eliminates most popular programming languages
  except Lisp, APL and Snobol. At the same time,
  Lisp's interpreter and its ability to treat
  functions as data are exactly what we need...

  A PASCAL or PL/I implementation which uses an
  interpreter, and allows the user program to access
  the interpreter data structures sufficiently, could
  be used just as a Lisp implementation would be used.
  However, such implementations are very rare, because
  these languages are not designed for them. If the
  implementor appreciates the importance of the
  interpreter, and of treating functions as data, he
  will usually choose to implement Lisp...

  When a language is used for implementing extensible
  systems, certain control structure and data
  structure features become vital:

   * Global Variables...
   * Dynamic Binding...
   * Variables Local to a File...
   * Hooks...
   * User handling of errors...
   * Non-Local Control Transfer...

  The traditional attitude towards Lisp holds that
  it is useful only for esoteric amusements and
  Artificial Intelligence... The special properties
  of Lisp, which make extensibility possible, are
  a key feature, even though many of the users will
  not be programmers.

tl;dr:

"Lisp and extensible editors are made for each other"

Sure, that was 43 years ago.  But still germane.

 > it's important to recognize that different
 > languages have their own strengths and may be
 > better suited for other specific tasks.

What's the point of saying that in the context for
which you suggest it?

Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Emanuel Berg]

Richard Stallman wrote:

>> Solution: MVC-ish separation of the interface, the
>> computation, and the presentation of the result. To solve
>> a problem, get the data into modern data structures with
>> modern access methods, apply known algorithms by the book
>> known specifically to help this problem rather than
>
> That is very abstract and does not propose any change
> concretely enough that we could consider it.

MVC is a term from CS theory, it means "Model View Control"
and you can summarize it just by saying that data,
data processing, and the interface, those should be
kept apart.

We have an interesting situation where the processing of data
with Elisp is often done directly in the buffer, i.e. _in_
that same data!

This is why Elisp code often gets completely littered with
commands that move point back and forth, that extracts data,
modifies data, inserts it back again, and so on.

What we should do - well, (1) one should be aware of it and
that it is a problem. So for example, instead of sorting
a region in the buffer, one should ask - what does that region
represent? what outputted it? - and then modify that function,
for example to make it accept an optional alternative sorter
or whatever.

And (2), since it is gonna be like this anyway to a huge
extent, to not have Elisp code being completely overrun by
such stuff, we can provide a much neater, more consistent such
set of functions.

So this is bad

(save-mark-and-excursion (progn (forward-paragraph -2) (point)))

This OTOH is much better

(pos-bol &optional N)
(pos-eol &optional N)

So for every unit, we should have pos-unit, pos-unit-beg,
pos-unit-end, and pos-unit-reg (pos-unit should probably be
the same as pos-unit-beg rather than pos-unit-reg for
practical reasons).

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Emacs website, Lisp, and other

[Dr. Arne Babenhauserheide]

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

Drew Adams <drew.adams@oracle.com> writes:
> language / hyperbole, IMO that description is not
> only too subdued

I’ll add that being subdued about strength can actually be harmful.

While false marketing is a problem, not doing marketing and not pointing
out the strengths of your project causes people to use systems that are
less suited to their requirements than your project.

Because other people will use marketing. And marketing works.

But marketing can be honest. Its goal is then to ensure that the people
to whom your project would be useful learn about the project.¹

⇒ Good marketing starts with the existing strengths of a project and
  finds people to whom these strengths are useful.

This also means to use language that conveys enthusiasm.

If you are silent about actual strength of your project, many people to
whom choosing your project would be the best decision will not find your
project when they are in a situation where they can choose it.

So the Emacs website and documentation should not sell elisp short.

Best wishes,
Arne

¹ https://www.draketo.de/anderes/honest-marketing#what-is-good-marketing
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

[External] : Emacs website, Lisp, and other

[Christopher Dimech]

> Sent: Wednesday, August 07, 2024 at 8:35 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Christopher Dimech" <dimech@gmx.com>, "Jeremy Bryant" <jb@jeremybryant.net>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>, "rms@gnu.org" <rms@gnu.org>
> Subject: RE: [External] : Emacs website, Lisp, and other
>
> > A balanced documentation example would be:
> >
> >  Emacs Lisp (Elisp) is a dialect of the Lisp
> >  programming language, chosen by Richard Stallman
> >  for its flexibility and his familiarity with it...
> >
> >  While Elisp's power and versatility make it
> >  well-suited for writing editing commands, it's
> >  important to recognize that different languages
> >  have their own strengths and may be better suited
> >  for other specific tasks.
> >
> > This approach provides necessary background
> > information without making exaggerated claims,
> > reducing the likelihood of sparking heated debates
> > among users.
>
> While I agree with general advice to avoid inflated
> language / hyperbole, IMO that description is not
> only too subdued, it misses the reasons why Elisp
> is important for Emacs:

It was meant as idea and general advice.  Yes, it was subdued.
The information you describe can be added.  My wording was about
the rewriting of some sentences.  Nothing more.

>  > Lisp programming language, chosen by Richard
>  > Stallman for its flexibility and his familiarity
>  > with it
>
> Flexibility: Certainly, but without some support
> that's just a weasel word - unhelpful, near
> meaningless.

That must be Richard's point of view, not ours.

> And RMS didn't choose Lisp because it was what he
> was familiar with.  There's a little more to it -
> and to Lisp - than you suggest there.  RMS has,
> himself, written about it.  You can take him at his
> 1981 word about why Lisp is important for Emacs.

Right.  The practical and historical reasons for choosing a Unix-Lke System
and developing Emacs cannot be attributed solely to technical merit.

> https://www.gnu.org/software/emacs/emacs-paper.html
>
>   Comprehension of the user's program reaches its
>   greatest heights for Lisp programs, because the
>   simplicity of Lisp syntax makes intelligent
>   editing operations easier to implement, while
>   the complexity of other languages discourages
>   their users from implementing similar operations
>   for them. In fact, EMACS offers most of the same
>   facilities as editors such as the Interlisp editor
>   which operate on list structure, but combined with
>   display editing. The simple syntax of Lisp,
>   together with the powerful editing features made
>   possible by that simple syntax, add up to a more
>   convenient programming system than is practical
>   with other languages. Lisp and extensible editors
>   are made for each other, in this way. We will see
>   below that this is not the only way...
>
>   An on-line extensible system must be able to accept
>   and then execute new code while it is running.
>   This eliminates most popular programming languages
>   except Lisp, APL and Snobol. At the same time,
>   Lisp's interpreter and its ability to treat
>   functions as data are exactly what we need...
>
>   A PASCAL or PL/I implementation which uses an
>   interpreter, and allows the user program to access
>   the interpreter data structures sufficiently, could
>   be used just as a Lisp implementation would be used.
>   However, such implementations are very rare, because
>   these languages are not designed for them. If the
>   implementor appreciates the importance of the
>   interpreter, and of treating functions as data, he
>   will usually choose to implement Lisp...

>   When a language is used for implementing extensible
>   systems, certain control structure and data
>   structure features become vital:
>
>    * Global Variables...
>    * Dynamic Binding...
>    * Variables Local to a File...
>    * Hooks...
>    * User handling of errors...
>    * Non-Local Control Transfer...
>
>   The traditional attitude towards Lisp holds that
>   it is useful only for esoteric amusements and
>   Artificial Intelligence... The special properties
>   of Lisp, which make extensibility possible, are
>   a key feature, even though many of the users will
>   not be programmers.
>
> tl;dr:
>
> "Lisp and extensible editors are made for each other"
>
> Sure, that was 43 years ago.  But still germane.
>
>  > it's important to recognize that different
>  > languages have their own strengths and may be
>  > better suited for other specific tasks.
>
> What's the point of saying that in the context for
> which you suggest it?

Emacs Lisp has evolved alongside Emacs, tailored specifically
to meet the needs of the editor. This co-evolution has made Elisp
particularly adept at tasks related to text editing, customization,
and extending Emacs functionalities.

Recognizing that Elisp has become highly specialized helps explain
why it is so effective within Emacs. This specialization is not because
of inherent properties of Lisp but due to focused development efforts
over time.

Other languages can potentially be used to develop Emacs-like editors.
Languages like Ruby, or modern variants of Lisp, such as Clojure, could
be adapted for similar purposes if there were enough focus and development
effort.  Just as Elisp has grown with Emacs, other languages could develop
unique features and optimizations for specific applications.

This recognition encourages a broader appreciation of programming languages
and fosters an open-minded approach.

[External] : Emacs website, Lisp, and other

[Christopher Dimech]

> Sent: Wednesday, August 07, 2024 at 10:10 AM
> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> To: "Drew Adams" <drew.adams@oracle.com>
> Cc: "Christopher Dimech" <dimech@gmx.com>, "Jeremy Bryant" <jb@jeremybryant.net>, "Eli Zaretskii" <eliz@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>, "rms@gnu.org" <rms@gnu.org>
> Subject: Re: [External] : Emacs website, Lisp, and other
>
> Drew Adams <drew.adams@oracle.com> writes:
> > language / hyperbole, IMO that description is not
> > only too subdued
> 
> I’ll add that being subdued about strength can actually be harmful.
> 
> While false marketing is a problem, not doing marketing and not pointing
> out the strengths of your project causes people to use systems that are
> less suited to their requirements than your project.

For Emacs development, the use of Elisp is quite clear.  Customizations
are done in Elisp.  Perhaps add some examples that other editors cannot do.
For instance, with the work of Protesilaos Stavrou, we have accessible
themes.  Astonishing work.
 
> Because other people will use marketing. And marketing works.
> 
> But marketing can be honest. Its goal is then to ensure that the people
> to whom your project would be useful learn about the project.¹
> 
> ⇒ Good marketing starts with the existing strengths of a project and
>   finds people to whom these strengths are useful.
> 
> This also means to use language that conveys enthusiasm.
> 
> If you are silent about actual strength of your project, many people to
> whom choosing your project would be the best decision will not find your
> project when they are in a situation where they can choose it.
> 
> So the Emacs website and documentation should not sell elisp short.

To sell it is by application, not words.  The biggest difficulty is getting
others to use the editor, and to make it easier for them to use elisp to
make emacs work better for them.  It does take some months to get productive
with it though.
 
 
> Best wishes,
> Arne
> 
> ¹ https://www.draketo.de/anderes/honest-marketing#what-is-good-marketing
> -- 
> Unpolitisch sein
> heißt politisch sein,
> ohne es zu merken.
> draketo.de
>

RE: [External] : Emacs website, Lisp, and other

[Drew Adams]

> Drew Adams <drew.adams@oracle.com> writes:
> > language / hyperbole, IMO that description is not
> > only too subdued
> 
> I’ll add that being subdued about strength can actually be harmful.
> 
> While false marketing is a problem, not doing marketing and not pointing
> out the strengths of your project causes people to use systems that are
> less suited to their requirements than your project.
> 
> Because other people will use marketing. And marketing works.
> 
> But marketing can be honest. Its goal is then to ensure that the people
> to whom your project would be useful learn about the project.¹
> 
> ⇒ Good marketing starts with the existing strengths of a project and
>   finds people to whom these strengths are useful.
> 
> This also means to use language that conveys enthusiasm.
> 
> If you are silent about actual strength of your project, many people to
> whom choosing your project would be the best decision will not find your
> project when they are in a situation where they can choose it.
> 
> So the Emacs website and documentation should not sell elisp short.

"marketing", "marketing", "marketing",
"marketing", "marketing", "marketing".

FWIW, a description, accurate or inaccurate, isn't
necessarily marketing.  We're not selling Emacs or
Elisp.  There's no market involved.

(Generations deranged by invasive commodification...)

[External] : Emacs website, Lisp, and other

[Christopher Dimech]

> Sent: Wednesday, August 07, 2024 at 11:09 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: "Christopher Dimech" <dimech@gmx.com>, "Jeremy Bryant" <jb@jeremybryant.net>, "Eli Zaretskii" <eliz@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>, "rms@gnu.org" <rms@gnu.org>
> Subject: RE: [External] : Emacs website, Lisp, and other
>
> > Drew Adams <drew.adams@oracle.com> writes:
> > > language / hyperbole, IMO that description is not
> > > only too subdued
> > 
> > I’ll add that being subdued about strength can actually be harmful.
> > 
> > While false marketing is a problem, not doing marketing and not pointing
> > out the strengths of your project causes people to use systems that are
> > less suited to their requirements than your project.
> > 
> > Because other people will use marketing. And marketing works.
> > 
> > But marketing can be honest. Its goal is then to ensure that the people
> > to whom your project would be useful learn about the project.¹
> > 
> > ⇒ Good marketing starts with the existing strengths of a project and
> >   finds people to whom these strengths are useful.
> > 
> > This also means to use language that conveys enthusiasm.
> > 
> > If you are silent about actual strength of your project, many people to
> > whom choosing your project would be the best decision will not find your
> > project when they are in a situation where they can choose it.
> > 
> > So the Emacs website and documentation should not sell elisp short.
> 
> "marketing", "marketing", "marketing",
> "marketing", "marketing", "marketing".
> 
> FWIW, a description, accurate or inaccurate, isn't
> necessarily marketing.  We're not selling Emacs or
> Elisp.  There's no market involved.
> 
> (Generations deranged by invasive commodification...)
> 

Because marketing today makes extensive use of social sciences, psychology, 
sociology, mathematics, economics, anthropology and neuroscience, the profession
is now widely recognized as a scam.  The same applies to areas such as Human Resources.

Re: [External] : Emacs website, Lisp, and other

[Dr. Arne Babenhauserheide]

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

Christopher Dimech <dimech@gmx.com> writes:

> From: "Drew Adams" <drew.adams@oracle.com>
>> FWIW, a description, accurate or inaccurate, isn't
>> necessarily marketing.  We're not selling Emacs or
>> Elisp.  There's no market involved.
>
> Because marketing today makes extensive use of social sciences, psychology, 
> sociology, mathematics, economics, anthropology and neuroscience, the profession
> is now widely recognized as a scam.  The same applies to areas such as Human Resources.

Such comments are why the honest marketing article has an appendix:

"6. Appendix: Why communicating your project?"
 https://www.draketo.de/anderes/honest-marketing#appendix-why-communicating-your-project

I’ve seen both missing marketing basics and bad marketing ruin projects.
I have never seen honest marketing ruin a project.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: [External] : Emacs website, Lisp, and other

[Emanuel Berg]

Drew Adams wrote:

> And RMS didn't choose Lisp because it was what he was
> familiar with. There's a little more to it - and to Lisp -
> than you suggest there. RMS has, himself, written about it.
> You can take him at his 1981 word about why Lisp is
> important for Emacs.
>
> https://www.gnu.org/software/emacs/emacs-paper.html
>
>   Comprehension of the user's program reaches its greatest
>   heights for Lisp programs, because the simplicity of Lisp
>   syntax makes intelligent editing operations easier to
>   implement, while the complexity of other languages [...]

Sorry, but we don't have _any_ of those advantages :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Emanuel Berg]

Abraham S.A.H." via "Emacs development discussions. wrote:

>> Moving point around
>
> I thought it's the strengh point of Emacs.

When programming, half the time is moving around in the buffer
instead of solving the actual problem.

Not only that, moving around in the buffer is difficult and
error-prone as you don't know how it will look at the point of
code execution, and also moving around and of course
especially _editing_ it inside it changes it, so it is a crazy
situation to encourage.

> Why "Everything being a buffer" is bad?

Because one would like to separate data, data retrieval, data
processing, and how data is displayed.

This is possible to do in Elisp but people have not payed
attention to it which is why many program including such in
core Emacs are very long programs with a lot of moving around
buffers endlessly and this code is all intermixed with
everything else.

Very ugly, boring to write, difficult to read, error-prone
to maintain.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs website, Lisp, and other

[Eli Zaretskii]

> From: Jeremy Bryant <jb@jeremybryant.net>
> Cc: emacs-devel@gnu.org,  rms@gnu.org
> Date: Tue, 06 Aug 2024 20:09:30 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Jeremy Bryant <jb@jeremybryant.net>
> >> Date: Sun, 04 Aug 2024 23:27:39 +0100
> >> 
> >> Reviewing the Emacs website, and previous discussions on this list below
> >> (admittedly not recent, but still relevant).  It seems important to add
> >> some text on Lisp which is not currently there, as per ideas of RMS and
> >> Eli summarised below.
> >
> > Why is this important?
> 
> It appeared to be an outstanding documentation item to add to the
> website, using the summary text written from RMS.
> 
> I personally believe it is important and useful in the context of an
> introduction to Emacs such as the website.  For new users, or indeed
> new contributors, Emacs Lisp may appear an intriguing choice, and that
> summary offers a compelling reason for Lisp.

It is hard to find a good place there to talk about these aspects.
The site introduces Emacs as an editor, and describes its important
features.  Emacs being Emacs, that list is long, but far from
comprehensive.  We could add a paragraph about Lisp there, but then
(a) it would be most probably lost in the (quite long) introduction,
and (b) there are many more aspects of Emacs of the same importance
that could be added, and we must draw the line somewhere.

The way the site solves this dilemma is to focus on user-facing
features.  The fact that Emacs is written in Lisp doesn't fit, IMO.

10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)

[Christopher Dimech]

> Sent: Wednesday, August 07, 2024 at 7:34 PM
> From: "Emanuel Berg" <incal@dataswamp.org>
> To: emacs-devel@gnu.org
> Subject: Re: 10 problems with Elisp, part 10 (was: Re: Emacs website, Lisp, and other)
>
> Abraham S.A.H." via "Emacs development discussions. wrote:
> 
> >> Moving point around
> >
> > I thought it's the strengh point of Emacs.
> 
> When programming, half the time is moving around in the buffer
> instead of solving the actual problem.
> 
> Not only that, moving around in the buffer is difficult and
> error-prone as you don't know how it will look at the point of
> code execution, and also moving around and of course
> especially _editing_ it inside it changes it, so it is a crazy
> situation to encourage.
> 
> > Why "Everything being a buffer" is bad?
> 
> Because one would like to separate data, data retrieval, data
> processing, and how data is displayed.
> 
> This is possible to do in Elisp but people have not payed
> attention to it which is why many program including such in
> core Emacs are very long programs with a lot of moving around
> buffers endlessly and this code is all intermixed with
> everything else.
> 
> Very ugly, boring to write, difficult to read, error-prone
> to maintain.

How the latex and tex modes have been written is an example.
 
> -- 
> underground experts united
> https://dataswamp.org/~incal
> 
> 
>

Re: Emacs website, Lisp, and other

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Jeremy Bryant <jb@jeremybryant.net>
>> Cc: emacs-devel@gnu.org,  rms@gnu.org
>> Date: Tue, 06 Aug 2024 20:09:30 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Jeremy Bryant <jb@jeremybryant.net>
>> >> Date: Sun, 04 Aug 2024 23:27:39 +0100
>> >> 
>> >> Reviewing the Emacs website, and previous discussions on this list below
>> >> (admittedly not recent, but still relevant).  It seems important to add
>> >> some text on Lisp which is not currently there, as per ideas of RMS and
>> >> Eli summarised below.
>> >
>> > Why is this important?
>> 
>> It appeared to be an outstanding documentation item to add to the
>> website, using the summary text written from RMS.
>> 
>> I personally believe it is important and useful in the context of an
>> introduction to Emacs such as the website.  For new users, or indeed
>> new contributors, Emacs Lisp may appear an intriguing choice, and that
>> summary offers a compelling reason for Lisp.
>
> It is hard to find a good place there to talk about these aspects.
> The site introduces Emacs as an editor, and describes its important
> features.  Emacs being Emacs, that list is long, but far from
> comprehensive.  We could add a paragraph about Lisp there, but then
> (a) it would be most probably lost in the (quite long) introduction,
> and (b) there are many more aspects of Emacs of the same importance
> that could be added, and we must draw the line somewhere.
>
> The way the site solves this dilemma is to focus on user-facing
> features.  The fact that Emacs is written in Lisp doesn't fit, IMO.

Agree

Emacs website, Lisp, and other

[Christopher Dimech]

> Sent: Wednesday, August 07, 2024 at 11:13 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Jeremy Bryant" <jb@jeremybryant.net>
> Cc: emacs-devel@gnu.org, rms@gnu.org
> Subject: Re: Emacs website, Lisp, and other
>
> > From: Jeremy Bryant <jb@jeremybryant.net>
> > Cc: emacs-devel@gnu.org,  rms@gnu.org
> > Date: Tue, 06 Aug 2024 20:09:30 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > >> From: Jeremy Bryant <jb@jeremybryant.net>
> > >> Date: Sun, 04 Aug 2024 23:27:39 +0100
> > >> 
> > >> Reviewing the Emacs website, and previous discussions on this list below
> > >> (admittedly not recent, but still relevant).  It seems important to add
> > >> some text on Lisp which is not currently there, as per ideas of RMS and
> > >> Eli summarised below.
> > >
> > > Why is this important?
> > 
> > It appeared to be an outstanding documentation item to add to the
> > website, using the summary text written from RMS.
> > 
> > I personally believe it is important and useful in the context of an
> > introduction to Emacs such as the website.  For new users, or indeed
> > new contributors, Emacs Lisp may appear an intriguing choice, and that
> > summary offers a compelling reason for Lisp.
> 
> It is hard to find a good place there to talk about these aspects.
> The site introduces Emacs as an editor, and describes its important
> features.  Emacs being Emacs, that list is long, but far from
> comprehensive.  We could add a paragraph about Lisp there, but then
> (a) it would be most probably lost in the (quite long) introduction,
> and (b) there are many more aspects of Emacs of the same importance
> that could be added, and we must draw the line somewhere.
> 
> The way the site solves this dilemma is to focus on user-facing
> features.  The fact that Emacs is written in Lisp doesn't fit, IMO.
 
I agree.  Some detail could be added in the introduction to new users
(perhaps in an appendix if things do not fit together well enough).  

For new users, we should mention the immediate benefits.

Customization and Extensibility: Emacs allows users to tailor the editor 
to their specific needs, whether it’s through themes, keybindings, or 
custom commands.

Integration and Efficiency: Emacs integrates various workflows, from code 
editing to project management and even personal organization, offering a 
seamless and efficient experience.

We can also suggest learning paths for users who wish to explore Emacs Lisp 
further, ensuring that this advanced knowledge is available without being a 
barrier to entry.

Emacs website, Lisp, and other

[Christopher Dimech]

> Sent: Wednesday, August 07, 2024 at 7:09 AM
> From: "Jeremy Bryant" <jb@jeremybryant.net>
> To: "Eli Zaretskii" <eliz@gnu.org>
> Cc: emacs-devel@gnu.org, rms@gnu.org
> Subject: Re: Emacs website, Lisp, and other
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Jeremy Bryant <jb@jeremybryant.net>
> >> Date: Sun, 04 Aug 2024 23:27:39 +0100
> >>
> >> Reviewing the Emacs website, and previous discussions on this list below
> >> (admittedly not recent, but still relevant).  It seems important to add
> >> some text on Lisp which is not currently there, as per ideas of RMS and
> >> Eli summarised below.
> >
> > Why is this important?
>
> It appeared to be an outstanding documentation item to add to the
> website, using the summary text written from RMS.
>
> I personally believe it is important and useful in the context of an
> introduction to Emacs such as the website.  For new users, or indeed
> new contributors, Emacs Lisp may appear an intriguing choice, and that
> summary offers a compelling reason for Lisp.

The negative effects of children requiring compelling reasons to
engage in activities are evident. This mindset reduces their
willingness to explore, as they become driven by adult-directed
incentives.  Many foundational skills and knowledge areas, which require
time and effort to master without immediate rewards, are neglected,
limiting their exposure to new ideas and skills.

The dependence on external motivation, leads to a lack of intrinsic drive
and the ability to pursue goals independently. Avoiding challenging
tasks without clear rewards hinders resilience and coping skills, essential
for handling life's difficulties.

Additionally, a constant need for compelling reasons fosters a short-term
mindset, impairing their ability to set and achieve long-term goals both
academically and personally.


> >> What do people think?
> >
> > I think it's a relatively minor issue, not worth arguing about.  But
> > it looks like we are up for such a discussion anyway...
>
> Right, it may not be an issue at all -- up to you -- only a suggestion for
> documentation improvement.
>
> Emacs supports many languages, and on this is getting better thanks to eglot,
> tree-sitter etc.
>
> I thought the thread implicitly related to Emacs Lisp.  As the elisp manual says:
> "The great power of the Lisp language makes it ideal for
> other purposes as well, such as writing editing commands."
>
> I should apologise as my initial thread was in retrospect too short on
> context.  It wasn't meant to start a sort of flamewar, sorry it has
> caused you to respond to many tangents.
>
>
>
>
>

Re: 10 problems with Elisp, part 10

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Would you please move this thread to emacs-tangent!

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs website, Lisp, and other

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I agree.  Some detail could be added in the introduction to new users
  > (perhaps in an appendix if things do not fit together well enough).  

  > For new users, we should mention the immediate benefits.

  > Customization and Extensibility: Emacs allows users to tailor the editor 
  > to their specific needs, whether it’s through themes, keybindings, or 
  > custom commands.

  > Integration and Efficiency: Emacs integrates various workflows, from code 
  > editing to project management and even personal organization, offering a 
  > seamless and efficient experience.

  > We can also suggest learning paths for users who wish to explore Emacs Lisp 
  > further, ensuring that this advanced knowledge is available without being a 
  > barrier to entry.

I agree it would be good to present briefly the benefits of Lisp
and how they affect using Emacs.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: 10 problems with Elisp, part 10

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > My point is that the buffer as abstraction is already pretty good.

  > Indeed.  As is looking-at and beginning-of-line, btw.

I dont know of an editor which doesn't have a concept of buffers or
the buffer.  However, the GNU Emacs approach, where you move poimt and
then call fuctions which operate at poit, is not the only possible way.

Shortly before writing GNU Emacs, I maintained Zwei, the second
Emacs-like editor for the MIT Lisp Machine.  In Zwei, every function
to operate on text required specifying a start and end position as
arguments -- one or wo of them.  Point and the mark existed for users,
but the main calling covention for functions to operate on text was
that you stored positions in Lisp varianles and set point or the mark
only for the user's benefit.

After working with that for a douple of years, I was convinced that
that was clunky, and using point and mark was a better Lisp calling
interface.

In addition, this made it possible to call a function from Lisp just
like the way a user would invoke the same command for editing.  It was
usually convenient to have just one function to call, convenient from
Lisp code and as a user command.

In Zwei one usually needed two different functions for each operation
on text, one to be the keyboard command and one to operate on
a position and return a position.  In GNU Emacs, there is just one
and it works in both ways.

I designed `interactive' to make it easier to do that.

When people criticize this functiob/command calling convention,
it is not clear to me what other alternative they would prefer.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs website, Lisp, and other

[Joel Reicher]

Richard Stallman <rms@gnu.org> writes:

>> Customization and Extensibility: Emacs allows users to tailor 
>> the editor to their specific needs, whether it’s through 
>> themes, keybindings, or custom commands.
...
>> We can also suggest learning paths for users who wish to 
>> explore Emacs Lisp further, ensuring that this advanced 
>> knowledge is available without being a barrier to entry.
>
> I agree it would be good to present briefly the benefits of Lisp 
> and how they affect using Emacs.

I'm ambivalent about Lisp, but I've often wondered whether it was 
"always" going to be the "right" choice for Emacs due to its 
support for destructive update and homoiconicity.

It means modifying the editor's code from within the editor, 
without restarting the editor, is possible, and I'm not sure the 
semantics of other languages support that as straightforwardly.

Thanks and regards,

       - Joel

Re: 10 problems with Elisp, part 10

[Emanuel Berg]

Richard Stallman wrote:

> I dont know of an editor which doesn't have a concept of
> buffers or the buffer. However, the GNU Emacs approach,
> where you move poimt and then call fuctions which operate at
> poit, is not the only possible way. [...]

Well, okay, good effort obviously, and thanks for sharing the
history as well.

> When people criticize this functiob/command calling
> convention, it is not clear to me what other alternative
> they would prefer.

Okay, sure!

I would like something that is spacier, faster, easier to edit
and read, with features to set it up completely.

[
  end  :range     0<   :default 73 :prefix-arg
  step :range-cut 2-10 :default 7
  i    :range     0<=  :default 0
]

Even shorter:

[
  end  :r  0<   :d 73 :pa
  step :rc 2-10 :d 7
  i    :r  0<=  :d 0
]

Also it would have: :prompt-string (:ps), :doc-string (:ds),
and so on.

Since people didn't like my use of the prefix-arg, one would
have to have a :prefix-arg-policy as well then :)

Anyway, not saying anyone should do it necessarily or anything
like that, just saying that would be a fast, safe,
easy-to-edit, and easy-to-read "interface interface" for the
formal parameters, to me, it would be a pretty much optimal
solution for the purpose.

-- 
underground experts united
https://dataswamp.org/~incal

Re: 10 problems with Elisp, part 10

[Emanuel Berg]

>>> Excellent, now have a look at ispell.el - 4 323 lines - or
>>> flyspell.el that is 2 393 lines - you can reduce it a lot,
>>> I take it.
>> 
>> That's not my point.
>> 
>> My point is that the buffer as abstraction is already
>> pretty good.
>
> Indeed. As is looking-at and beginning-of-line, btw.

The buffer is good for editing text and can be used for
various purposes, but for computing as in data-processing in
general, you don't want to retrieve and insert data with
editing commands in a buffer.

But want to have it in specific data structures suited for
whatever purpose one is dealing with.

Faster, safer and much easier to program.

-- 
underground experts united
https://dataswamp.org/~incal

Re: 10 problems with Elisp, part 10

[Emanuel Berg]

> The buffer is good for editing text and can be used for
> various purposes, but for computing as in data-processing in
> general, you don't want to retrieve and insert data with
> editing commands in a buffer.

Grep ispell.el: "excursion" is mentioned 27 times, "goto-char"
56 times, and "point" 161 times. In 4 323 lines of Elisp.

Yet it doesn't have a (spell "word") even.

To me that is completely backwards, as (spell "word") is the
_first_ thing I would setup before even thinking about moving
around in the buffer, any buffer or anywhere else for
that matter.

I think I already said that BTW, so let's drop this issue
then, I'm happy to, anyway.

-- 
underground experts united
https://dataswamp.org/~incal

Re: 10 problems with Elisp, part 10

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sat, 10 Aug 2024 07:41:47 +0200
> 
> > The buffer is good for editing text and can be used for
> > various purposes, but for computing as in data-processing in
> > general, you don't want to retrieve and insert data with
> > editing commands in a buffer.
> 
> Grep ispell.el: "excursion" is mentioned 27 times, "goto-char"
> 56 times, and "point" 161 times. In 4 323 lines of Elisp.
> 
> Yet it doesn't have a (spell "word") even.

ispell.el is an interactive front-end to spell-checking programs, so
its main purpose is interactive invocation to spell-check text in a
buffer.  If you want noninteractive spell-checking, ispell.el is not
for you.

That said, ispell.el does have ispell--run-on-word, which does what
you want (but it requires some setup, see ispell-word).

> To me that is completely backwards, as (spell "word") is the
> _first_ thing I would setup before even thinking about moving
> around in the buffer, any buffer or anywhere else for
> that matter.

That's because you evidently misunderstand the purpose of ispell.el,
see above.

Re: Org mode API

[Ihor Radchenko]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

>> May you elaborate a bit on the problems with Org mode API?
>
> I use it to gather all entries for a kanban table and it took me a long
> time to understand the match and scope and to find what exactly I get
> from org-map-entries,¹ how to get the filtering and scope right,

What exactly was the difficulty? Is there anything that is not clear in
the docstring?

> ... and how
> to post-process the elemets.²

In your function I just see you getting headline title and CUSTOM_ID
property. I am not sure what difficulty you are talking about.

Did you see <https://orgmode.org/manual/Using-the-Property-API.html> and
<https://orgmode.org/manual/Using-the-Mapping-API.html>?

> And it’s not efficient, because org-map-entries actually gives me far
> more than what I need — what I’d actually need is to get the nth org
> element matching match and scope for which the passed function does not
> return nil.

How do you expect Org API to allow such a query? Do you need something
akin tree-sitter query syntax?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: 10 problems with Elisp, part 10

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Okay, sure!

  > I would like something that is spacier, faster, easier to edit
  > and read, with features to set it up completely.

  > [
  >   end  :range     0<   :default 73 :prefix-arg
  >   step :range-cut 2-10 :default 7
  >   i    :range     0<=  :default 0
  > ]

Feel free to implement it.  If it catches on, we might put it in ELPA.
But please use some other mailing list for that project.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: 10 problems with Elisp, part 10

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The buffer is good for editing text and can be used for
  > various purposes, but for computing as in data-processing in
  > general, you don't want to retrieve and insert data with
  > editing commands in a buffer.

Emacs is intended for text editing and designed for text editing.

If you want to use Emacs to do something else, and use a different
data structure, you have strings, lists, vectors, symbols and hash
tables to work with.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [External] : Emacs website, Lisp, and other

[Madhu]

* Emanuel Berg <87le186g3f.fsf@dataswamp.org> :
Wrote on Wed, 07 Aug 2024 07:45:40 +0200:
> Drew Adams wrote:
>> And RMS didn't choose Lisp because it was what he was
>> familiar with. There's a little more to it - and to Lisp -
>> than you suggest there. RMS has, himself, written about it.
>> You can take him at his 1981 word about why Lisp is
>> important for Emacs.
>>
>> https://www.gnu.org/software/emacs/emacs-paper.html
>>
>>   Comprehension of the user's program reaches its greatest
>>   heights for Lisp programs, because the simplicity of Lisp
>>   syntax makes intelligent editing operations easier to
>>   implement, while the complexity of other languages [...]
>
> Sorry, but we don't have _any_ of those advantages :)

I believe elisp (and lisp) had those advantages when this paper was
written. What has chages is now the berated complexity of other
languages (including syntactic elementss) have been dragged into elisp
over the last decade or two, (some of it through exploiting a notional
anti-common-lisp sentiment).  While the basic sexp structure sull seems
the same, now to understand the "modern code" you have to refer
understand and familiarize yourself and read documentation of the
constructs in the other languages before you can understand elisp.

Re: [External] : Emacs website, Lisp, and other

[Emanuel Berg]

Madhu wrote:

>>> Comprehension of the user's program reaches its greatest
>>> heights for Lisp programs, because the simplicity of Lisp
>>> syntax makes intelligent editing operations easier to
>>> implement, while the complexity of other languages [...]
>>
>> Sorry, but we don't have _any_ of those advantages :)
>
> I believe elisp (and lisp) had those advantages when this
> paper was written. What has chages is now the berated
> complexity of other languages (including syntactic
> elementss) have been dragged into elisp over the last decade
> or two, (some of it through exploiting a notional
> anti-common-lisp sentiment). While the basic sexp structure
> sull seems the same, now to understand the "modern code" you
> have to refer understand and familiarize yourself and read
> documentation of the constructs in the other languages
> before you can understand elisp.

I think this is typical for Lisp, it leads to complexity -
more so than many other languages where you just add one more
line to be executed.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Emacs website, Lisp, and other

[Emanuel Berg]

Madhu wrote:

>>> Comprehension of the user's program reaches its greatest
>>> heights for Lisp programs, because the simplicity of Lisp
>>> syntax makes intelligent editing operations easier to
>>> implement, while the complexity of other languages [...]
>>
>> Sorry, but we don't have _any_ of those advantages :)
>
> While the basic sexp structure sull seems the same, now to
> understand the "modern code" you have to refer understand
> and familiarize yourself and read documentation of the
> constructs in the other languages before you can
> understand elisp.

I have 29 656 functions (of those are 8040 interactive) if
this script is correct [1]

For 'emacs -Q', or if you just run the script, the result is:
8559 functions (3014 interactive)

Can that really be right? :O

If you do this on the source:

  awk '/\(defun /{print $2}' **/*.el | sort -u | wc -l

you get: 45 865

This is beyond me. How can we, in 2024, with Emacs development
going on for 39 years, 4 months and 26 days, so far resulting
in the writing of possibly _forty-five thousand_ Elisp
functions - this is excluding ELPA, MELPA, and local code -
how can we ask for basic math functions, functions that give
you every word or sentence in a paragraph, and so on?

Well, one thing is sure, if it really is that bad, let's not
blame Lisp.

[1] https://dataswamp.org/~incal/emacs-init/script/count-funs.el

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Emacs website, Lisp, and other

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Thu, 15 Aug 2024 08:17:16 +0200
> 
> If you do this on the source:
> 
>   awk '/\(defun /{print $2}' **/*.el | sort -u | wc -l
> 
> you get: 45 865
> 
> This is beyond me. How can we, in 2024, with Emacs development
> going on for 39 years, 4 months and 26 days, so far resulting
> in the writing of possibly _forty-five thousand_ Elisp
> functions - this is excluding ELPA, MELPA, and local code -
> how can we ask for basic math functions, functions that give
> you every word or sentence in a paragraph, and so on?

We have everything that we need (and if we need more, we add after
examining and analyzing the needs).  Emacs is not an exercise in
providing set of APIs that satisfies some academical notion of
"completeness", especially not when what's "complete" is judged from a
POV that has very little to do with the actual design and purpose of
Emacs (as opposed to some GP programing language or library).

IOW, if an API is not in the set, it is rarely if ever needed in
Emacs.  If you claim that a function to give you every word in a
sentence or a paragraph is needed, you need to justify that by
describing the relevant real-life use cases that make sense for Emacs
jobs.

> Well, one thing is sure, if it really is that bad, let's not
> blame Lisp.

Indeed.  In fact, there's no "blame" here at all, IMNSHO.

Re: [External] : Emacs website, Lisp, and other

[Emanuel Berg]

Here is some more stats and data on this.

30 434 functions, see random 100 sample below.

Fun fact: Only 1.5% functions are from cl-lib.

(require 'cl-lib)

(defvar funs)
(defvar cl-funs)
(defvar funs-len)
(defvar cl-funs-len)

(mapatoms (lambda (e) (when (functionp e) (cl-pushnew e funs))))
(setq funs-len (length funs))
(setq cl-funs
  (cl-remove-if-not (lambda (e) (eq 0 (string-match "cl-" (symbol-name e)))) funs))
(setq cl-funs-len (length cl-funs))

(defvar oh)
(let ((len (length funs)))
  (setq oh nil)
  (dotimes (_ 100)
    (push (nth (random len) funs) oh)))

(progn
  (insert
    (format "\n\ncl-funs: %d of %d, %.1f%%\n"
            cl-funs-len
            funs-len
            (* 100 (/ cl-funs-len funs-len 1.0))))

  (let ((beg (point)))
    (dolist (o oh)
      (insert (format ";; %s\n" o)))
    (sort-region nil beg (point-max))))

cl-funs: 442 of 30 434, 1.5%

;; ad-has-proper-definition
;; advice--make
;; article-date-iso8601
;; byte-compile-indent-to
;; byte-compile-log-file
;; c-c++-vsemi-p
;; c-electric-brace
;; c-forward-decl-arglist
;; c-partial-ws-p
;; checkdoc-interactive-loop
;; class-of
;; color-xyz-to-xyy
;; debug--variable-list
;; default-boundp
;; delete-region
;; display-buffer-other-frame
;; doc-view-initiate-display
;; ediff-patch-file
;; epa-info-mode
;; epg-key-sub-key-list--cmacro
;; erc-modified-channels-object
;; erc-subseq
;; eshell-mode-hook-f
;; files--ask-user-about-large-file-help-text
;; follow-delete-other-windows-and-split
;; font-lock-debug-fontify
;; gnus-all-score-files
;; gnus-cite-delete-overlays
;; gnus-convert-article-to-rmail
;; gnus-dribble-clear
;; gnus-group-description-apropos
;; gnus-group-update-eval-form
;; gnus-html-cache-expired
;; gnus-message-citation-mode
;; gnus-method-to-server
;; gnus-summary-limit-to-recipient
;; gnus-summary-next-page
;; gnus-summary-show-article-from-menu-as-charset-ibm775
;; hack-connection-local-variables
;; image-dired-jump-thumbnail-buffer
;; image-transform-fit-to-width
;; imap-message-flags-add
;; info-goto-top
;; info-xref-check-all-custom
;; isearch-message
;; isearch-unread
;; ld-script-mode
;; mail-bury
;; mail-mail-followup-to
;; mail-source-start-idle-timer
;; make-face-x-resource-internal
;; make-temp-file-internal
;; map-charset-chars
;; markdown-match-bold
;; markdown-promote
;; menu-bar-left-scroll-bar
;; mh-goto-header-end
;; mh-junk-allowlist-a-msg
;; mh-uncompface
;; mhtml--submode-syntax-table
;; minibuffer-force-complete
;; mm-encode-body
;; mode-line-toggle-modified
;; mouse-set-mark-fast
;; nntp-wait-for
;; nsm-check-tls-connection
;; org-babel-describe-bindings
;; org-babel-edit-prep:emacs-lisp
;; org-decode-time
;; org-force-cycle-archived
;; outline-hide-sublevels
;; package-install-from-archive
;; pcomplete-completions-at-point
;; pcomplete-opt
;; puny-encode-string
;; quote-ref
;; remember-notes
;; scroll-other-window-down
;; set-face-background
;; shell-command-guess-mailcap
;; slime--compile-hotspots
;; slime-autodoc--cache-get
;; slime-prin1-to-string
;; speedbar-buffers-tail-notes
;; speedbar-frame-mode
;; subed--post-command-handler
;; subed-backward-subtitle-text
;; subed-copy-player-pos-to-stop-time
;; subed-jump-to-subtitle-text
;; tab-bar--undefine-keys
;; tab-select
;; vc-bzr-find-revision
;; vc-git-conflicted-files
;; vc-hg-pull
;; w3m-check-refresh-attribute
;; w3m-cookie-retrieve
;; w3m-select-buffer-window-size
;; w3m-tab-drag-mouse-function
;; window-full-height-p
;; xref-find-references-and-replace

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Emacs website, Lisp, and other

[Madhu]

* Emanuel Berg <87ed6qbah6.fsf@dataswamp.org> :
Wrote on Thu, 15 Aug 2024 07:50:45 +0200:
> Madhu wrote:
>
>>>> Comprehension of the user's program reaches its greatest
>>>> heights for Lisp programs, because the simplicity of Lisp
>>>> syntax makes intelligent editing operations easier to
>>>> implement, while the complexity of other languages [...]
>>>
>>> Sorry, but we don't have _any_ of those advantages :)
>>
>> I believe elisp (and lisp) had those advantages when this
>> paper was written. What has chages is now the berated
>> complexity of other languages (including syntactic
>> elementss) have been dragged into elisp over the last decade
>> or two, (some of it through exploiting a notional
>> anti-common-lisp sentiment). While the basic sexp structure
>> sull seems the same, now to understand the "modern code" you
>> have to refer understand and familiarize yourself and read
>> documentation of the constructs in the other languages
>> before you can understand elisp.

[oh wow did I actually write that word salad vomit?! apologies for the
atrocious proofing]

> I think this is typical for Lisp, it leads to complexity -
> more so than many other languages where you just add one more
> line to be executed.

No I think just the number of functions is not a measure of "bad"
complexity", quite the opposited. since a function is an abstraction
that can be understood on itself, and in terms of other abstractions if
needed -- as long as all follow the same pattern, as the upanishadic
dictum states "that by which all things are understood" -- my complaint
would apply more to things like using cl-defmethod (without a spec) and
other constructs that cannot be understood by merely reading, and
involve learning some fp theory and syntax, and require the explicit
tracing of execution - when encoutering a bug - which becomes near
impossible with lexically compiled code.

Re: [External] : Emacs website, Lisp, and other

[Emanuel Berg]

Here are the "worst 25" according to the Elisp below:

  1. gnus      2630
  2. org       1727
  3. erc       1283
  4. slime     1074
  5. mh         714
  6. w3m        710
  7. c          606
  8. comp       603
  9. tramp      475
 10. vc         474
 11. eshell     462
 12. subed      438
 13. cl         423
 14. markdown   420
 15. dired      308
 16. epg        302
 17. url        292
 18. message    273
 19. byte       258
 20. rmail      250
 21. make       218
 22. package    206
 23. widget     202
 24. window     201
 25. custom     192

(require 'cl-lib)

(defun count-list (l)
  (cl-loop
    with res
    with done
    for e in l
    while l
    do (unless (member e done)
         (push (list e (cl-count e l :test #'equal)) res)
         (push e done))
    finally return (cl-sort res #'>= :key #'cadr)))

(defun result-list (l)
  (cl-loop
    with str = ""
    for (e o) in l
    for i from 1
    do (setq str (format "%s\n%3d. %-8s %5d" str i e o))
    finally return str))

(defvar funs)

(setq funs nil)

(mapatoms (lambda (e) (when (and (fboundp e)
                                 (functionp e)
                                 (not (listp e)))
                        (cl-pushnew e funs))))

(length funs) ; 30 443

(setq libs
      (mapcar
        (lambda (e)
          (let* ((str  (symbol-name e))
                 (dash (string-match "-" str)))
            (when dash
              (substring str 0 dash))))
        funs))

(length libs) ; 30 443

(setq libs
      (cl-remove-if
       (lambda (e)
         (or (not e)
             (string-match "(" e)))
       libs))

(length libs) ; 29 761 (-1203)

(setq libs (cl-sort libs #'string<))

(length libs) ; 29 761

(insert "\n" (result-list (seq-take (count-list libs) 25)))

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Emacs website, Lisp, and other

[Emanuel Berg]

Madhu wrote:

>>>>> Comprehension of the user's program reaches its greatest
>>>>> heights for Lisp programs, because the simplicity of
>>>>> Lisp syntax makes intelligent editing operations easier
>>>>> to implement, while the complexity of other languages [...]
>>>>
>>>> Sorry, but we don't have _any_ of those advantages :)
>>>
>>> I believe elisp (and lisp) had those advantages when this
>>> paper was written. What has chages is now the berated
>>> complexity of other languages (including syntactic
>>> elementss) have been dragged into elisp over the last
>>> decade or two, (some of it through exploiting a notional
>>> anti-common-lisp sentiment). While the basic sexp
>>> structure sull seems the same, now to understand the
>>> "modern code" you have to refer understand and familiarize
>>> yourself and read documentation of the constructs in the
>>> other languages before you can understand elisp.
>
> [oh wow did I actually write that word salad vomit?!
> apologies for the atrocious proofing]

No proof, method, or data to back anything up. Not then, not
now. One should just accept that Lisp is the best programming
language with no investigation required, case closed.

>> I think this is typical for Lisp, it leads to complexity -
>> more so than many other languages where you just add one
>> more line to be executed.
>
> No I think just the number of functions is not a measure of
> "bad" complexity", quite the opposited.

... but then one would expect to find almost anything of
everything. And especially all _basic_ stuff.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Emacs website, Lisp, and other

[Emanuel Berg]

source:
  https://dataswamp.org/~incal/emacs-init/meta.el [also yanked last]

data:
  https://dataswamp.org/~incal/emacs-data/meta-funs.txt

cool feature:
  note the aligned tables for arbitrary data - that are also
  minimized

Fun Emacs!

;; (meta--funs 10)

 1. gnus     2364
 2. erc      1302
 3. slime    1092
 4. w3m       663
 5. comp      622
 6. c         592
 7. tramp     482
 8. cl        442
 9. markdown  438
10. eshell    340

;; (meta--funs 100)

  1. gnus        2364
  2. erc         1302
  3. slime       1092
  4. w3m          663
  5. comp         622
  6. c            592
  7. tramp        482
  8. cl           442
  9. markdown     438
 10. eshell       340
 11. dired        327
 12. epg          321
 13. message      291
 14. byte         277
 15. url          240
 16. make         225
 17. package      224
 18. widget       220
 19. window       219
 20. custom       211
 21. mm           202
 22. set          195
 23. bibtex       179
 24. xref         172
 25. mail         168
 26. x            161
 27. isearch      160
 28. tab          157
 29. image        154
 30. Info         147
 31. shr          147
 32. comint       145
 33. js           139
 34. help         137
 35. file         132
 36. archive      131
 37. eww          129
 38. mml          125
 39. nnimap       125
 40. ad           110
 41. find         107
 42. doc          102
 43. completion   101
 44. treesit       99
 45. vc            98
 46. copy          98
 47. diff          95
 48. mouse         93
 49. sldb          92
 50. sh            91
 51. eieio         90
 52. ffap          88
 53. display       87
 54. ispell        85
 55. read          82
 56. project       81
 57. minibuffer    80
 58. dbus          80
 59. frame         79
 60. compilation   79
 61. lisp          78
 62. smie          77
 63. checkdoc      76
 64. tex           74
 65. font          73
 66. nntp          70
 67. auth          70
 68. makefile      69
 69. backtrace     69
 70. sgml          68
 71. rx            67
 72. shell         66
 73. browse        64
 74. outline       62
 75. pcomplete     62
 76. epa           62
 77. menu          61
 78. pr            61
 79. article       60
 80. json          59
 81. common        59
 82. nnheader      58
 83. describe      58
 84. elisp         58
 85. kmacro        57
 86. seq           57
 87. string        57
 88. internal      55
 89. nnmail        54
 90. nnml          52
 91. Man           51
 92. delete        50
 93. face          50
 94. get           47
 95. global        47
 96. nnfolder      46
 97. css           46
 98. insert        45
 99. kill          45
100. org           44

;; (meta--funs 1000)  [see URL for this]

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/meta.el

(require 'cl-lib)

(defun meta--count-list (l)
  (cl-loop
    with res
    with done
    for e in l
    do (unless (member e done)
         (push (list (cl-count e l :test #'equal) e) res)
         (push e done))
    finally return (cl-sort res #'>= :key #'car)))

(defun meta--result-list (l)
  (cl-loop
    with biggest = (length (number-to-string (caar l)))
    with num-len = (length (number-to-string (length l)))
    with longest = (apply #'max (cl-mapcar (lambda (e) (length (cadr e))) l))
    for (n lib) in l
    for i from 1
    for str = (concat str
                (format (concat (format "%%%dd. " num-len)
                                (format "%%-%ds " longest)
                                (format "%%%dd"   biggest)
                                "\n")
                        i lib n))
    finally (insert "\n" str)))

(defun meta--funs (&optional n)
  (or n (setq n 20))
  (let ((num 0)
        (libs)
        (str)
        (dash)
        (par))
    (mapatoms (lambda (e) (when (functionp e)
                            (setq str  (symbol-name e))
                            (setq dash (string-match "-" str))
                            (setq par  (string-match "(" str))
                            (unless par
                              (cl-incf num)
                              (when dash
                                (push (substring str 0 dash) libs))))))
    (with-help-window "*meta*"
      (insert (format "functions: %d\n" num))
      (meta--result-list (cl-subseq (meta--count-list libs) 0 n)))))

;; (meta--funs   10)
;; (meta--funs  100)
;; (meta--funs 1000)

(provide 'meta)

-- 
underground experts united
https://dataswamp.org/~incal