using a function as the "main" script

The fact that every function (excluding anonymous functions which are very limited) has to reside on a different file is very annoying, maybe because I'm used to other programming languages like C. It occurred to me that by making my main script a function I have the option of having functions defined in the same file,while I can still have other functions saved in their own file either because they are big enough to justify it, or they are used by other modules, etc.

One drawback is obvious: the workspace is not available after the program finishes. OK, I can live with that. Are there other factors to consider (needless to say I'm rather new to MATLAB)? I guess it cannot be really bad since when using GUIDE this is what happens anyway.

[dpb]

Scope of functions is somewhat similar to file scope in C.

You can have multiple functions in the same file in Matlab, simply that they're not visible outside that function file.

Whether that is or is not advantageous depends on the purpose of the function--obviously, if it's a general new utility function of broad potential application it makes no sense to make it only visible within some other function. OTOH, if it's a helper function or simply a factorization of a functional objective, then it's far better that it be such.

"When in Rome..." is worth remembering--Matlab is not C (or Fortran or any other particular language). It is somewhat unique and one eventually becomes used to those peculiarities albeit some are easier to adjust to than others depending on one's background.

[John D'Errico]

So you need to learn different programming patterns. If all languages were the same, then why bother with another language?

We can't really know what other "factors" you would want to consider, since we can't know what things you will find annoying.

[Josh]

to dpb:

"You can have multiple functions in the same file in Matlab, simply that they're not visible outside that function file." - sure, when your file is a function! Hence my question about declaring the "main" script as a function, so I can have the privilege of sticking some functions in that same file instead of having a large number of rather small files. All considerations about scope etc. are , of course, relevant.

to John D'Errico:

I was asking just about that one thing: the downside, if any, of having my "main" script defined as a function.

[John D'Errico]

And we don't know what you might consider a downside. Perhaps it is time to just learn MATLAB instead of grousing about things being different from C.

[dpb]

I thought I outlined a fair reason for/against choosing to do that (incorporate multiple functions within a given file, that is).

The question of whether a "main" is written as a function or a script is primarily a choice of what one wants for scope and for what purpose the script is being written--and we can't know that for you plus it's highly dependent on a given task. Sometimes you want stuff to be in the workspace because you're working interactively; other times there's no need to have anything visible in the workspace so functions are a logical choice to hide clutter.

To me the question is almost entirely scope and the purpose of whether I'm writing code "in anger" (as a Scottish power plant engineer I worked with years ago referred to plant testing once the preliminary work/setup was done) or whether it's just a throwaway for a query here or on cs-sm or the like.

[Josh]

Thanks. Again, I am well aware of the general software engineering issues of scope, re-usability and other such design considerations. I was wondering if there are any differences between script and function files (e.g. performance wise) that should affect the decision and that I, being new to MATLAB, don't know about - aspects that are unique to MATLAB. From the discussion here I take it there is no obvious reason to stick to intuitive idea that the "main" should be a script. It's not too surprising; as I mentioned earlier this is what happens anyway when one uses GUIDE.

Anyway, the tone of some replies (not yours) gives me the impression that I sound like I'm complaining and whining about MATLAB (maybe the term "very annoying" I used at the start of this thread was poorly chosen). I'm not; Actually I like it a lot.

[Image Analyst]

dpb, please put/move extensive comments like this as answers so I can vote for them. I'm trying to get you (and Greg) up to 3000 points by the end of the year so you can have full "god-like" powers.

[Josh]

Very intersting, dpb, that is the parts that I understand are...

Your opening sentence, "It's always changing with each release" brings another quation to mind, but I guess it deserves to be on its own thread. I would greatly appreciate your involvement there, too... The

[dpb]

OK, IA, I did...I had noticed you were being pretty aggressive on voting; wasn't sure of your motive(s)... :)

Answer 1

[Image Analyst]

It's not really a drawback. In fact you could make a case where having variables hanging around after a function has finished is a drawback. It's just all about scope and every programming language has times when certain variables are in scope (able to be seen) and certain variables that are not in scope.

As far as what other things are different with C, you can search for "differences with C" on the Mathworks site and find pages like this: http://www.mathworks.com/help/matlab/matlab_oop/matlab-vs-other-oo-languages.html

[Josh]

Thanks for that link!

[Image Analyst]

I use simple scripts for small test routines. Like you said, it's convenient that the variables are left in the workspace so you can examine them when the script's done. With a function you'd have to set a break point at the end of the function to be able to do that.

If the script becomes a little more complicated, and you'd like to have a function in it, then you can do that. Just define your function(s) below your script but be sure to put a "function" statement at the top of your script because you can't have a script followed by any functions - they must all be functions.

Once the test algorithm is fully tested and developed then it's time to build it in to a more sophisticated GUI where the user can do all kinds of complicated things and set all kinds of parameters and options with various controls like sliders, radio buttons, etc. So I transfer the script into a function or control callback of the more sophisticated program, like the one you build in GUIDE.

I hope that explains it a little better, at least my workflow. If so, you can accept or "Vote" for any answers you like.

Answer 2

[dpb]

It's always changing with each release, but the one area that may make some difference is the level of optimization done by the JIT compiler on scripts vis a vis functions. At one time, at least, scripts weren't or were only moderately optimized whereas functions were (iirc; this is memory from quite a while ago, not gospel). I believe at current time only difference of real significance is that between the interactive command line as compared to m-files whether they be functions or scripts.

The one obvious difference is that there's a slight additional overhead of calling a function to build the local scope but for a main only called once, that should be negligible.

The key difference from C or other compiled languages is the introduction of the interpreter to eliminate the specific compile/link step. With the advent of the hidden JIT compiler while was always a step there to get from source to an executable form, the performance has improved significantly in most areas at the cost of the increased number of methods and higher-level data abstractions that have noticeably higher overhead associated with them. It's a tradeoff that only "time-in-grade" will eventually let you evaluate more fully in comparison to the alternatives.

In general, one finds the added functionality of the packaged supporting libraries make up for the overhead; otherwise there wouldn't continue to be a market. At some point, the complexity and/or computational intensity of projects can get to the point that it becomes necessary to move some or all of the computational engine to compiled code but often that can be done simply by judicious use of mex-files and the like while retaining the user interface.

ADDENDUM

On Sean's comment -- there's always while debugging scripts the alternative besides setting the breakpoint in the function of using assignin to place variables of interest in the workspace. I've at least been known to do this for this reason, particularly if there are other corollary things there that aren't in the function I'm playing with at the time...

Answer 3

[Sean de Wolski]

I use scripts for simple one time things and for examples that I want to publish, or examples that document the use of a function. Everything else I write is a function or class.

• Drawbacks to functions: you have to put a breakpoint at the end to see its workspace. I do this so much I barely consider it to be a drawback.
• Drawbacks to scripts: they mess with and possibly depend on your base workspace. They don't clean up after themselves. They're not quite as jittable because the interpreter has no idea what it's going to be given until runtime.