the #'function type-in-code issue, (E)lisp, and C

[Emanuel Berg <embe8573@student.uu.se>]

Remember the discussion that a #'function should be
put like that, sharp quoted?

I have now changed all of my code. The conclusions
are:

1) This made me `require' a lot of stuff that was
previously not required. This meant some pleasant
work, but did it also make the code more robust? - an
open question...

2) Sometimes it was difficult to know how to put it.
Here, the help came in handy. Here are two examples:

       (put SYMBOL PROPNAME VALUE)

       Store SYMBOL's PROPNAME property with
value VALUE.

   so

       (put 'upcase-region 'disabled nil)

   but

       (add-hook HOOK FUNCTION &optional APPEND LOCAL)

       Add to the value of HOOK the function FUNCTION.

   and consequently

       (add-hook 'text-mode-hook #'text-mode-hook-f)

Now, the help came in "handy", but if you compare it
to the languages that do use types in the code all the
time, and are not ashamed to do so, we see that in
those languages there is never such detective work
required, at all!

For example, the language C. Do:

    M-x printf(3) RET

and see that the first thing they tell you is

    SYNOPSIS #include <stdio.h>

       int printf(const char *format, ...); int
fprintf(FILE *stream, const char *format, ...); int
sprintf(char *str, const char *format, ...); int
snprintf(char *str, size_t size, const char *format,
...);

i.e., the types!

So here what I can see (E)lisp is at a clear
disadvantage as it is not only unclear what to do,
even when you decide what to do, if you decide to do
the function/symbol distinction, it is not clear how
to do it!

-- 
underground experts united
http://user.it.uu.se/~embe8573