On 8/26/10 18:34 PDT, Walter Bright wrote:
Andrei Alexandrescu wrote:
At my workplace we're using Google's logging library glog
(http://google-glog.googlecode.com/svn/trunk/doc/glog.html), and the
more I use it, the more I like it. It's simple, to the point, and
effective.
I was thinking it would be great to adapt a similar design into
Phobos. There will be differences such as use of regular argument
lists instead of << etc., but the spirit will be similar. What do you
think?
Ok, I'm going to get flamed for this, but,
I don't get it
I do logging all the time. It's usually customized to the particular
problem I'm trying to solve, so it involves uncommenting the right
printf's and then running it. Voila. Done.
The logging libraries I've seen usually required more time spent
installing the package, getting it to compile, reading the
documentation, finding out it doesn't work, rereading the documentation,
etc., etc., than just putting in a #...@$%^ printf, and Bang, it works, cut
& print.
Even worse, the logging libraries are loaded with a grab bag of trivial
features to try and puff it up into looking impressive. They always
seemed to me to be a solution in search of a problem.
Shields up! what am I missing about this?
I was curious to hear what others reply - great discussion! I won't add
much to what was said, but I do want to emphasize a couple of points.
Logging is something that 9 people do in 10 ways. As such, leaving it to
everybody's whim will produce many incompatible logging styles, formats,
and mechanisms, which is untenable in any corporation that has
long-running programs on more than a few servers. I smile inside
thinking what logging would look like if everybody at Facebook decided
how to do their own logging on the many tens of thousands of running
servers.
You have already seen the value of standardizing on easy things that
everybody does differently - so that's why D has things such as version,
debug, and unittest as keywords. Most likely you have experienced
first-hand the outcome of leaving such simple policy decisions to the
whim of the user. It is easy to port that understanding and expertise to
a matter that is very similar even though you haven't experienced it
yourself.
One problem with logging is that it's one of those "pure design"
problems - it poses almost no algorithmic or systemic challenges. This
unfortunately creates an opportunity for overblown designs to come forth
and justify their own existence ("clearly you could do logging yourself
easily, but it would take you a long time to implement all of this
framework with all these features" etc), which in turn establishes a
ratchet mechanism that brings up ever more intricate, feature-full designs.
That's why I'm saying: keep the logging library nice and simple and
never allow itself to take it too seriously.
Andrei
