Naming, and Gnus functions length [Was: Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code]]

[Garreau, Alexandre]

On 2018-10-08 at 16:14, Emanuel Berg wrote:
> If you have studied the Gnus source code, you find that the defuns are
> insanely long. They go on all but forever. This is because Gnus is
> already slow, and perhaps Elisp is as well, so they don't want to
> brake it up into modules (smaller defuns) because then it would
> require the funcall overhead. Perhaps Gnus would benefit from inlining
> stuff?

Maybe Gnus functions length are just a question of style.  I guess their
developers are experienced enough to know how to properly use manual
inlining.  And anyway, as, as you pointed it, Gnus can already be
sometimes quite slow, it’s probably more because of I/O than function
call overhead, so this later must be neglictible in comparison.  So Gnus
functions length is probably unrelated.

I put Gnus dev in copy (hoping it’s relevant to the conversation and not
inapropriated to the situation) in case that can help getting more
relevant answers for this.

I personally myself tend to write really big functions, because I like
to have well-named things, and dislike to repeat myself and/or have a
lot of intermediary values and functions with bad names and poor
semantics, so until I come with a proper and nice semantic abstraction I
keep stuff in the same function.

This is unlike some languages like scheme, ocaml, etc. which potentially
requires recursion for loops in some cases, therefore obligating you to
give a name to each loop of your programs (thus potentially resulting in
needing a lot of names, and even potentially bad or complicated ones).

Also unlike pre-algebraic languages which may force you in using lot and
lot of temporary variables, which will inevitably result in either using
very, I find, poor names (such as “double_x = x * 2”), either totally
non-sensical and confusing names such as “A”, “B”, “C”, etc. (TeX is a
notable example where a lot of the loops use recursions, and stuff like
that, you end up needing many names and ending with names with strange
semantics such as “@”, double-“@”, etc. everywhere, resulting in cryptic
code for the unexperienced).