Re: C and Emacs Lisp code parts

[Davis Herring]

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

Davis

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