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: Emacs website, Lisp, and other

[Alan Mackenzie]

Hello, Emanuel.

On Mon, Aug 05, 2024 at 00:55:48 +0200, Emanuel Berg wrote:
> 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 :)

To understand the opposite point of view, read one of Paul Graham's
essays at https://paulgraham.com/icad.html, where he describes 9
novelties introduced by Lisp into programming in 1958, and how most, but
not all, of these have since been adopted by lesser languages.

My own view is that Lisp indeed is one of the top languages, but that
Common Lisp is too big, and thus too difficult, to learn for most
programmers.  For those who succeed in learning it, their productivity
will be enormous whilst using it.  Maybe this productivity could be
matched by other "strange" languages (Haskell, perhaps?), but not by
"normal" languages such as C, C++, Java, Python or perl.  I think it a
pity that a moderate sized Lisp, something around the size of Emacs Lisp
without the cl-* extensions, never made it as a general purpose language
alongside the above.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

Emacs website, Lisp, and other

[Christopher Dimech via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

Alan, we both opened a discussion on tangents.



> Sent: Tuesday, August 06, 2024 at 8:03 AM
> From: "Alan Mackenzie" <acm@muc.de>
> To: emacs-tangents@gnu.org
> Subject: Re: Emacs website, Lisp, and other
>
> Hello, Emanuel.
>
> On Mon, Aug 05, 2024 at 00:55:48 +0200, Emanuel Berg wrote:
> > 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 :)
>
> To understand the opposite point of view, read one of Paul Graham's
> essays at https://paulgraham.com/icad.html, where he describes 9
> novelties introduced by Lisp into programming in 1958, and how most, but
> not all, of these have since been adopted by lesser languages.
>
> My own view is that Lisp indeed is one of the top languages, but that
> Common Lisp is too big, and thus too difficult, to learn for most
> programmers.  For those who succeed in learning it, their productivity
> will be enormous whilst using it.  Maybe this productivity could be
> matched by other "strange" languages (Haskell, perhaps?), but not by
> "normal" languages such as C, C++, Java, Python or perl.  I think it a
> pity that a moderate sized Lisp, something around the size of Emacs Lisp
> without the cl-* extensions, never made it as a general purpose language
> alongside the above.
>
> > --
> > underground experts united
> > https://dataswamp.org/~incal
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>
> ---
> via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
>

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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: Emacs website, Lisp, and other

[Jean Louis]

* Alan Mackenzie <acm@muc.de> [2024-08-05 23:04]:
> To understand the opposite point of view, read one of Paul Graham's
> essays at https://paulgraham.com/icad.html, where he describes 9
> novelties introduced by Lisp into programming in 1958, and how most, but
> not all, of these have since been adopted by lesser languages.

I have read it, of course articles by Graham are very insightful.

> My own view is that Lisp indeed is one of the top languages, but that
> Common Lisp is too big, and thus too difficult, to learn for most
> programmers.

My personal view on Common Lisp at the time when I was learning it was
that it was childish simple as compared to previous programming
languages I knew. I even got impression that people who loved Guile,
Scheme, Emacs Lisp, Common Lisp are bragging over the childish easy
language. Learning was not hard, it was pleasure, and I was feeling
like coming back home.

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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: Emacs website, Lisp, and other

[Immanuel Litzroth]

