Edit and run a script with another script

I need to use two scripts that are part of a packaged program many, many times in a row, so I'd like to find a way to essentially put them in a loop. More specfically, I need to open hawt_params.m, change the variable blade_params.pitch, save it, then open create_hawt.m, change the entry in arg_list{3}, and then run it. I did some searching and it seems the usual advice for such questions is to write functions and not scripts, which, of course, would make this trivial. I'd really rather not try to convert someone else's scripts into function, though (unless that's easier than I'm imagining). I'll admit that I, myself, am a script writer, so perhaps the barrier is more mental. Anyway, I'm looking for overall efficiency of the task, so, if there's a way to get it done with the existing scripts, I'd love to learn how. Thanks.

[Rik]

What barrier do you have that is stopping you from writing functions? Even scripts are generally treated as functions: before it is called the workspace has some state, and after it runs the workspace has a new state. Those are your inputs and outputs. What you describe sounds really simple, but your solution sounds extremely complex. I don't see why you would want to keep scripts in production code. Scripts are for debugging. Functions can hide implementation and can provide a clear documentation of inputs, outputs, and side-effects. Scripts lack all that, and can also pollute the calling workspace and overwrite essential variables without warning.

Why reinvent the wheel?

[Daniel]

My wheel is a script. I have almost always used scripts, so that is my habit. Habits are hard to change. I don't like change. Scripts work for me. I like having everything in my workspace so it's visible and accessible.

My solutions was about as simple as it gets. I copied and pasted two scripts (that were already designed to work in conjunction) into a new script, added a loop around them, and edited them to change a mere two variables based on a new vector. It was certainly more efficient for a one-off need than writing a new function.

[Rik]

Let me be clear that I don't want to yuck your yum.

My problem with scripts is that they don't provide encapsulation. The way I write code is that it works in blocks, where each block has a purpose. It does something. I believe that something should have a name so I can easily reuse it later. Within that block it is fine if all variables live in the same workspace, but I don't see why my code that reads a text file should share a workspace with code that processes it, nor with the code that is creating graphics. I'm not in the camp that anything over 6 lines should be split into two functions, but I do think it is useful to have small functions.

How do you deal with more complex tasks? Do you copy code all over the place? What if you think of an optimization?

If you make your code a function you can use that function in two places already. It clearly is a logical unit already, otherwise it wouldn't have been a single complete script.

[Daniel]

I do copy a lot of code and I often have to make little adjustments when doing so. I can imagine that a well-written function would avoid some of those adjustments, but, just the same, some of those adjustments are what make me think that writing a function wouldn't save me any time since I can't imagine writing it generally enough. I suppose it's the sort of thing where I have to weigh the cost of learning and perfecting a new method against something I've been doing for years. I also rarely find the need to optimize. I'm sure "experts" would be disgusted by my code.

[Rik]

I don't really see what about functions is so daunting. You just move the first block of code in your script (where you define some input variables) to the function definition.

If you have a look at some of my bigger FEX submissions you will get an idea of the typical size of my functions (readfile, ComputeNonCryptHash and WBM should be decent examples). Once they are small enough you start building up a utility belt of functions. Using functions also prevents me from having to dive into my code again.

I'm not saying copying a lot of code is bad. The input parser is mostly the same between all my functions, as the details are extremely function-specific, but the overall framework is not. The point is not that you can't addapt existing code, the point is that you make black boxes that free you to focus on the structure of your code, instead of the specifics.

Also note that bad habits are easy to develop and hard to unlearn, which only gets worse the longer you stick to them. I'm also (at least slightly) embarassed by my old code. The difference is that I can update the code from readfile version 1.0 and replace it by the current version. No other code needs to change, except that now the function works on more files or is confirmed to work under more circumstances.

If you consider this function you might see my point: reading a text file is often only a small part of the process. The point is that the reading itself can be handled by a black box. Now I'm free to write the code that selects lines and processes them.

The same goes for isnetavl. I found out that some companies block the ping system function. After I wrote a workaround, I only needed to update that single file, and all other functions trying to confirm an internet connection would work again. With your system you would have to hunt down every place you use that code and update every occurence, checking if you made edits to that specific version you would have to keep.

Answer 1

[Daniel]

I found a way. I just copied and pasted the two existing scripts into a new one and created a loop around them. Pretty easy, but still curious if there's any functionality for scripts to interact with each other.