From: Jean Louis <bugs@gnu.support>
To: help-gnu-emacs@gnu.org
Subject: Re: stats say SBCL is 78 875 % faster than natively compiled Elisp
Date: Sun, 19 Feb 2023 08:58:05 +0300 [thread overview]
Message-ID: <Y/G6bZt7Hxmg7efJ@protected.localdomain> (raw)
In-Reply-To: <87o7pq21i4.fsf@dataswamp.org>
* Emanuel Berg <incal@dataswamp.org> [2023-02-18 23:23]:
> > Speed does not matter for purposes I need, like sales,
> > handling people, communicating with people.
>
> Speed always matters in computing.
You have generalized my personal specific answer.
To find out if speed matters you would need to ask people to
understand their personal needs. General statements may not be always
practically useful. What really matters is the use for people.
I have been programming in Perl, it gave me useful life period. Then
there was HTML rendering in Perl. Personally I had to consider whole
system that was of use for me as human, the Perl programming language,
an browser that was displaying the rendered HTML as program
application GUI. I have tried using it from CLI by using Common
Lisp. I cannot say that Common Lisp os so "Common". Every
implementation is different. For simple programming functions I have
to change to this or that implementation. And integration of packages
is not smooth as one expects it. Let me say it is worse, not as
reliable, than Perl package (CPAN). Is speed the only factor? I don't
think so. Then I tried it out with Emacs Lisp, and because there are
many features already built-in it spares me time of programming.
Emacs offers GUI already, hyperlinks (buttons). Imagine only those two
features for example. Then simple function can list those files
hyperlinked and let me as user click to see the generated PDF with the
invoice. Does it matter that some milliseconds pass? No.
Another example is searching for particular contact in the database,
sometimes it would take longer time, like 1-2 seconds. But I know how
to speed it up. Would it be faster with Common Lisp? Probably, but
personally does not matter, as the features in Emacs are taken for
granted and spare my time to program. In the same way the PostgreSQL
database spare my time to program.
And finally, there is no HTML rendering, no browser, and it all comes
faster than with the HTML GUI.
Could I do it with Common Lisp faster? Probably yes, but in the end I
would spend more time programming it, as Common Lisp does not have
integrated features like Emacs.
If you do know how to quickly create Common Lisp GUI with spreadsheet,
that I can change keybindings on every different listing, with
multiple instances running in the same time (multiple buffers) then
let me know. I would like to use it, but I did not find solution.
In Emacs one can detect what other buffers are displayed, move object
from one buffer's place to other buffer's place.
tabulated-list-mode gives me that solution built-in, I can list
database objects and do something on them. It is most similar to
spreadshet widget. As much as I look into GUIs for Common Lisp, I
cannot easily find solution. I would need to program too much. At
least that is my impression.
Which solution for the above description can be replaced by Common Lisp?
https://common-lisp.net/libraries
I would like to know, as I want to try it out.
--
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-19 5:58 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-14 7:56 stats say SBCL is 78 875 % faster than natively compiled Elisp Emanuel Berg
2023-02-15 5:04 ` Chen Zhaoyang
2023-02-15 11:37 ` Emanuel Berg
2023-02-15 6:59 ` Jean Louis
2023-02-16 6:04 ` Emanuel Berg
2023-02-17 17:38 ` Jean Louis
2023-02-18 19:54 ` Emanuel Berg
2023-02-18 20:15 ` Emanuel Berg
2023-02-18 20:39 ` Eli Zaretskii
2023-02-18 20:47 ` Emanuel Berg
2023-02-19 6:35 ` Eli Zaretskii
2023-02-21 7:04 ` Native compilation by default?: Was [Re: " Madhu
2023-02-21 12:37 ` Eli Zaretskii
2023-02-21 16:35 ` Emanuel Berg
2023-02-21 19:57 ` Emanuel Berg
2023-02-21 22:21 ` Native compilation by default? (was: Re: stats say SBCL is 78 875 % faster than natively compiled Elisp) Emanuel Berg
2023-02-21 23:54 ` Emanuel Berg
[not found] ` <87h6vetquk.fsf@dataswamp.org>
2023-02-22 1:47 ` Emanuel Berg
2023-02-23 10:46 ` Emanuel Berg
2023-02-23 20:18 ` Jean Louis
2023-02-26 1:05 ` Emanuel Berg
2023-02-22 12:32 ` Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp Eli Zaretskii
2023-02-26 3:08 ` Madhu
2023-02-26 4:32 ` Stefan Monnier via Users list for the GNU Emacs text editor
2023-02-26 5:15 ` Emanuel Berg
2023-02-26 6:27 ` Eli Zaretskii
2023-02-26 7:10 ` Emanuel Berg
2023-02-26 16:14 ` FW: [External] : " Drew Adams
2023-02-26 16:31 ` Eli Zaretskii
2023-02-26 17:12 ` Drew Adams
2023-02-26 17:31 ` Eli Zaretskii
2023-02-26 18:29 ` Drew Adams
2023-02-26 19:04 ` Eli Zaretskii
2023-02-26 20:05 ` Emanuel Berg
2023-02-27 8:42 ` Madhu
2023-03-03 14:55 ` Stefan Monnier via Users list for the GNU Emacs text editor
2023-02-26 6:25 ` Eli Zaretskii
2023-02-26 16:10 ` [External] : " Drew Adams
2023-02-19 5:58 ` Jean Louis [this message]
2023-02-15 12:36 ` full native compile (was: Re: stats say SBCL is 78 875 % faster than natively compiled Elisp) Emanuel Berg
2023-02-15 14:05 ` Eli Zaretskii
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/G6bZt7Hxmg7efJ@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).