Another Log implementation

[Andrei Alexandrescu]

On 05/29/2011 04:52 PM, Vincent wrote:
> Hello, Andrei! Very appreciate you spent time on my work.
> I agree with some your critique, sure it's just a question of
> improvements. My main question is acceptance of my log library as a
> whole conception, since it's simple and 10 from 10 programmers can
> understand its sources (I keep it as very serious goal).

Why? 10 out of 10 would be more interested in using the library 
effectively instead of reading its source. Clearly keeping the source 
readable is desirable, but not an overriding goal. It's probably the 
last thing you care about after having taken care of everything.

> Let's discuss doubtful points...
>
>> Verbosity is not very often used indeed but I'd guess many people got
>> used to it because it's present in most libraries.
>
> Habit is not the rule. You must remember those days when every DOS
> editor show time in menu bar. WHY? Just because everybody did it. I see
> nothing bad to loose this 'verbosity' as archaic feature.
> As I said before, 'special demands' is the pain of 'special programmers'
> - if they REALLY cannot live w/o 'verbosity', they can add it in 3 LOC.

You mentioned you don't care about verbosity levels. I added that I 
haven't found a lot of use for them either. Next thing you know, you're 
presupposing your own assumption. Isn't the data set a tad small to draw 
conclusions from?

>> * The library doesn't take care of capturing the origin of the log
>> (file/module/line) so the user must pass them manually.
>
> I've read posts related __LINE__s in log and don't see any reason in
> this feature. Why?
> 1. It's not direct task of 'logging'. Log doesn't care about your
> lines/files just because you're too negligent to control what and where
> you log - its task is just assemble together runtime info.
> 2. Nobody prevent you from doing it! Just make 'mixin' with __FILE__ and
> use.
> 3. In my practice I didn't see so low-level approach for debugging -
> well organised log shows enough, why people care about number of code
> line in editor?? Funny, heh...
> 4. Logging is not only "We have a problem in line 10!" - it's "trace of
> life" for our program.

Without automated headers including location of the log line and 
date/time, one can't even call that a logging library. It's an text 
streaming facility.

>> * The library requires version(logging) to control enabling.
>> Essentially the client would need to prefix _all_ logging lines
>
> Agree completely. But something says to me that it's just a my little
> knowledge of D (and it's true). Sure there is some feature to make log
> calls 'invisible' without 'version' prefix - I just used feature I sure
> about. May be mixins will help? This is the place where I need help of
> community.

The help can be readily absorbed from reading the existing proposal.

>> * The library always evaluates arguments, even when logging is
>> dynamically disabled.
>
> First, let's remember Knuth's "Premature Optimization" warning - say
> "it's slow" only when it's really slow down your program.

Evaluating arguments always vs. not at all is a matter of principles.

> Second, remember use case of this "runtime switch": "ALL logging is
> enabled (read "everywhere it's slow"), but at this place it's disabled
> (and who cares how slow it is?)".

It is very important that the program is as fast as it can when logging 
is disabled. I don't understand how one could argue sensibly otherwise.

> Third, if you use log, you NEED this info, despite how fast it was
> calculated. And even if you jump over with 'lazy' arguments, they HAVE
> to be calculated - you wait 'em anyway! So... what a benefit you have
> from laziness?

With lazy evaluation you can arrange that complex expressions inside the 
log calls are not evaluated.

> And hell, if you're good programmer, you'll never write critical section
> like
> log("a");
> log("b");
> ...rather you accumulate log info and output it at once.
> I agree with usefullness of 'lazy' stuff, but not in this case.

Sometimes you do need to insert log expressions in relatively critical 
places for debugging purposes.

>> * The library does not define a notion of a severity hierarchy
>
> If you look at use cases of this 'severity', there is no 'hierarchy'
> (look at usage of my library) - it's again "habits" of 70-th. Just
> obvious example from real life:
> I log all 'info' messages about client actions. But somewhere I get
> database exception - my fault, logged as 'critical'. Together with two
> levels above I have 'warning' level about problems like 'this person has
> no surname'. Question is: "Why I must dig in 'warning' trash, when I
> just need info what client did and which critical problem happen?". As
> you see, 'hierarchy' is just "flat" view on problem - there is
> independed severities and _combination_ of 'em.
> Again, no apocalypse happen - who need this feature, that must spent
> time on it.

Your example describes a trivial matter. Often times, the trace leading 
to a critical problem is indicative of the issue in more complicated 
applications.

>> Arguably defining a hierarchy could be considered outside the scope of
>> a "core" logging library, but that means more work for the casual user
>> of the library to achieve a common task.
>
> Exactly. You cannot include in simple 'string assembler' all
> functionality (esp. legacy point of view - time is changed!). Simple
> requirements must lead to simple usage - if you don't use 'verbosity',
> why you should pass parameters in every log call?

Who does? Did you skim the existing proposal at all?

>> I believe something close to Jose's library (after community feedback)
>> will become the standard library for logging, so we should at best we
>> consolidate efforts behind it.
>
> What if I don't believe? :) We'll spent time on functions, used by 1% of
> 'old shoes' and give a bad example for next generations. I don't pretend
> I wrote the best library ever, but I kept on rule 'implement only
> necessary stuff' and I have a reason for every decision.
> Well, I don't want to press anybody, but before you completely give up
> my implementation I wanna be smashed with serious arguments how bad my
> design is. :) (may be it'll be good lesson for another designs!)
>
> Good luck for all community!

Same here, and welcome. First, this seems to be the third time you are 
referring negatively about age. That is never in good taste, and can at 
best be tolerated if it comes from a position of exceptional achievement.

Second, if you're looking for definitive arguments for or against your 
design, you're unlikely to find them. Design is a subjective endeavor, 
so you can always make a counter-argument to pretty much any argument 
(as you just did).

Third, I find it tenuous to agree that you "implemented only the 
necessary stuff" and that you "have a reason for every decision". If you 
cast a candid eye over your design, you'll notice that it has virtually 
nothing to do with logging aside from using the "log" word here and 
there. It's barely a design at all as it's just a barebones streaming 
text out glue that assembles an external string template engine with an 
ad-hoc streaming interface containing only the Write primitive. So 
unless you set out to implement nothing but simple streaming, you didn't 
implement only the necessary stuff; and if you have a reason for every 
decision, then by necessity one motivating reason was to stay away from 
anything specific to logging.



Andrei