[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C and Emacs Lisp code parts

From: Davis Herring
Subject: Re: C and Emacs Lisp code parts
Date: Tue, 5 Jul 2016 11:02:13 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

Git, like init (and /etc/init.d), Emacs, NumPy, and basically every
other non-trivial software system in existence, consists of a mix of
compiled and interpreted code according to the strengths and
weaknesses of each.  Everyone knows this.

So why you tell that?
Still don't understand why qualifying git "C-based" should be wrong.

Because you drew attention to Git's C basis as (what appeared to be) an argument for moving Emacs in that direction, despite the fact that Emacs is already C-based in much the same fashion as Git (other than that there are many C functions which take Lisp_Object).

My suggestion is about re-considerating, reversing a kind of dogmatic
pro-elisp policy - as I felt it.
While completely agree with Clément's posts here --stressing the
benefits of Lisp debugging etc.--
these strength is less important WRT lifetime of core functions.

The extent of that policy is "put in in Elisp unless there's a good reason not to", which is merely a question of burden of proof. And that direction of burden makes sense: it is widely accepted that C programming takes longer, so why pay for it in the case where no one can point out a reason one way or the other?

The idea is about reflecting the reasons which part to keep in C, which
in Lisp. Don't have a quick answer for that. Roughly would favor to look
what belongs to user-space, what not. Also stuff which is used seldom
probably doesn't deserve C, etc.

No disagreement here -- but the utility of this conversation is quite limited until you have such an answer (quick or otherwise). Merely suggesting that people (who, say, are implementing a new feature and need to decide what language to use) consider carefully which language to use is not usefully distinct from the current "policy".

Amdahl is about processing power raised by number of kernels, no idea
what the example should contribute here.

Amdahl's law is not so limited: see more precisely <https://en.wikipedia.org/wiki/Amdahl%27s_law#Speedup_in_a_serial_program>.

Spelled out explicitly: if, in some context, we spend only (say) 20% of our time running Lisp code (vs., say, redisplay), then we can improve the speed of that context by no more than 25% by rewriting that Lisp in any fashion whatsoever (including C).


This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]