My init.m Feels Like it's Missing Something
Although I am familiar with about a dozen or so programming languages I am only sort of, kind of, halfway competent in about three. MMA with it's boxes, expressions, patterns, symbols, and cells is a whole new beast to me. It forces you to forget everything you think you know about programming and think differently. Then it throws a wrench into the whole mess hy introducing the init.m without a good explanation.
The following working code is what I have so far. It is what I call my pre-alpha init.m. My concerns are that it may be missing something that MMA experts normally place in there. For example is this a good place to clean out old temp files, remove obsolete symbols or delete obsolete objects, create persistent objects, set new paths, set $HistoryLength
, ClearSystemCache
, is using Once
here okay, etc.? My other concern is where should I drop copies of init.m if I want it to survive a refreshed Kernel or a crashed FrontEnd?
(* overload immediately needed repository resources *)
Once@(
Quiet@PersistResourceFunction["PersistResourceFunction"];
Quiet@PersistResourceFunction["SymbolQ"];
Quiet@PersistResourceFunction["ResourceFunctionMessage"];
Quiet@ResourceUpdate[ResourceObject["PersistResourceFunction"]];
);
(* overload immediately needed packages *)
Once@Map[Get,{"Alphas`", "NBEssentials`", "NBTaskmate`","NBStyles`"}];
(* other cool tasks TBD *)
Since I have your attention is it okay to do this: Once@Get /@ {"Alphas
", "NBEssentials", "NBTaskmate
","NBStyles"};
?
There is Almost No Help Published by Wolfram
Some of our most essential code is hidden away in a file that we can just drop 'n' forget. Although the proper contents of this infamous file is expected to be well understood by all seasoned programmers the official documentation at Wolfram only hints at but gives no solid examples of the kind of things to put in there. This would help coders like me who are not programmers but come from a different field like physics and engineering who need to employ coding with their work and must adhere to best practices to go with it.
What Mathematica Stack Exchange Has to Offer
As of this writing a search for init.m yields 419 help posts. However these are all about fixing specific-area applications or broken code not about building a proper init.m.
There are a few "big-list" posts such as the ambitious undisputed world heavyweight that grew into Godzilla which I really like, Where can I find examples of good Mathematica programming practice?, unfortunately in its quest to answer all best practices under the sun it forgets to even mention the init.m. Another one I really like is the more focused Getting serious about Mathematica programming but it too omits the init.m. There are others. This is just a very small sampling that stood out to me as expected to have a dedicated category on the init.m.
The Five Secondary Goals of this Post Are to Help Build Best Practices
Of course the primary goal is to examine my init.m which will help me figure out what is good to put in there and what not to put in there. Along the way we can help many others by identifying some best practices.
- Let others learn from your best practices by sharing your code in an Answer.
- Let others share their expertise in how to improve your shared code.
- By identifying what every init.m file should have and why.
- By identifying what what every init.m file should NOT have and why.
- By identifying in which directories we should drop 'n' forget our init.m and why.
With posts like these there are no losers, everybody wins. The only catch is we all need to participate to win.