I code in the exact same way: many iterations, and a constant visual feedback to make sure all the side cases are covered -- to divide and conquer, but also map

I code in the exact same way: many iterations, and a constant visual feedback to make sure all the side cases are covered -- to divide and conquer, but also map the problem as it is too easy to forget some side cases! I am currently learning SAS, an old language. I find integrating it in an environment that allows literate programming (and live programming) extremely useful. I chose Rstudio for the many visualizations available. Now I am starting to love SAS -- even the "old school" things like "cards", which allow embedding data within the document. This is extremely important for reproducible research. But there comes a time when a precise question must be answered, and exploration must be stopped to concentrate on what is important, and cast away the details. That is when learning solidifies into something tangible. I believe coding is initially a 2 step process, and that the 3rd part of the lifecycle of any program (maintenance!) can benefit from welding these first 2 steps together in a notebook. A notebook allows to document the development process and refresh your memory whenever you need to look at some old code and understand why it was implemented this way. For me, the 2 steps + lifecycle process is: 1) exploration, cobbling together a first implementation, and using Echo/print or their equivalent to make sure it works. Good old print debugging is extremely effective because it allows you to check if your algorithm follows your logic 2) refining the solution, reimplementation. Discard the Echo/prints, add a debug flag, and a test data set to make sure you get consistent outputs. Sometimes, it is even time to switch to another language if performance is an issue. Minimal documentation of the code is kept. 3) maintenance, extension. If 1 and 2 were done in a notebook, whenever documentation is not sufficient, it is extremely easy to go back to the first versions of the code, and do some tweaks. Mathematica is a wonderful tool to do that, but Rstudio is just more useful these days to mix various pieces and languages. I find myself using Rstudio more and more for everything these day -- even for shell scripting and SQL. By the way, I love your example [2] -- the density of information is high. I just wish there was a way to integrate the Mathematica engine within Rstudio, with a rending rendering of the output. Do you know a way to submit a piece of code to the Mathematica kernel, then get Mathematica output properly formatted say as HTML? (and of course, automatically, in a way that can be scripted) This is a bit like how ODS work in SAS. If it takes several steps, that's fine. I just want to create something that I feed Mathematica code to, and that returns to me the Out cells, not just as ascii text but properly rendered to integrate within Rstudio. Extra bonus point if the output is not just a html rendering, but also contains javascript to allow Manipulate.