Dear Andy,

How are you today? Here's the notebook I promised you a couple of weeks ago. Let me know if you have any questions.

Cheers, Micah

Attachments:

WolframLanguage_...nb

You could just do:

 AssociateToNested = ResourceFunction["AssociateToNested"];

And then it is 1st-class in your view (-:

Hi Andy,

First you should become reasonably familiar with Mathematica. The best way to do this is to read the 'Introduction for Programmers' and 'An Elementary Introduction to the Wolfram Language'. by Stephen Wolfram, both available at the bottom of the Main Documentation page in Help. You may already have read these.

Mathematica is not Smalltalk or any other computer language. I think it pretty much transcends these other languages and it's not too useful to try to convert it to one of them. The time you might spend in doing that is lost to learning concepts and methods of machine learning.

I don't know why you should get immersed in an IDE. (Except possibly Workbench - but only for the purpose of documentation.) An external IDE is not Mathematica. It has nothing to do with Mathematica. In a very practical sense Mathematica is its own IDE. All the time you spend learning an IDE is time not spent on studying machine learning.

You don't need an IDE for debugging. Just put temporary Print statements in your code (usually inside a Module) to display intermediate results. I've found that always gets me to the problem and the solution.

I've been using Mathematica since 1996, just before Version 3 came out. I wrote most of the code and did much of the design of a Tensorial application (with Renan Cabrera), and a UnitsHelper package. And wrote and sold hundreds of copies of a Presentations package that started out just the way you are accumulating routines. I've been working for some time on a quite large Grassmann Algebra/Calculus application with John Browne. So my essay advice came from quite a bit of experience.

Package routines often grow out of notebook work. I put a Routines Section at the top of the notebook (also known as Package Purgatory) and put initial routines there. I always include a usage statement, a SyntaxInformation statement, and the routine itself. (Sometimes there are also Options, Attributes and error messages.) I make the routine an Initialization cell and use it for a while in the notebook. Then only after testing and using the routine for some time do I copy it into a package file (package Heaven). A package file in appearance is very much like a regular notebook. It can have Section headers and Text cells as well as the Initialization cells for the code. The entire process is easy and smooth. And the result meshes with the normal use of Mathematica.

Hi John, Could you explain a little more about how I use Context[]. I looked at the help, but it wasn't obvious to me how I would set things up to load my utility functions.

Thanks Andy

Andy, I think you've started a very interesting and useful discussion.

However, I think good answers depend a lot on what your objective was in turning to Mathematica in the first place. Mathematica is a nice application to use for many reasons - but I just wonder what your specific reason is?

Long function names are preferred to short for exactly this reason.

You can dump and restore all Your kernel expressions to file to "quickly" restore a session having "all your stuff ready". here's how to do one expression only:

x>>filename;  (* see Put and moreso DumpSave[] in Help *)
y<<filename;

So you don't have to store them all. If you did you'd use a library system (library science is a college course).

Back to long names: you may need to replace some names and get a compatibility problem. the answer is to use fully long names and append more to the name if there is a compatibility problem.

You should avoid using nick names and short names because you'll run into naming collisions or forget what the nick names are in some years.

Long names are best.

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

Hi Paco, I am definitely going to explore that option. I certainly like the idea of being able to instantly access any functions I have created. Out of curiosity, is there a simple way to list the functions? I realise I am trying to convert MMA into Smalltalk! but it would be useful to have some sort of function browser. I am sure my list of functions will grow over time. Actually, is there a way to add them to the help system? Perhaps that would be useful too.

By the way, for the future reference of anyone reading this thread, the menu that Paco is referencing is not in the Mathematica program, but rather in a notebook that one downloads from WFR - it took me a little while to work that out.

Cheers Andy

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!

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

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.

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

Thanks Mark, I had never heard of WorkBench. I will go and take a look.

Cheers Andy