Actually, I think the Resource System (as related to, but distinct from the public Wofram function repository) is a great solution for "snippets" like this as you call them. Simply create a Resource Function! Resource Functions do NOT have to be pushed to the WFR, but can be deployed locally on your machine, or sharably in the cloud. For local publication, you don't even need to write documentation (tho, even for snippets, I think it is usually worth it to write down a basic usage).

Anyway just an idea. The same menu that gets you "Submit to FunctionRepository" will also get you options for "deploy in this session", "deploy in the cloud", and "deploy on this computer". If you choose the last of these, the function will always be available (without any pre-loading) via ResourceFunction["MyNeatFunction"].

Hope this helps!

A low-maintenance alternative to managing packages is to simply run NotebookEvaluate["~/path/to/myUtilities.nb"] in whatever notebook you want to use myUtilities functions and symbols.

I use this approach in my forthcoming book Functional Dataflow, and was happy to hear WRI's publishing unit is adopting this method of separating utility functions to such Appendix notebooks.

Advantages:

• No need to modify anything in the source notebook

• Can be chained so that a target notebook need only call NotebookEvaluate once, and not the entire set of dependencies

• If the source notebooks are managed eg Google Cloud or similar cloud filesystems, then you need only update at a single location. These updates will be auto-sync'd to other device filesystems.

Disadvantages:

• No namespace control
• No private/public distinction

Mathematica has a standard method, quite simple, to put together material in an Application, which is convenient for your own usage and easily transmitted to other users. I describe this in my essay at A Mathematica Style at my web site.

An Application is placed in your $UserBaseDirectory//Applications folder. It can contain notebooks, packages, palettes, style sheets, documentation, other types of files, and folders. The packages can be loaded with a simple statement, and Mathematica automatically knows how to access all the material. You can have just the items you want. You can just zip it up and transmit it to another person. You can have private development folders that you delete from the public distribution. If you start out with this format you won't have to reorganize or jerry-build when you add new things.

Making user-defined functions 2nd-class citizens is the same uglyness as having to import packages - something that WRI explicitly tries to automate - yet we have this ugly syntax:

ResourceFunction["AssociateToNested"][a, {"a", "b"} -> x]

versus 1-st class functions:

AssociateToNested[a, {"a", "b"} -> x]

Even Python's syntax is preferable.

Thank you Neil, and Alan. Both those suggestions sound great. I think I will try both approaches and see if one seems to fit my natural workflow better.

Cheers Andy

Hi David, Thank you for the link to your essay, that looks like a really useful approach. I will give that a try too.

Cheers Andy

Hi Micah, Thanks very much for your thoughts. I would be very interested to look at the paclets notebook, it sounds very encouraging.

I am also really interested in the various IDEs that people are using. I am gradually understanding the different ways in which I could use the Wolfram language. There seems to be a breakout when one moves from exploring a problem - notebooks seem to work well for that - and actually coding a solution, where perhaps the IDEs make more sense.

I am also conscious that my thinking has been coloured by the fact that I usually use Smalltalk, and therefore I am bringing a whole set of assumptions to this particular problem.

Cheers Andy

I may be biased, but in my opinion, one of the most useful features of resource functions is the ability to easily save a function (including necessary dependent functions) for later use. For example, I just recently wrote this function AssociateToNested:

In[1]:= AssociateToNested[a, {"a", "b"} -> 1]
In[2]:= a
Out[2]= <|"a" -> <|"b" -> 1|>|>

In[3]:= AssociateToNested[a, {{"a", "c", "d"} -> f[x], "b" :> 1 + 1}]
In[4]:= a
Out[4]= <|"a" -> <|"b" -> 1, "c" -> <|"d" -> f[x]|>|>, "b" :> 1 + 1|>

I used to save my personal functions in an auto loading paclet on my machine, but these days I've found it to be much easier to just store them as resource functions. For example, this deploys it on my local machine:

In[5]:= LocalCache @ DefineResourceFunction @ AssociateToNested
Out[5]= LocalObject["file:///C:/Users/rhennigan/AppData/Roaming/Wolfram/Objects/49c7018f-75f7-4e51-b37b-ca75bced73bd"]

