Too much builtins (was Re: Python's simplicity philosophy

[Ron Adam]

On 13 Nov 2003 22:40:35 +0200, Ville Vainio
<ville.spammehardvainio at spamtut.fi> wrote:

>Douglas Alan <nessus at mit.edu> writes:
>
>[reduce]
>
>> >> If someone can't understand this quickly, then they shouldn't be
>> >> programming!
>> 
>> > Again, it's not "can't", it's whether they need to or not.
>> 
>> If you don't want to learn a cool concept that will only take you 60
>> seconds to learn, then you shouldn't be programming!  Or you can stick
>> to loops.
>
>As far as reduce goes, ppl will undoubtedly take a look at the
>description, understand it in well under 60 seconds, can't think of
>any use for the feature during the next 60 seconds (that wouldn't be
>clearer with explicit iteration), and forget it soon after turning the
>page. I didn't forget it, just wondered why such an oddball feature
>was a builtin. Obviously reduce can rock someone's world, but life is
>too short to bother if it doesn't rock yours.
>
>> and powerful feature with a slew of specific, tailored features.  If
>> reduce() can be relegated to a library or for the user to implement
>> for himself, then so can sum().  If the language is to only have one,
>> it should be reduce().
>
>I also think that reduce, sum, map and filter (and lots of others,
>__builtins__ has *too much stuff*) should be removed from builtins,
>but that will probably take some time (1997 years?). LC's and genexpes
>will take care of most of that stuff. And people can always do:
>
>from funtional import *  
># map, filter, reduce, curry, ... (I want lots of these :)
>
>There are also tons of functions that should be in sys, math or
>whatever:
>
>reload, repr, divmod, max, min, hash, id, compile, hex...
>
>What's your pet deprecation candidate? I have always thought
>`backticks` as repr has got to be the most useless feature around.


I think from a pragmatic point of view,  what should be a built in
core,  built in module, or in a standard library,   should be
determined by how often they are needed to be used or depended on in
programs and modules.   You could probably do a statistical annalist
to determine this by searching though the libraries,  and a fairly
large library of end use applications.  

Moving things closer to the core may increase the efficiency of the
most used items,  and moving things further away would simplify and
better organize the language.   It's always a trade off to some degree
isn't it?  

Also,  being in the core is not necessarily the fastest way.  Modules
that accessing compiled and optimized dll's can be faster when related
functions are grouped so they can share code and data internally.

_Ron Adam