Denise Stack (EEI)
Tue Apr 30 07:42:28 CEST 2002
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
Current complexity= 7418
4185 functions do not need to be exported
2070 functions can be moved
1163 functions cannot be moved
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
> Now this function calls
> 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)
> 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
More information about the erlang-questions