Thank you for the quick feedback. I will definitely add some more clear documentation and link to the Output object. Ill update the pull request asap.

I can change the implementation. However, I was trying to mirror cascading Debug functionality without changing what already exists and without adding a ton of methods that take different parameters (java style). Cascading's Debug uses the values as class defaults and then overrides them based on the constructor used. I chose to use the most complete constructor and use Scala's optional parameters to mirror that functionality. 

The results of using the new Debug function with all the defaults would be equivalent to the current debug. Using the cascading default constructor results in:
```scala
output = Output.STDERR, prefix = null, printFields = false 
```

I could make a method for each (or the most useful) Cascading Debug constructors (listed below) or make one value required as you suggested. I would most likely require printFields since thats my main use case and probably the most common. (I want to see the tuple fields at different stages in my flow):

```java
public Debug()
public Debug( String prefix )
public Debug( String prefix, boolean printFields )
public Debug( boolean printFields )
public Debug( Output output )
public Debug( Output output, String prefix )
public Debug( Output output, String prefix, boolean printFields )
public Debug( Output output, boolean printFields )
```

I do like the fact that the current implementation allows for all of the above combinations with just one function.

Given the above does that change your opinion on the implementation? If you would like a required parameter do you agree with printFields?