Thanks Sean, that's very helpful indeed.

You mention a virtual book, but I not quite sure what you mean. I have found this page

http://reference.wolfram.com/language/?source=nav

is that what you meant? Or, is there an actual 'learn the wolfram language' book?

Cheers Andy

That is just what I needed!

Thanks so much. I was struggling to understand the whole system, but this book gives me exactly the on-ramp I need.

Right, off to write my first WL programs!

Cheers Andy

I just want to second the above.

In general, displays of data, especially as in data-driven programming, make Mathematica code much easier to read and understand.

-- Mark

Thanks Henrik, That is really helpful. I particularly like the tree layout, I think the way it demonstrates the branching structure is very useful indeed.

For anyone else who comes across this question in the future. I have a few observations: 1. The virtual book is very helpful indeed. I think it would pay Wolfram to make it more visible to new users. The one thing that is rather strange about it is that the navigation is not linear. In other words, you can't always step through the book page by page. Sometimes you have to backtrack to a section description to get to the next section. No doubt it made sense to the designers, but I am finding it breaks up the reading flow.

1. It takes a while to learn the terminology used within the system. I think this is a bigger barrier for me than for some others. I do most of my programming in Smalltalk. When I first came across Entities I - unconsciously - interpreted them as 'objects', and that meant I brought a whole collection of assumptions with me. It has taken a while to escape from that construct. I am still not quite sure how to thing about Entities, but I now see them more as a bundle of arrays, with some accessing methods.

2. There seems to be an idiomatic style to writing Wolfram Language programs. I think it is really important to let go of other style experience and try to embody this style, otherwise I feel I am going to be fighting the system to try to make it conform to my view of how it should work.

3. Debugging is a pain! I would love for someone to show me the best way of debugging, and I do understand that by building up the code from very small functions, debugging is much less of an issue. However, the fact that I can't easily inspect, values really throws me off. Hopefully, someone will enlighten me to the true way :-)

I am really enjoying learning the system, and I can see that it has huge potential.

I can't claim to know the best way of debugging, but here is how I approach developing code.

Mathematica (WL) uses a functional paradigm. Generally, I try to keep things readable and testable by keeping functions simple, and calling functions from functions to build up complexity.

However, there are times when that doesn't work - particularly when I need a complex function to map onto a list. A good example is a function to process data in a file, when I want to process many files, or a new file at intervals. In this case, I start out developing the function as a section of a notebook that performs the import and analysis on a single file using a sequence of separate cells. I will take a sample file name and assign it to a variable called "file." Then in the next cell I'll Import "file" assigning the import to "raw." Then in successive cells I'll format the data as needed, do any required analyses, export data as needed, make plots and export them as needed, or just format the data into an expression I want as the output of the function. I can see the results and correct any errors as I go along. When I'm happy, I'll usually save the notebook as a development book. But then I will delete all output from the sequence of cells and terminate each with a semicolon. I place a cell with the opening for Module at the top, including the list of internal variables as used in the cells below. I use "file_" as the argument since I used "file" as the file name. If necessary, I add a cell at the end with the output I want from the function, and merge the cells into what is now a single cell which defines the function using the Module. In writing the initial cells, I use (* *) comments for documentation rather than formatted cells, anticipating that they need to be within a single cell when finished.

I find this generally produces functions which work. If I later get an error, perhaps due to unanticipated input, I try first to troubleshoot with embedded print statements or an altered final expression. (Like we did oh so many years ago.) If that fails, I load the development notebook with the inline cells version of the function and feed that the input that is causing the problem.

Best regards,

David