I didn't have to track down all the code I wrote in my notebook and copy and paste it into a separate package. The function is now usable any time on my machine automagically even after quitting the kernel:

In[6]:= Quit[]

In[1]:= ResourceFunction["AssociateToNested"][a, {"a", "b"} -> x]
In[2]:= a
Out[2]= <|"a" -> <|"b" -> x|>|>

Similarly, I can save functions to my cloud account with:

In[1]:= CloudDeploy[ DefineResourceFunction @ AssociateToNested, 
                     "ResourceFunctions/AssociateToNested",
                     Permissions -> "Public"
        ]

Out[1]= CloudObject["https://www.wolframcloud.com/obj/rhennigan/ResourceFunctions/AssociateToNested"]

Since I gave it public permissions, now anyone can access and use it with:

ResourceFunction["user:rhennigan/ResourceFunctions/AssociateToNested"]

I think some people might look at some of the well-documented functions on the public Wolfram Function Repository and think the process of creating a ResourceFunction might be a daunting task, but for your personal function deployments you don't need any documentation at all.

As a bonus example, one of the best resource functions ever created can't be found on the Wolfram Function Repository: https://www.wolframcloud.com/obj/rhennigan/DeployedResources/Function/BirdPeek

use Context[] to your best advantage. you don't have to be making a Package to use Contexts

Personally, I don't have a huge collection so i have a local package that loads Wolfram packages that i use in "the average full session", including a few of my own.

But I often "need a blank slate" - so unless i have two kernels two front ends I don't load anything. Also I am susceptible to power outage and forced reboots from automatic system updates. So I don't want the extra wait of loading libraries unless: I call out to use them.

Hi Richard, Thank you for your very detailed explanation. What you are proposing is very close to what I was looking for. However, I agree with Alan that the need to wrap my function in a ResourceFunction[] call adds to the cognitive overhead, i.e. I have to remember to treat one function differently from another. Having said that, I shall definitely experiment, because the overhead may prove to be insignificant.

By the way, I tried loading your published function, but couldn't get it to work. My input/output looks like the below. Am I doing something wrong?

In[202]:= ResourceFunction["user:rhennigan/ResourceFunctions/AssociateToNested"] Out[202]= AssociateToNested In[203]:= ResourceFunction["AssociateToNested"][a,{"a","b"}->x] During evaluation of In[203]:= ResourceAcquire::apierr: The specified resource could not be found. Out[203]= $Failed[a,{a,b}->x]

Hi David, Ah yes, clarification - always a good idea! The back story is that I decided to spend a year using MMA exclusively (as far as possible). I really want to understand what I can and can't do in the system. Or, perhaps to put it more accurately, what I should and shouldn't use it for. I am particularly interested in exploring how machine learning might change the way I solve problems.

So far, I have found myself using MMA in two distinct modes: 1) exploring a problem, for which the notebook is a good model 2) building small utility applications, which I will want to reuse in whole, or part.

Because I come from a purely Object Oriented background (Smalltalk), I find myself thinking of functions as if they were objects, and that leads me to want to create instances of functions, hence the need to understand how to save, and reuse, with the minimum effort.

I went back and reread your essay on how to structure applications, and I found that very useful. I am going to adopt that structure when building this little utilities and see if it helps. I think I will also try Alan's suggestion about capturing my functions in a notebook, and then evaluating it at the start of each project. If I understand correctly, that will allow me to access the functions without wrapping them in any other function call.

In addition to the above, I am going to try out the IDE experiments. I am not sure at what point, in the development of a solution, one switches from the notebook to the IDE. Time will tell.

Thank you to everyone who took the time to respond to my question. I think I have plenty to experiment with. I will update this thread, in a few months, when I have had a chance to try out the various options. Hopefully, the update will be useful for anyone stumbling across this question in the future.

Can you please submit to WFR a function that auto-converts f = ResourceFunction["f"] - I have hundreds in just my data toolkit - and resolves potential name-clashes? - The latter should be done on Wolfram's side, since they are in a position to view all definitions and can flag them.

Hi Micha, Many thanks for this. I shall enjoy digging into it

Cheers Andy