
Logging Without Side-effects - nuriaion
http://dl.dropbox.com/u/7810909/writer-monad/chunk-html/index.html
======
gjm11
The author begins with some harsh words about conventional logging: he uses
the term "dysfunctional environment" to mean "system not using functional
programming", and says about attempts to separate concerns so that the
programmer can focus on actually getting the job done when not looking at
logging "None work. But you already knew that". On the other hand, "In
functional environments, we delineate the essence of a problem from its
execution model." and the author's system looks for "the essence of logging".

So, it seems we're entitled to hope that his monad-based functional logging
system will accomplish what "dysfunctional" ones fail to do: separate things
out so that your ordinary code isn't polluted with logging nonsense.

Here's an extract from the "demo" at the end of the presentation, illustrating
the system at work. This is the Scala version; there's a Haskell one too and
it looks very similar modulo syntax.

    
    
        val r =
          for {
            a <- k withvaluelog ("starting with " + _)
            b <- (a + 7) withlog "adding 7"
            c <- (b * 3).nolog
            d <- c.toString.reverse.toInt withvaluelog ("switcheroo with " + _)
            e <- (c % 2 == 0) withlog "is even?"
          } yield e
    
        println("Result: " + r.a)
        println("LOG")
        println("===")
        r.log foreach println
    

Oh. So introducing logging has required that the computation be broken down
into separate steps (fair enough; that's to be expected); that the syntax be
"monadized" (if you were doing this without logging and didn't need a
particular order of execution, those assignments would look quite different);
that _every bit of the calculation that doesn't need logging have a ".nolog"
appended_.

Note also that for a less-toy example where you want a single log for
everything your program does, the whole thing needs to get this treatment.
(Either that, or you need some _extra_ mechanism to combine the logging
efforts of different bits of the system.)

This is meant to be an improvement over scattering logging statements through
your code? It's supposed to _reduce_ the intrusiveness of the logging system,
and make it easier to "focus on the programming task"?

If you're going to present a logging system that is _in every respect worse_
than the ones used in imperative, side-effect-happy, statement-based
programming systems, I think it is unwise to talk about "dysfunctional
environments" and "the essence of logging".

~~~
dibblego
I would like to help you better understand the point here. Please let me know
how I might do this.

~~~
stephenjudkins
From the perspective of a reader not steeped in functional programming, your
proposed solution to logging is probably unpersuasive, for the reasons the
above commenter articulated better than I can.

* When using loaded terms such as "dysfunctional" to describe programming paradigms that the reader may be very comfortable with--and may have produced useful software using--make sure to thoroughly defend this characterization.

* Do you believe that there exist extremely intelligent, productive programmers who remain unconvinced of the merits of functional programming? If so, force yourself to adopt a charitable view of their skepticism. If not, what's the point of this presentation? Those committed to functional programming don't need to hear why their approach is superior, since that's just preaching to the choir; you can skip to the implementation section.

~~~
dibblego
* I'll happily defend the use of the term dysfunctional programming. Using this term serves quite a lot of purpose, in particular, among other things, to break a false dichotomy that regularly misleads. Your next question emphasises this, unknowingly I assume.

* Yes, there are legitimate complaints about functional programming. However, there are many "arguments" that are "not convinced of the merits", which simply argue from ignorance. I am not interested in discussion at this level, unless it's ultimately constructive i.e. teaching.

None of the points made in the original post are compelling. They can all be
easily over-turned. I can also make predictions about how much is understood
based on the points made (there are many examples of this, raising my
confidence that this is simply a very far-out misunderstanding). These
predictions would help for teaching.

I am offering an invitation to remedy the misunderstanding. I do not care to
address arguments from ignorance.

