Re: 10 problems with Elisp, part 10

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

[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

[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

[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

[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

[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

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

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

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

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

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

[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

[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

[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

[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

[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

[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

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

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

[Christopher Dimech]

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

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

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

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

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

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

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

Re: 10 problems with Elisp, part 10

[Dr. Arne Babenhauserheide]

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

Christopher Dimech <dimech@gmx.com> writes:

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

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

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

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

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

Replace "Python" with whatever programming language they use.

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

Did you read code of large weather models?

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

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

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

Don’t go badmouthing other people.

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

Please don’t repeat that mistake with Python.

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

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

10 problems with Elisp, part 10

[Christopher Dimech]

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

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

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

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

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

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

Re: 10 problems with Elisp, part 10

[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

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