Shock horror

[Denise Stack (EEI)]

Hi,
this could almost be amusing, if it didn't reinforce the opinion that
Erlang is getting more complex with each release....

I ran anal:go(all) using a version of R7B and found that firstly I had
to change the source code from xref:analyse/3 to xref:analyze/3.
Somewhere between tools-1.6.3 and tools-2.0.1 the undocumented
introduction of the alternate forms took place. Then the numbers of
exported function calls of each type seems to have increased to a rather
large degree: 

Current complexity= 7418                    
4185 functions do not need to be exported   
2070 functions can be moved                 
1163 functions cannot be moved

/Denise.

Joe Armstrong wrote:
> 
>    Complexity Shock Horror ....
> 
>    I have found to my horror and amazement that that our beloved
> Erlang system is far more complex than it should be ...
> 
>    ... it all started  when I started reading systools.erl ...
> 
>    Warning -  timid souls  should not read  on for  this is a  tale of
> horror that will chill your very entrails and make you doubt your sanity
> 
>    ....
> 
>    (scroll the page for more)
> 
>    I wanted to change
> 
>         systools:script2boot/1
> 
>    Now this function calls
> 
>         systools_lib:file_term2binary/2
> 
>    and I could not understand why the code for this had been placed in
> a *different* module - surely *nobody* would want to call
> systools_lib:file_term2binary/2 - it's so obscure that nobody would
> ever think to use it. And it's not even documented (systools_lib) has
> no man pages - so the chances that anybody would ever even think of
> using this function are minuscule.
> 
>    I thought to myself - "I'll do a Xref analysis to find out if
> anybody calls systools_lib:file_term2binary/2" - this turned out to be
> more difficult than I had imagined - xref once small and easy to use has
> grown in complexity since I last used it to the point where it is almost
> (but not quite) impossible to use.
> 
>   <<xrefs manual pages seem also to have degenerated to the point of
> unusability - but *that* is another question>>
> 
>   After a few false starts and guesses to what xref did I was able to
> analyse the system to see who called "systools_lib:file_term2binary/2" -
> and my intuition was correct:
> 
>   systools_lib:file_term2binary/2 is only called from systools.erl
> 
>   Now I might be completely "out and cycling" here (as my Swedish
> friends would say) - but IMMVHO (Most very :-) if it is the case
> that only one other module calls an exported function then the
> function could be MOVED to the place from whence it was called.
> 
>   A case of
> 
>         "Whither wert tho called oh systools_lib:file_term2binary/2?
> 
>         "From only systools.erl"
> 
>         "Then go ye thence"
> 
>   So I thought to myself - How many exported functions are "singletons"
> (by that I means functions which are only called from one external
> module) - To answer this I wrote a little program...
> 
>   During the writing, thereof, I discovered that there were not only a
> large number of singletons (I had hoped that I had stumbled across the
> only one) but also a large number of "nollitons" - exported functions
> that *nobody* calls.
> 
>   For your edification and delight, the numbers are:
> 
>    #exported functions = 8148
>    4632 functions do not need to be exported (nollitons)
>    2225 functions can be moved               (singletons)
>    1291 functions cannot be moved
> 
>  Pretty stinky stuff, ej wot.
> 
>  IMHO every time a nolliton or singleton is used the system become
> more difficult to understand and more difficult to structure and more
> difficult optimise - "module at a time" compilers do not like external
> functions - and thinking up sensible names for them is a pain in the
> nether regions.
> 
>  Even worse I don't even know if we can remove the buggers - perhaps
> (horrors) some application actually calls an undocumented nolliton -
> removing (say) all nollitons might awaken the the great God of
> backwards incompatibility - their might be much gnashing and grinding
> of teeth and wailing and crying if we did this ...
> 
>  Before the age utopic bliss is achieved (thank you Thomas) we could
> perhaps check to see if any of the BIG applications call the nasty
> little nollitons and singletons ...
> 
>  Do they?
> 
>  Run the enclosed program to see (adding you own own application
> modules to the set of stuff that is analysed)
> 
>  /Joe
> 
>   PS cannot anything  be done about this, apart  from a total re-write
> using Richards heirarchical module system  (which I guess we should do
> at the same time :-)
> 
>   ------------------------------------------------------------------------
>                Name: anal.erl
>    anal.erl    Type: Plain Text (TEXT/PLAIN)
>            Encoding: BASE64