The demonstrations code isn't good code to start with. I would have found it overwhelming and confusing when I started. I always recommend going through the virtual book and reading documentation examples.

You're right that it's very easy to make dense unreadable code in practically any lisp like language. Some of the coding styles I've seen used in the demonstrations are very difficult to piece together.

I find well written Wolfram Language code easy to read. More so than even, say, Python. But badly written code is always hard to read.

I don't know of any tools like you describe existing in any language. I'm not sure how it would know how to unbundle and un-nest the functions in a way that made it readable. Ideally, well written code is like that anyway.

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

Hi Andy,

yes, it definitely has a huge potential! But one has to pay a price in terms of effort. When I started learning Mathematica only three years ago, we had version 8 and there the Virtual Book was very explicit to find. And the best and fastest way to get familiar with WL is to work through the capter "Core Language" entirely. I do not understand why something that useful as this Virtual Book is now in V10 so completely hidden - you will not find it unless you know that there is one.

Debugging is in my opinion not that a big problem, because it is an interpreter language after all. And there the notebook environment is helpful, e.g. the possibility of double/triple/multiple clicks to make whole expressions visible - very simple, but effective!

But anyway - you made a top decision! I use MMA every day and I am sort of addicted!

Henrik

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 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 David, That is very helpful indeed. I like the idea of building up the function in a notebook, and then collapsing it into code.

It is interesting that you use mapping the function on a file as the example. Because, I was trying to do exactly that yesterday. In my case, I had a collection of pdf files that had been encoded in Base64 as part of a mime message. I needed to turn them base into binary pdfs. The good news is that I got it to work, and the WL expressions were incredibly simple, and powerful.

The bad part was that there was something wrong with the input file format, and it seemed to be quite difficult to get Mathematica to show me the contents of what it was trying to import. I am sure there is a way to dump the value of the Import expression, but this was an example of where I needed to understand debugging in more detail.

In the end, tackled the problem in Smalltalk, and spotted the problem easily, because Smalltalk has such excellent inspection capabilities. I need to find the equivalent capabilities in WL. But, in the meantime, I will definitely adopt your approach.

Cheers