unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Jean Louis <bugs@gnu.support>
To: help-gnu-emacs@gnu.org
Subject: Re: Lookarounds and recursion in Emacs regexes
Date: Tue, 7 Feb 2023 12:46:12 +0300	[thread overview]
Message-ID: <Y+Id5LzM4FygKBVR@protected.localdomain> (raw)
In-Reply-To: <87mt5tje44.fsf@dataswamp.org>

* Emanuel Berg <incal@dataswamp.org> [2023-02-05 16:15]:
> Jean Louis wrote:
> 
> >>> Although somewhat proficient, I never learnt to love Python.
> >> 
> >> People don't love Python like they do Lisp, but no doubt it
> >> has it's good sides - development speed not the least.
> >
> > Do you want to say that development speed in Lisp is slower
> > than in Python?
> 
> Lisp is a family of languages, if we talk Elisp then Elisp is
> faster for anything Emacs related obviously, if we talk
> everything else then Python is faster.

Faster for development?

Faster for speed processing by programming language?

Subject is development, not speed.

I do not know if it exists for Python, but for Emacs Lisp, all
references exists within Emacs. That helps for speed of development.

I cannot know for Python how can I see definition of the function, is
there any way to see that?

> If we talk Common Lisp vs Python, then Python is, in
> general, faster.

For Common Lisp I can access all functions and their definitions from
within the Common Lisp itself.

Great design!

For Python, I see that many things are not integrated in Emacs, and
getting symbol descriptions, functions, information, it is not easy,
and is error prone. I installed `jedi' package, but I see I get not
conclusive error messages and I cannot get information for Python
functions.

User is disabled by design.

That Python development would be faster, I can't say for Emacs editor.

Regarding language itself, maybe you could tell "why" do you consider
development with Python faster?

> We then consider the languages themselves, the technology around,
> but also the huge spread of Python while Lisp is either a fringe
> language or - actually that's our common ground - the underground.

You have not explained specifics. I cannot get you. I get opinion, but
not specific.

I gave you one specific on developing Emacs Lisp in Emacs, versus
developing Python, which function descriptions are not easily
accessible. 

Developing Emacs Lisp in Vim would become harder for that reason.

Editor is one important aspect of it.

"Huge spread" of Python is indication of something, I do not know what
you mean with it. Maybe you mean that number of people knowing Python
would be helpful in development? I can understand it from there.

If language is "fringe", I cannot see how that influences development,
apart from maybe not having other people to exchange with them.

For example, I could easily program in this programming language, much
"fringe", and I could find all references, books, just anything:

Icon (programming language) - Wikipedia:
https://en.wikipedia.org/wiki/Icon_(programming_language)

What are Icon's distinguishing characteristics:
https://www2.cs.arizona.edu/icon/uguide/faq.htm#features

I just guess I would have no problems with that one and speedy
development, it is for reason of being well documented.

-- 
Jean

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

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



  reply	other threads:[~2023-02-07  9:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27 14:11 Lookarounds and recursion in Emacs regexes Evan Aad
2023-01-27 18:12 ` Marcin Borkowski
2023-01-27 19:30   ` Emanuel Berg
2023-01-28  6:46     ` tomas
2023-02-03 19:22       ` Emanuel Berg
2023-02-04 15:46         ` Jean Louis
2023-02-04 21:48           ` Emanuel Berg
2023-02-07  9:46             ` Jean Louis [this message]
2023-02-07 10:25               ` Emanuel Berg
2023-02-07 22:45                 ` Jean Louis
2023-02-26 11:40       ` the GLIMPs [GIMP Lisps] (was: Re: Lookarounds and recursion in Emacs regexes) Emanuel Berg
2023-02-27  8:31         ` tomas
2023-02-04 22:28     ` Lookarounds and recursion in Emacs regexes Stefan Monnier via Users list for the GNU Emacs text editor
2023-02-04 22:44       ` Emanuel Berg
2023-02-05  5:51       ` Eli Zaretskii
2023-02-06 12:53         ` Emanuel Berg
2023-02-06 13:09           ` Emanuel Berg
2023-02-06 13:23           ` Eli Zaretskii
2023-02-06 13:44             ` Emanuel Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+Id5LzM4FygKBVR@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).