[-- Attachment #1.1: Type: text/plain, Size: 2701 bytes --]

Matthias Felleisen has done work on comparing programming languages:
https://jgbm.github.io/eecs762f19/papers/felleisen.pdf
Also some of the practical aspects of using Python vs other languages have
been documented here:
https://haslab.github.io/SAFER/scp21.pdf
i


On Mon, Aug 5, 2024 at 10:03 PM Alan Mackenzie <acm@muc.de> wrote:

> Hello, Emanuel.
>
> On Mon, Aug 05, 2024 at 00:55:48 +0200, Emanuel Berg wrote:
> > 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 :)
>
> To understand the opposite point of view, read one of Paul Graham's
> essays at https://paulgraham.com/icad.html, where he describes 9
> novelties introduced by Lisp into programming in 1958, and how most, but
> not all, of these have since been adopted by lesser languages.
>
> My own view is that Lisp indeed is one of the top languages, but that
> Common Lisp is too big, and thus too difficult, to learn for most
> programmers.  For those who succeed in learning it, their productivity
> will be enormous whilst using it.  Maybe this productivity could be
> matched by other "strange" languages (Haskell, perhaps?), but not by
> "normal" languages such as C, C++, Java, Python or perl.  I think it a
> pity that a moderate sized Lisp, something around the size of Emacs Lisp
> without the cl-* extensions, never made it as a general purpose language
> alongside the above.
>
> > --
> > underground experts united
> > https://dataswamp.org/~incal
>
> --
> Alan Mackenzie (Nuremberg, Germany).
>
> ---
> via emacs-tangents mailing list (
> https://lists.gnu.org/mailman/listinfo/emacs-tangents)
>


-- 
-- A man must either resolve to point out nothing new or to become a slave
to defend it. -- Sir Isaac Newton

[-- Attachment #1.2: Type: text/html, Size: 3759 bytes --]

[-- Attachment #2: Type: text/plain, Size: 92 bytes --]

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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.

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: 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.

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

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

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2024-08-05 19:31]:
> 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.

Do you mean making Elisp better in the eyes of the world, or technically for Elisp users?

There are obviously many Elisp users, worth enough for developing it
technically, improving it, that is fine and good. And developers are
doing it. We are here in society of Elisp users.

For the eyes of the world, does it matter? I do not see how it does
matter.  Last time I checked, there must be millions of Emacs
users. Not all of them are loud and talking. I just guess that
majority does not even know about Elisp. But there is large number of
Emacs users, as there is large number of GNU/Linux users, and growing.

They may open editor and write something. They may not know about
Elisp, though they soon find out, so it is surely growing. Watching
our mailing lists I can see new users coming.

Comparisons like Python vs Elisp are useless as it is just interesting
for discussion and some language wars in old style.

What is useful is practical program, software, which is made and
provides final benefits.

A single program, no matter the language, can provide huge success.

For more technical insight into the war general Lisp vs Python:
http://www.norvig.com/python-lisp.html

>     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 :)

Statements were exaggerated. You have various data structures, and if
you need to operate on buffer, operate. Personally I operate on
hashes, and lists, and vectors, etc. Not on buffers. I cannot find
your statement universal.

> 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.

Come on. All programming is about looking, searching, and of course it
can be boring and error prone, I remember machine language, of course
it is error prone, there is no programming language not error prone.

> 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 some developers are lost, some are okay with it.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: Emacs website, Lisp, and other

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2024-08-06 22:53]:
> Flamewars begin when discussions employ inflated descriptions of a language

I like it.

> 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.

Isn't praise for each programming language found in their books?!

Nothing wrong about it.

> 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.

The context remains relevant, particularly regarding great
power. There are very few editors like Emacs, and that context is
still applicable today.

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

I was thinking fun started, and now you wish to avoid it.

> 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.

That above is Boring, come on, here is better version:

Emacs Lisp (Elisp) is not just any programming language; it's the
beating heart of the ultimate text editor, Emacs. Chosen by the
brilliant Richard Stallman for its unparalleled flexibility, Elisp
empowers users to customize their editing experience in ways that are
simply impossible with other editors. Stallman’s expertise, honed
through groundbreaking projects like the Incompatible Timesharing
System (ITS) and the Lisp Machine Operating System at MIT, solidified
Elisp as the backbone of Emacs, transforming it into an editor that
transcends mere text editing. With Elisp, users tap into a world of
infinite possibilities, tailoring Emacs to fit their every need,
making it the best choice for anyone serious about productivity and
creativity. Why settle for less when you can harness the power of
Elisp in the finest editor ever created? Emacs truly sets the
standard!

Emacs is not just an editor; it is a revolution in the world of text
manipulation, a sophisticated powerhouse that redefines the very
concept of what an editor can be! Its design, meticulously crafted
with unparalleled attention to compatibility with Unix, catapults it
to a level of portability that no other editor can even dare to
approach.

With the incredible capabilities of Elisp, the very lifeblood of
Emacs, users have at their fingertips a relentless, supercharged tool
for writing editing commands that eclipses the functionality of all
other editors combined! The possibilities are limitless—commanding
every aspect of your workflow with elegance and precision that’s
simply unattainable in any other editing environment.

