Gaga about bifs

[James Hague]

Robert Virding wrote:
>Why is everyone so completely gaga about adding new bifs
>to do relatively trivial things? Especially seeing you
>can already to do it without adding new stuff. Use
>erl_scan:string and io_lib:fwrite.

That's a good point, but I can see two reasons:

1. integer_to_list and list_to_integer are already bifs.  It's cleaner to
have arity two versions with the same names than it is to have completely
different functions in different modules.

2. The currently Erlang implementation is one of the fastest interpreted
languages I have seen.  It walks all over Python for most things, for
example (by factors of 2 to 20 on micro-bencmarks!), even though Erlang is
functional and Python imperative.  Much of this speed comes from great
attention to the low-level details of the interpreter:  threaded code, beam
"superinstructions," having many core functions coded in C.  Certainly
integer_to_list/2 is not a time critical function in most cases, but then I
guess you could argue the same about integer_to_list/1.  If implementation
purity were the highest priority, then there's no reason for lists:reverse
and lists:length to be bifs, for example.

Execution speed for most tasks is not top priority, and that the Erlang
system *has* been honed with a focus on speed helps keep this true.

>I have sent a
>modified io_lib to erlang_questions a  couple of times
>but it hasn't seemed to make it into the distribution.

This brings up an entirely different issue.  The OTP team is doing a good
job with bug fixes and general maintenance, but general improvements,
significant and otherwise, seem to have ground to a halt, or at least be in
a state of confusion.  This has come up several times now.  It may just be
that Erlang is good enough for the places it is used, but it would be nice
to see some more active development.  A number of improvements have come up
and never seem to go anywhere.