Re: 10 problems with Elisp, part 10

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

Re: 10 problems with Elisp, part 10

[Dr. Arne Babenhauserheide]

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

Christopher Dimech <dimech@gmx.com> writes:

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

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

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

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

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

Replace "Python" with whatever programming language they use.

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

Did you read code of large weather models?

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

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

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

Don’t go badmouthing other people.

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

Please don’t repeat that mistake with Python.

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

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

10 problems with Elisp, part 10

[Christopher Dimech]

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

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

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

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

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

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

Re: 10 problems with Elisp, part 10

[Emanuel Berg]

Dr Arne Babenhauserheide wrote:

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

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

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

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

Emacs files and lines by the command:

  $ wc -l **/*.el

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

         [...]

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

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

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

[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 --]

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: 10 problems with Elisp, part 10

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

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

Wins only in being popular.  It can win against most languages in that regard and I doubt if it's only for technical reasons.

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

Sure.  But should we consider Python as a technically better language?

Of course it has lessons to be learnt and advantages to be studied and adopted.  But should one try to make Elisp more like JS or PHP or Python just because they have more programmers?  Isn't it because of some other industrial causes that they are popular?

And are you sure that what you mentioned in number 10 is Emacs' weakness and not its advntage?

--
Best Regards,

Re: 10 problems with Elisp, part 10

[Emanuel Berg]

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

>> Yes, Python is incomparable to Emacs Lisp and would
>> probably win quite even against the collective Lisp world,
>> I'm afraid.
>
> Wins only in being popular.

I didn't say that. You know why? Because I didn't mean it.

> But should we consider Python as a technically
> better language?

It doesn't take much experience to do cool things fast
in Python, it is a fact.

In Lisp, _no one_ does that, almost.

> Of course it has lessons to be learnt and advantages to be
> studied and adopted.  But should one try to make Elisp more
> like JS or PHP or Python just because they have more
> programmers?  Isn't it because of some other industrial
> causes that they are popular?

No comments, I haven't said any of what you say so I don't
need to answer it, either.

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

10 problems with Elisp, part 10

[Christopher Dimech]

> Sent: Wednesday, August 07, 2024 at 7:44 PM
> From: "Emanuel Berg" <incal@dataswamp.org>
> To: emacs-devel@gnu.org
> Subject: Re: 10 problems with Elisp, part 10
>
> Abraham S.A.H." via "Emacs development discussions. wrote:
> 
> >> Yes, Python is incomparable to Emacs Lisp and would
> >> probably win quite even against the collective Lisp world,
> >> I'm afraid.
> >
> > Wins only in being popular.
> 
> I didn't say that. You know why? Because I didn't mean it.
> 
> > But should we consider Python as a technically
> > better language?
> 
> It doesn't take much experience to do cool things fast
> in Python, it is a fact.

I have been involved it large python projects that today I do 
not touch even if they have some value to me.

But I work on lisp everyday.  With frustration or without, the lisp
code gets read and written.   

> In Lisp, _no one_ does that, almost.
> 
> > Of course it has lessons to be learnt and advantages to be
> > studied and adopted.  But should one try to make Elisp more
> > like JS or PHP or Python just because they have more
> > programmers?  Isn't it because of some other industrial
> > causes that they are popular?
> 
> No comments, I haven't said any of what you say so I don't
> need to answer it, either.
> 
> -- 
> underground experts united
> https://dataswamp.org/~incal
> 
> 
>

10 problems with Elisp, part 10

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

> I didn't say that. You know why? Because I didn't mean it.
> It doesn't take much experience to do cool things fast
> in Python, it is a fact.

I agree to disagree, Emanuel!  Sorry, but I do not think “Python is
a generally better programming language”.  Perhaps Python is very good
in some aspects but not in general, and I know Python better than any
other language.

I think that Python is popular in  the sense of “there are more Python
programmers than most other languages”.   And I think “In the software
industry, technical  merits of a  programming language do not  make it
popular.”!  Java and C and JS  didn't become popular only due to their
technical merits.

> Emacs-w3m is from Japan <3

As I said, perhaps only in Japan.

However, as an Asian, I know  no university in my country or neighbour
countries teaching  Lisp.  Just a  few pages  of history and  no more.
But they teach C, Java and Python.

> No. Just think, remove this line in Lisp
>
> some-item))

Why should  I?  Why should I  use `kill-line`?  Why not  removing that
item with `kill-sexp`?

Do you know Python and Lisp and acknowledge their difference?

In Python,  one removes a  statement by  removing its content  and the
following newline character; because  in Python statements are started
and  terminated with  newlines  (a character)  (unless continued  with
a backslash or separated with a semicolon! Yeah...)

In Lisp, one  removes statements by removing sexps.   Because in Lisp,
statements  are   started  and  terminated  with   another  character,
parenthesis!  (Only parenthesis, no exceptions)

For  removing  a  statement  in   Python,  use  `kill-line`  (C-k)  or
`kill-whole-line`.  For removing a  statement in Lisp, use `kill-sexp`
(C-M-k).

You  are using  your  own  presumptions to  reason  out, and  convince
others.  Your presumptions are not mine,  and your facts are not facts
to me.

Python is not a mainly better language.  It's your own presumption.
I learnt  it because I  have to.  Others learn  it too, for  many only
because they also have to.  Lisp is not widespread in universities any
more.  It's your own presumption.  Perhaps in US, perhaps in the past.

Please, do  not declare  your opinions as  Accepted Facts.   At least,
they are not established facts to many other developers.

I think  that I'm out  of this discussion.   I don’t have  any benefit
here. 

-- 
Best Regards,

Re: 10 problems with Elisp, part 10

[Sebastián Monía]

"Abraham S.A.H." via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

>> I didn't say that. You know why? Because I didn't mean it.
>> It doesn't take much experience to do cool things fast
>> in Python, it is a fact.
>
> I agree to disagree, Emanuel!  Sorry, but I do not think “Python is
> a generally better programming language”.  Perhaps Python is very good
> in some aspects but not in general, and I know Python better than any
> other language.

I saw this brought up before, but: this whole conversation is way off
topic.

And it has been going for a while now: why not take it to the tangents
list, as it was suggested earlier?

-- 
Sebastián Monía
https://site.sebasmonia.com/

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: 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: 10 problems with Elisp, part 10

[Eli Zaretskii]

> Date: Wed, 7 Aug 2024 20:57:29 +0200 (CEST)
> From:  "Abraham S.A.H." via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> > I didn't say that. You know why? Because I didn't mean it.
> > It doesn't take much experience to do cool things fast
> > in Python, it is a fact.
> 
> I agree to disagree, Emanuel!  Sorry, but I do not think “Python is
> a generally better programming language”.  Perhaps Python is very good
> in some aspects but not in general, and I know Python better than any
> other language.

Once again, I request that the sub-thread about Python vs ELisp be
taken off this list, to emacs-tangents, for example.  It is off-topic
here, and this discussion has already generated so much noise that I'm
seriously considering to forcibly shut it down by unpleasant
administrative means.

10 problems with Elisp, part 10

[Christopher Dimech]

> Sent: Thursday, August 08, 2024 at 4:58 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Abraham S.A.H." <arash.sah@tuta.io>
> Cc: emacs-devel@gnu.org
> Subject: Re: 10 problems with Elisp, part 10
>
> > Date: Wed, 7 Aug 2024 20:57:29 +0200 (CEST)
> > From:  "Abraham S.A.H." via "Emacs development discussions." <emacs-devel@gnu.org>
> > 
> > > I didn't say that. You know why? Because I didn't mean it.
> > > It doesn't take much experience to do cool things fast
> > > in Python, it is a fact.
> > 
> > I agree to disagree, Emanuel!  Sorry, but I do not think “Python is
> > a generally better programming language”.  Perhaps Python is very good
> > in some aspects but not in general, and I know Python better than any
> > other language.
> 
> Once again, I request that the sub-thread about Python vs ELisp be
> taken off this list, to emacs-tangents, for example.  It is off-topic
> here, and this discussion has already generated so much noise that I'm
> seriously considering to forcibly shut it down by unpleasant
> administrative means.
 
I have added to emacs-tangent the possibility of arguing about the two 
languages there.  But the unwillingness to use a language to get some 
job done is counter-productive.  Simplicity and potency have never been
requirements.  If there are multiple ways of doing something, I welcome that.

Please follow Eli's instructions.  If it is forcibly shut down, you bring it 
upon yourselves.

Re: 10 problems with Elisp, part 10

[Emanuel Berg]

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

>> It doesn't take much experience to do cool things fast in
>> Python, it is a fact.
>
> I agree to disagree, Emanuel!  Sorry, but I do not think
> "Python is a generally better programming language".

Devel time faster than in Lisp, is what I'm saying.

Maybe one could have a Lisp that also was as fast or almost as
fast, if one focused on that aspect.

> However, as an Asian, I know no university in my country or
> neighbour countries teaching Lisp.

Even so.

>> No. Just think, remove this line in Lisp
>>
>> some-item))
>
> Why should  I?  Why should I  use `kill-line`?  Why not 
> removing that item with `kill-sexp`?

Indeed, be an excellent Emacs user, that is all it takes.

No, the syntax makes it harder and slower to edit for
everyone. More syntax errors, more typing.

One thing one could try is to replace boring, trivial stuff
with non-Lisp syntax.

For example setting up the interface. Here is one example from
my own code. (Note: Over one in five interfaces in the Emacs
source uses Lisp and not the `interactive' format string.)

  ;; ...
  (interactive (if (numberp current-prefix-arg)
                   (list current-prefix-arg)
                 current-prefix-arg))
  (unless end
    (setq end 73))
  (unless step
    (setq step (min 10 (max 2 (/ end 10)))))
  (unless i
    (setq i 0))
  (unless (and (numberp i)    (<= 0 i)
               (numberp end)  (<  0 end)
               (numberp step) (<  0 step))
    (error "Bogus indata"))

This is 402 chars!

But here is a 135-char solution that expresses the same:

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

And here is a 88 char solution:

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

Also with: :prompt-string (:ps), :doc-string (:ds) ...

That way, we could keep Lisps elegance and power for where
people cared about it, for example solving interesting
algorithmic problems and so on.

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

Re: 10 problems with Elisp, part 10

[Dr. Arne Babenhauserheide]

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

Emanuel Berg <incal@dataswamp.org> writes:

>   (unless end
>     (setq end 73))
>   (unless step
>     (setq step (min 10 (max 2 (/ end 10)))))
>   (unless i
>     (setq i 0))

This could already be trimmed a lot:

(setq
  end (or end 37)
  step (or step (min 10 (max 2 (/ end 10))))
  i (or i 0))

⇒ start optimizing where no syntax breakage is needed.

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

[Emanuel Berg]

Dr. Arne Babenhauserheide wrote:

>>   (unless end
>>     (setq end 73))
>>   (unless step
>>     (setq step (min 10 (max 2 (/ end 10)))))
>>   (unless i
>>     (setq i 0))
>
> This could already be trimmed a lot:
>
> (setq
>   end (or end 37)
>   step (or step (min 10 (max 2 (/ end 10))))
>   i (or i 0))
>
> → start optimizing where no syntax breakage is needed.

That's the thing, one shouldn't have to optimize anything, and
in particular not such common and everyday things, the language
should optimize that for you.

Besides what you did is almost nothing. For that part, it is
from 108 to 82 chars, a mere 26 chars.

Please write all this in Lisp anywhere near this 88 chars, and
then I'm even generous with the whitespace.

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

:r means signal error if outside of the interval.

:rc means set to min or max if outside of the interval.

Defaults should be the same for interactive and
non-interactive use.

:pa means both M-x, C-u M-x, and C-u x M-x should work.

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

Re: 10 problems with Elisp, part 10

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Fri, 09 Aug 2024 10:36:58 +0200
> 
> Dr. Arne Babenhauserheide wrote:
> 
> >>   (unless end
> >>     (setq end 73))
> >>   (unless step
> >>     (setq step (min 10 (max 2 (/ end 10)))))
> >>   (unless i
> >>     (setq i 0))
> >
> > This could already be trimmed a lot:
> >
> > (setq
> >   end (or end 37)
> >   step (or step (min 10 (max 2 (/ end 10))))
> >   i (or i 0))
> >
> > → start optimizing where no syntax breakage is needed.
> 
> That's the thing, one shouldn't have to optimize anything, and
> in particular not such common and everyday things, the language
> should optimize that for you.

The above is not optimization, it is the usual Emacs Lisp style of
doing this kind of jobs.

> Please write all this in Lisp anywhere near this 88 chars, and
> then I'm even generous with the whitespace.
> 
> [
>   end  :r  0<   :d 73         :pa
>   step :rc 2-10 :d (/ end 10)    
>   i    :r  0<=  :d 0             
> ]
> 
> :r means signal error if outside of the interval.
> 
> :rc means set to min or max if outside of the interval.
> 
> Defaults should be the same for interactive and
> non-interactive use.
> 
> :pa means both M-x, C-u M-x, and C-u x M-x should work.

The very fact that you need to explain what this mean speaks volumes.

Anyway, we are not going to redesign Emacs Lisp, so this line of
discussion leads nowhere.  Please stop keeping it alive, it just adds
unnecessary noise to this already very noisy list.

Re: 10 problems with Elisp, part 10

[Eduardo Ochs]

On Fri, 9 Aug 2024 at 07:21, Emanuel Berg <incal@dataswamp.org> wrote:
>
> [
>   end  :r  0<   :d 73         :pa
>   step :rc 2-10 :d (/ end 10)
>   i    :r  0<=  :d 0
> ]
>
> :r means signal error if outside of the interval.
>
> :rc means set to min or max if outside of the interval.
>
> Defaults should be the same for interactive and
> non-interactive use.
>
> :pa means both M-x, C-u M-x, and C-u x M-x should work.

Hi Emanuel,
what is that syntax?
If that is a DSL written in Lisp can you show a complete example of
how to load it and use it?
Thanks in advance...
  Eduardo Ochs
  http://anggtwu.net/#eev

Re: 10 problems with Elisp, part 10

[Emanuel Berg]

Eduardo Ochs wrote:

>> [
>>   end  :r  0<   :d 73         :pa
>>   step :rc 2-10 :d (/ end 10)
>>   i    :r  0<=  :d 0
>> ]
>
> what is that syntax?

It is called the DRAW syntax.

DRAW stands for "Dorks Run Away - Weehoo!"

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

Re: 10 problems with Elisp, part 10

[Emanuel Berg]

Eli Zaretskii wrote:

>> [
>>   end  :r  0<   :d 73         :pa
>>   step :rc 2-10 :d (/ end 10)    
>>   i    :r  0<=  :d 0             
>> ]
>> 
>> :r means signal error if outside of the interval.
>> 
>> :rc means set to min or max if outside of the interval.
>> 
>> Defaults should be the same for interactive and
>> non-interactive use.
>> 
>> :pa means both M-x, C-u M-x, and C-u x M-x should work.
>
> The very fact that you need to explain what this mean
> speaks volumes.

(info "(Emacs)")
(info "(Elisp)")

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

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

[Bob Rogers]

   From: Emanuel Berg <incal@dataswamp.org>
   Date: Fri, 09 Aug 2024 10:36:58 +0200

   . . .

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

   :r means signal error if outside of the interval.

   :rc means set to min or max if outside of the interval.

This is damn near unreadable.  Instead of advocating for cryptic code
and talking about how few characters it is, maybe you should look for
completion methods or typing aids and then talk about how few keystrokes
normal Lisp takes to enter?

					-- Bob Rogers
					   http://www.rgrjr.com/

Re: 10 problems with Elisp, part 10

[Emanuel Berg]

Bob Rogers wrote:

>    [
>      end  :r  0<   :d 73         :pa
>      step :rc 2-10 :d (/ end 10)    
>      i    :r  0<=  :d 0             
>    ]
>
>    :r means signal error if outside of the interval.
>
>    :rc means set to min or max if outside of the interval.
>
> This is damn near unreadable.

To me, thanks to the spaces with keywords and values, it is
much easier to edit and read.

A bunch of interactive format strings from the Emacs source:

  (interactive "^p\nd\nd")

  (interactive "r\nP\np")

  (interactive "i\np\ni\np")

  (interactive "P\ncMark:" ...)

You think they are easier to read?

Okay, people are different.

I did offer a spelled out version, of this format:

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

They don't express the same things at all, almost, but one can
compare then from the readability aspect, sure. Take it for
what it is.

> Instead of advocating for cryptic code and talking about how
> few characters it is, maybe you should look for completion
> methods or typing aids and then talk about how few
> keystrokes normal Lisp takes to enter?

Nah, I don't like it, takes the fun out of typing.

And it isn't just typing, it is also looking at and browsing
the code.

Fewer chars is always better, as long as you can understand
it. The above, I can understand very easily and I would be
100% fluent with it if I used it often, and that goes for
a lot of people, I think.

Besides, even apart from the syntax, the proposed interface
isn't anything like `interactive', really, as you can guess
from the keywords above.

-- 
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 01:21:55 +0200
> 
> Bob Rogers wrote:
> 
> >    [
> >      end  :r  0<   :d 73         :pa
> >      step :rc 2-10 :d (/ end 10)    
> >      i    :r  0<=  :d 0             
> >    ]
> >
> >    :r means signal error if outside of the interval.
> >
> >    :rc means set to min or max if outside of the interval.
> >
> > This is damn near unreadable.
> 
> To me, thanks to the spaces with keywords and values, it is
> much easier to edit and read.
> 
> A bunch of interactive format strings from the Emacs source:
> 
>   (interactive "^p\nd\nd")
> 
>   (interactive "r\nP\np")
> 
>   (interactive "i\np\ni\np")
> 
>   (interactive "P\ncMark:" ...)
> 
> You think they are easier to read?

Yes, for anyone who is used to ELisp.

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

  > Please write all this in Lisp anywhere near this 88 chars, and
  > then I'm even generous with the whitespace.

  > [
  >   end  :r  0<   :d 73         :pa
  >   step :rc 2-10 :d (/ end 10)    
  >   i    :r  0<=  :d 0             
  > ]

This topic is not pertinent to Emacs development.
Please move this to emacs-tabgents, or somewhere else.

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

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