Mon Apr 29 12:44:51 CEST 2002
On Mon, 29 Apr 2002, Thomas Arts wrote:
> 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
> I was brave enough to scroll...
> > 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.
> But not the nollitons. If you write a library, you write it for the
> nollitons! Users are going to call these functions.
> calender:date_to_greorgian_date/1 may be a nollition, it is supposed to
> be that.
Yes, silly me ... :-) I was just overwhelmed by horror :-) A quick
peep gives the impression that there is a lot of obscure junk that
never should have been written (mea culpa) never have beeen exported
and should never be called.
The problem is that some of the nollotons are so obscure that that
should never have been exported - my feeling is that a lot of them are
exported just to allow spawn to work - a hang back to the days before
I'd really like to know which nollitons are not called by a major
application - these are canditates for removal.
The problem with systems is not adding new stuff - it's removing old
junk that is never used.
> Thus, the concern are the nollitons and singletons not in the manual
> pages, they are the really uglies... You are not going to tell me
> that you checked all manual entires for the 8148 functions, did you?
No - whould that I could - that would require a tighter integration
of the documentaion and code than is used today. Hopefully this will
be improved in "son of Erlang".
More information about the erlang-questions