http://nbviewer.ipython.org/url/jdj.mit.edu/~stevenj/IJulia%...
I often need to do calculations involving many parameters, and there are three important considerations I usually have to deal with:
1. I'm probably going to want to tweak the parameters.
2. The calculation is going to be difficult to express as a succinct equation.
3. I may want to look back over the result later.
Using an ordinary calculator is cumbersome because of 1 and 2, and doesn't satisfy 3. AN alternative is to use an ordinary interactive shell to put everything together, which helps with 2, but still makes for a lot of work on 1 and doesn't fix 3.
Writing a whole program to do the calculation is an improvement because it fixes 1 and 2, and it helps with 3 because I can leave myself lots of comments. I've found literate CoffeeScript to be very effective here (you can even turn it into a nice webpage to share your math with others), but there are still some drawbacks. The results are not interleaved with the code, so when I look back over it, it's not easy to check my work and debug. The workflow also leaves a bit to be desired. You can't, for example, quickly play with a small snippet as you're working through your thoughts.
A notebook, on the other hand, elegantly handles all of these considerations. I can use markdown to create a nice article for my future self explaining all of my calculations, have comments, code, and results all next to each other, and tweak parameters on the fly.
Yet I still find myself using literate CoffeeScript instead. And the main reason for that is that whenever I use Python, I constantly wish that I was using CoffeeScript instead.
(the IPython Notebook is utterly, utterly wonderful. It's the first digital lab notebook worth a damn for data scientists.)
I've had several conversations with R folks who insist that RStudio + Knitr does everything the IPython notebook does, and I feel like I've had a hard time conveying why I like the notebook for data exploration, prototyping, and demoing.
E.g., the R notebook linked to below looks neat, but it's still just markdown compiled to a static document. That's a different workflow--not a better or worse one; but certainly different.
Personally, I find it more interesting to mix languages in a single notebook - we have a %%R cell magic which allows you to have R cells in amongst your Python code, passing data between the two. An R kernel would only run R code.