While other programming languages might boast their unique strengths,
they pale in comparison to the sheer versatility of Emacs and
Elisp. Why settle for mediocrity when you can wield the best? Emacs is
not merely suited for specific tasks; it is a universal toolkit that
transforms the mundane into the extraordinary, empowering every user
to achieve feats of productivity that would leave mere mortals in awe.

Emacs is, without a doubt, the ultimate editor, the crown jewel of
software development, a perennial favorite for those who value true
mastery over their editing experiences. Embrace the greatness of
Emacs, and you will never look back!


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2024-08-07 02:11]:
> > 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.

Emacs is product, and can be well sold, it is power text editor, with
too many features and extensibility. Perfect software product. Manage
anything, compan, clinic, hospital, memberships, calculations,
spreadsheets, plethora of features.

It is sellable. License allows it.

Just sell.

I could not purchase GNU CD-ROMs back in time, it was too much money
in the Wittwer library in Stuttgart, but later I purchased GNU/Linux
where Emacs was marketed and sold. So I did buy it.

Nobody forbid selling Emacs.

I can do supermarket point of sales on Emacs. Or clinic
management. Anything.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2024-08-15 13:34]:
> 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.

Finally, reason from your keyboard typing. Before your fingers start a
rebellion and declare themselves the new rulers of your thoughts! 🖥️👑

:-)

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2024-08-15 10:05]:
> 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)

I got 983 in my Emacs Lisp directory. So I do not fund 30,000
functions in source too much really.


---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Drew Adams via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

> > > 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.

GNU's not selling Emacs or Elisp.  They're not being
produced for exchange/sale by GNU.  It's not commodity
production.

(But you can still buy a printed manual from GNU, I assume.)

> Emacs is product, and can be well sold, it is power text editor, with
> too many features and extensibility. Perfect software product. Manage
> anything, compan, clinic, hospital, memberships, calculations,
> spreadsheets, plethora of features.
> 
> It is sellable. License allows it. Just sell.

It's not developed for sale by GNU; that's the point.
That's not the purpose/motivation behind its production.

You can develop your own enhancements for it with an
eye to selling them, i.e., with that as their purpose.
But the motivation behind the development of GNU Emacs
isn't to sell it.  It has great use value and zero
exchange value - like the air we breathe.
---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2024-10-23 23:26]:
> > > > 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.
> 
> GNU's not selling Emacs or Elisp.  They're not being
> produced for exchange/sale by GNU.  It's not commodity
> production.
> 
> (But you can still buy a printed manual from GNU, I assume.)
> 
> > Emacs is product, and can be well sold, it is power text editor, with
> > too many features and extensibility. Perfect software product. Manage
> > anything, compan, clinic, hospital, memberships, calculations,
> > spreadsheets, plethora of features.
> > 
> > It is sellable. License allows it. Just sell.
> 
> It's not developed for sale by GNU; that's the point.
> That's not the purpose/motivation behind its production.

https://www.gnu.org/bulletins/bull23.html#SEC28

Watch, GNU system was sold for years on CD-ROMs. I have seen it sold
on the shelves of the bookstore. I just guess Emacs was included.

> You can develop your own enhancements for it with an
> eye to selling them, i.e., with that as their purpose.
> But the motivation behind the development of GNU Emacs
> isn't to sell it.  It has great use value and zero
> exchange value - like the air we breathe.

License does not prohibit selling. Motivation we know. But it is
sellable product, just as many other products.

In your country it may not be common, software is however sold in all
forms in other countries. I have purchased Red Hat Linux in past,
Emacs was on the CD-ROM and advertised.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Emanuel Berg]

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

Jean Louis wrote:

>> 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.
>
> Do you mean making Elisp better in the eyes of the world, or
> technically for Elisp users?

How nice to hear from you, thanks for helping me out that
other time, so okay, this old and boring discussion tho - I'm
just gonna answer this one message - okay - ... - really,
ONE message, I saying.

First, what I mean "better": as a programming language,
as technology.

> There are obviously many Elisp users, worth enough for
> developing it technically, improving it, that is fine and
> good. And developers are doing it. We are here in society of
> Elisp users.

