I hope things turn around for you this summer.

I agree with you on the debugger. But, I started my career debugging two-wire communication using an oscilloscope on the wires and a logic analyzer around the CPU. So, I am able to remind myself things could be much worse.

To answer your question on conditional outputs, I use a pipeline paradigm. You are correct, it does add a bit of overhead (more functions), but I am usually able to keep the functions smaller and focused on a single task.

One of the strengths of WL is that it supports so many different ways of doing things. Of course, that is also one of its biggest drawbacks. We cannot win them all.

Thanks for the conversation.

This summer is not so great unfortunately. Actually currently I am at a hospital for a few days. It's not Corona, but relatively harmless. Anyway, all those rules for daily life are not so agreeable. Paticularily in hospitals.

Concerning "Print" again: Just like probably you do I try to avoid global variables. Hence each functional piece of code is packed into a block or module. Not only functions but the final "main"-program as well. (Btw: I did not really understand why WL has Block and Module. I prefer Block because it acts similar to ordinary program call-stacks in other languages).

Hence, if you need multiple outputs from within one block you have to use either multiple prints or do what you do: Packing them all together into an overlayed larger structures and returning that from the block.

I can see your points why you do that, but for me most of the time this is just an additional more or less complicated layer which makes the program worse understandable and is functional superfluous. Print is a much more straight forward approach.

And, on top of that, what do you do if you have conditional outputs within that block? The standard WL-way of printing the returned variable at end of block will not work then. You would either need another function just for outputting your output structure. Or you would need a lot of different return-points within your block, which is really ugly and bad for testing.

Thanks very much, Mike. Your solution, packing the Manipulate into a function (myApp in your example) is exactly what does the job.

Concerning your question why I Print the Manipulate: The Manipulate-output is just part of some more output (a grid actually).

The Wolfram language supports many (perhaps too many) different programming paradigms and patterns. This often means that there are an infinite number of good solutions to every challenge.

In cases like this, when we do not have to use a global variable, I usually prefer to keep things local by passing them in with something like:

myApp[graphs_List] := Manipulate[
   graphs[[i]],
   {
    {i, 1, "Step"},
    1,
    Length[graphs],
    1,
    Appearance -> "Open"
    },
   LabelStyle -> Directive[Black, Bold, 11],
   ControlPlacement -> Bottom
   ];

myGraphs = {1, 20, 30, 40};
myApp[myGraphs]

I believe this solution:

• Keeps things simple
• Makes it clear that visualization never updates the input data
• Allows the visualization to be reused

Of course, there are other simple solutions. And sometimes, keeping your data global is the best solution. In this case, I got the following to work:

graphs = {1, 20, 30, 40};

Manipulate[
 graphs[[i]],
 {
  {i, 1, "Step"},
  1,
  Length[graphs],
  1,
  Appearance -> "Open"
  },
 LabelStyle -> Directive[Black, Bold, 11],
 ControlPlacement -> Bottom
 ]

Also, I am curious as to why you are printing the Manipulate instead of just returning it?