It looks interesting, but the screencast needs to be a bit more concise, and aimed at people who would actually use this. I made it through the first 5 minutes and gave up, because I wanted to see what the library did. I didn't want a tutorial seemingly aimed at absolute beginners, who in my mind wouldn't give two hoots about improved debugging at that stage.

Had there been a shorter overview of the cool things you could do, I might have got a better impression.

Read the API. I had the same problem and skimmed through the API in 2 minutes.

This looks pretty cool. At first I had the reaction that it was too simple. I didn't have patience to watch the video, so I just read the homepage.

I think you should at least mention the other "letters" included in the library on the front page. It goes in depth into 'p', which makes it seem like it's all there is. Maybe name some of the other letters, and link to the API docs.

Each individual piece seems pretty small and easy enough to implement, but the package as a whole seems more valuable, having all these little tools in one place.

Nice work

This is great feedback, thanks. I updated the docs.

This is great. It's sad to say but there are coders (like me) who will write our own half-assed muck in order to half-assedly follow good procedure...or even worse, just skip procedure all together. So any well-implemented, graceful simplication can be more valuable than the library and its seemingly few lines of code at face value. Thank you for putting this together and I hope you keep improving it

What am I missing? I looked over the API and tried to skim through the video (10 minutes in and still no demonstration of anything in the API), but I couldn't figure out why any of the Letters functions would be preferable to just jumping into a debugger session.

Anyone care to explain?

Letters is an abstraction layer over the ways many people detect problems with code in the real world. (I see these patterns re-emerge every day.) A debugger is part of the solution. Easy profiling and object diffing are another. Detecting how vulnerable you are to XSS attacks is yet another. When you have the power to do this inline without breaking your code apart, I think you gain productivity.

In other words, these patterns are not something we should have to spend brainpower on.

I probably should not have put the screencast on the front page -- it's actually about rationale and not about code examples. You can find concrete examples at http://lettersrb.com/api

Didn't check the code out but it looks like p is something like:

    obj.tap { |x| puts x }

That's the base case. It takes arguments, too, and if you give it a block, it prints out the result of the block called in the receiver's scope.

Why `p` though? That's a method on Kernel already and does puts(args.inspect)

Just changed it. I was hoping people wouldn't mix and match, but I don't mind using `o` instead:

https://github.com/davejacobs/letters/issues/6

Thank you very much.

Cool, looks like a useful library.

The problem this is trying to solve is an annoying one - so much so that I just wrote something similar a couple of weeks ago: https://github.com/suan/quick-debug

Letters seems like a better way to do it though.

Nice, but for quick debugging I usually use pry: https://github.com/pry/pry

This is great! I think I'll start using this, I'm tired of putting prettyprint statements everywhere :P