Unfortunately, in terms of features, we have been falling
behind majorly, and not just compared to powerhouses like
Common Lisp and Python.

We have also not optimized Emacs for speed and convenience, we
did not learn from the smartphone generation.

Yes, The developers have done _a lot_ but they have not been
the type of leaders who use their surroundings to make them
better, and become even better themselves. They want to do
everything themselves and if you are just a few bunch of guys
doing that, that's gonna be a problem.

> For the eyes of the world, does it matter? I do not see how
> it does matter. Last time I checked, there must be millions
> of Emacs users.

Haha :) When did you check Jean, and how, and what was the
exact result please?

There are more Emacs users now than in the 90s and early 00s
but relative speaking Emacs position is way down compared
to then. This was bound to happen, maybe it is healthy even,
it doesn't bug me, but I want to have all the features
everyone else has, or close to it, unfortunately we don't.

> Not all of them are loud and talking.

Rumors has it there is 230 members on this list and they don't
all like Emanuel's messages. But I think everyone likes Jean's
messages so it evens up :)

> I just guess that majority does not even know about Elisp.
> But there is large number of Emacs users, as there is large
> number of GNU/Linux users, and growing.

Elisp is a fringe, fringe sport for the computer elite.
Even Lisp as a whole are a pretty marginalized bunch.

> Comparisons like Python vs Elisp are useless as it is just
> interesting for discussion and some language wars in
> old style.

Impossible to compare, unfortunately (for us). But I still
like Elisp more.

For example, can you do _this_ in Python? (Well, yes! I'm sure
they can.)

Blog post coming up really soon now as the saying goes ...

  https://dataswamp.org/~incal/bad/meta/screenshot/grad.png


[-- Attachment #2: grad.png --]
[-- Type: image/png, Size: 10746 bytes --]

[-- Attachment #3: Type: text/plain, Size: 61 bytes --]


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

[-- Attachment #4: Type: text/plain, Size: 92 bytes --]

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Drew Adams via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

> License does not prohibit selling. Motivation we know.
> But it is sellable product, just as many other products.

Yes.  It's about the motivation - how and why a
product gets produced.  That you can sell something
doesn't mean it's developed _for_ sale/profit.

And it's not about whether it's _legal_ to sell
something.  You can sell anything, legal or not,
if you find a buyer for it.  (The buyer might not
legally own it as a result, but that's beside the
point.)

Selling something doesn't make it a commodity and
its creation commodity production: production for
exchange.

If the development of GNU Emacs were dependent on
its sale, then you might have an argument.  It's
not, and you don't.

Your own livelihood might (or might not) depend
on your sales of Emacs.  But that alone doesn't
affect the development of Emacs - its how and why,
its raison d'etre.
---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2024-10-24 00:13]:
> Jean Louis wrote:
> 
> >> 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.
> >
> > Do you mean making Elisp better in the eyes of the world, or
> > technically for Elisp users?
> 
> How nice to hear from you, thanks for helping me out that
> other time, so okay, this old and boring discussion tho - I'm
> just gonna answer this one message - okay - ... - really,
> ONE message, I saying.
> 
> First, what I mean "better": as a programming language,
> as technology.

I am here only to poke on you ;-)

But I can't replace Emacs Lisp with something else. I have got
interface and it is sufficient, I need not think of plethora of
elements. We manage employees, documents, accounting, reports of all
kinds, I mean it is huge. I have switched from Perl to Emacs.

** Statistics 

╔════════════════════════╦════════╦══════════════════════════════╦═══════╗
║ Total number of people ║ 242546 ║ Total Hyperdocuments         ║ 62993 ║
╠════════════════════════╬════════╬══════════════════════════════╬═══════╣
║ People in last week    ║ 108    ║ Hyperdocuments in last week  ║ 216   ║
╠════════════════════════╬════════╬══════════════════════════════╬═══════╣
║ People in last month   ║ 261    ║ Hyperdocuments in last month ║ 841   ║
╚════════════════════════╩════════╩══════════════════════════════╩═══════╝

All that above is managed through Emacs interface.

So if Python is better, it is for me personal issue, not technical
issue. I have got no oversight and capacity to measure what is better.


-- 
Jean


---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2024-10-24 00:21]:
> If the development of GNU Emacs were dependent on
> its sale, then you might have an argument.  It's
> not, and you don't.

