Using glog's design for Phobos?

[Andrei Alexandrescu]

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