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/
next prev parent 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
* 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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.