Development of GNU was dependent of money, and that money arrived from
various sources, obviously also from sale.

So it's product. I know it better, you don't. 8-)

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: Emacs website, Lisp, and other

[Dr. Arne Babenhauserheide via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

[-- Attachment #1.1: Type: text/plain, Size: 2876 bytes --]

Jean Louis <bugs@gnu.support> writes:

> Emacs Lisp (Elisp) is not just any programming language; it's the
> beating heart of the ultimate text editor, Emacs. Chosen by the
> brilliant Richard Stallman for its unparalleled flexibility, Elisp
> empowers users to customize their editing experience in ways that are
> simply impossible with other editors. Stallman’s expertise, honed
> through groundbreaking projects like the Incompatible Timesharing
> System (ITS) and the Lisp Machine Operating System at MIT, solidified
> Elisp as the backbone of Emacs, transforming it into an editor that
> transcends mere text editing. With Elisp, users tap into a world of
> infinite possibilities, tailoring Emacs to fit their every need,
> making it the best choice for anyone serious about productivity and
> creativity. Why settle for less when you can harness the power of
> Elisp in the finest editor ever created? Emacs truly sets the
> standard!
>
> Emacs is not just an editor; it is a revolution in the world of text
> manipulation, a sophisticated powerhouse that redefines the very
> concept of what an editor can be! Its design, meticulously crafted
> with unparalleled attention to compatibility with Unix, catapults it
> to a level of portability that no other editor can even dare to
> approach.
>
> With the incredible capabilities of Elisp, the very lifeblood of
> Emacs, users have at their fingertips a relentless, supercharged tool
> for writing editing commands that eclipses the functionality of all
> other editors combined! The possibilities are limitless—commanding
> every aspect of your workflow with elegance and precision that’s
> simply unattainable in any other editing environment.

This lacks a note about being improved¹ over decades by diverse groups of
expert hackers who care for their tools ☺

¹ better word lacking. "Honed" is already used in another place ☺

> While other programming languages might boast their unique strengths,
> they pale in comparison to the sheer versatility of Emacs and
> Elisp. Why settle for mediocrity when you can wield the best? Emacs is
> not merely suited for specific tasks; it is a universal toolkit that
> transforms the mundane into the extraordinary, empowering every user
> to achieve feats of productivity that would leave mere mortals in awe.
>
> Emacs is, without a doubt, the ultimate editor, the crown jewel of
> software development, a perennial favorite for those who value true
> mastery over their editing experiences. Embrace the greatness of
> Emacs, and you will never look back!

This calls for becoming a blog post!
And being recorded as a youtube video.

(maybe with the subtitle: you may find hyperbole here. The fun is real!)

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

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

[-- Attachment #2: Type: text/plain, Size: 92 bytes --]

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: 10 problems with Elisp, part 10

[Dr. Arne Babenhauserheide via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

[-- Attachment #1.1: Type: text/plain, Size: 1091 bytes --]

Emanuel Berg <incal@dataswamp.org> writes:

> Yes, The developers have done _a lot_ but they have not been
> the type of leaders who use their surroundings to make them
> better, and become even better themselves. They want to do
> everything themselves and if you are just a few bunch of guys
> doing that, that's gonna be a problem.

Whom do you see as developers here?

Given that melpa and elpa and elpa-nongnu exist where outside devs do a
lot of work, you can’t just mean the core programmers, because they
obviously don’t do everything by themselves.

So you would have to mean the package authors.

But that includes people who learned from vim (and got many vim-users to
switch to Spacemacs or Doom). Who learned from language servers. Who
created full-blown IDEs as well as lean, continuously built Make
integration and flycheck linting.

So you can’t really mean these, either.

As a result I’m at a loss as to whom your comment actually matches.

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

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

[-- Attachment #2: Type: text/plain, Size: 92 bytes --]

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

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

[Emanuel Berg]

Jean Louis wrote:

> But I can't replace Emacs Lisp with something else. I have
> got interface and it is sufficient, I need not think of
> plethora of elements. We manage employees, documents,
> accounting, reports of all kinds, I mean it is huge. I have
> switched from Perl to Emacs.

Oh, you are not replacing it alright. No one said it was bad
or distasteful. It is very good and many, including I, like it
and use it every day. So relax Jean, you are completely
normal ;) You have been good to Elisp and Elisp has been good
to you.

No, I think the frustration, IIRC, ws because

(1) No one else was enthusiastic about making Elisp better, in
    part for its own sake, to make och try to make Emacs
    a Lisp powerhouse up there with CL and Clojure (and
    others); and

(2) even more so, I was frustrated with that boasting,
    functional programming is superior (absolutely not true),
    Lisp is built-in superior to other languages, Lisps syntax
    is an advantage, Lisp programs are short and elegant (yes,
    sometimes, before they get too long, e.g. gnus-sum.el [13
    239 lines], Lisp programmers have a better mental
    understanding of their programs compared to other
    programmers and their sorry languages.

Truthfully and honestly, 2024, one would put it like this:

- if you care about/for Lisp, do it - that is, however, the
  only reason to do it, if you don't care for it, there are
  many alternatives, don't do Lisp, or do just a little
  for culture.

- if you care about/for Lisp, but not Emacs, don't do Elisp,
  there are again many Lispy alternatives that are,
  marginalized as they may be, better that Elisp.

But if you care for Emacs, if you care for Lisp, and maybe the
bigger picture with the community, eco-system around it, yes,
why not? That attitude/boasting bugs me but that doesn't mean
Elisp is bad.

> ** Statistics 
>
> ╔════════════════════════╦════════╦══════════════════════════════╦═══════╗
> ║ Total number of people ║ 242546 ║ Total Hyperdocuments         ║ 62993 ║
> ╠════════════════════════╬════════╬══════════════════════════════╬═══════╣
> ║ People in last week    ║ 108    ║ Hyperdocuments in last week  ║ 216   ║
> ╠════════════════════════╬════════╬══════════════════════════════╬═══════╣
> ║ People in last month   ║ 261    ║ Hyperdocuments in last month ║ 841   ║
> ╚════════════════════════╩════════╩══════════════════════════════╩═══════╝
>
> All that above is managed through Emacs interface.

That's exactly right, that's how you do it, Jean! Digits and
order bring fortune to _everyone_.

Here is a screenshot of it:
  https://dataswamp.org/~incal/emacs-data/jeans-hypertable.png
  
I also try to make an honest buck now and then.
Did you hear of the next installment of Police Quest,
Sierra-On Line's old franchise, that is coming for Emacs?

  https://dataswamp.org/~incal/sneak/police.png

> So if Python is better, it is for me personal issue, not
> technical issue. I have got no oversight and capacity to
> measure what is better.

It is better in the sense, give 100 programmers 100 programs
to write, then do the same to 100 other programmers but the
same task, one group uses Python and one uses Elisp, what will
happen with 100% certainty is that the Python guys will

- complete their task (all 100? possible)
- complete many, many more programs
- their programs will be much better
- they will do it faster, i.e., less man hours
- and with much less frustration during the process

PS. EOD, can't do this anymore, okay? :) DS.

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


---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: 10 problems with Elisp, part 10

[Joel Reicher]

Emanuel Berg <incal@dataswamp.org> writes:

> No, I think the frustration, IIRC, ws because
>
> (1) No one else was enthusiastic about making Elisp better, in 
>     part for its own sake, to make och try to make Emacs a Lisp 
>     powerhouse up there with CL and Clojure (and others); and

To my mind that's a bit like saying make a mouse trap better by 
making it more like a bear trap.

By all means make elisp better, but don't compare it to languages 
that are used for different things.

> (2) even more so, I was frustrated with that boasting, 
>     functional programming is superior (absolutely not true), 
>     Lisp is built-in superior to other languages, Lisps syntax 
>     is an advantage, Lisp programs are short and elegant (yes, 
>     sometimes, before they get too long, e.g. gnus-sum.el [13 
>     239 lines], Lisp programmers have a better mental 
>     understanding of their programs compared to other 
>     programmers and their sorry languages.

Different languages are good for different things. Saying one 
language is better than another only makes sense if they are being 
used for the same thing, and only in the context of that thing.

I like Lisp, but I wouldn't use it for everything.

Regards,

        - Joel

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)