That is such a good question. I have been using the program for a long time and I still have problems. For an example that I have had since 2005 i[t_?NumericQ] := 0.3*10^-9 UnitStep[10 [Tau] - t] UnitStep[t] What was he or she doing with this code line? I still cannot figure it out.

The demonstrations are wonderful, but to try to figure them out is a task. When I was a professor I never had trouble when my students tuned in FORTRAN programs even if they were not perfect. But if I was teaching today and they turned in a Mathematica demo. I would be climbing the walls. Maybe I am just too old now!

Hi Andy,

the relevant things are already said above. I just want to make a minor remark: One can easily write simple "help functions" to make complicated pieces of code more understandable, e.g.:

Attributes[makeObviousFrame] = 
  Attributes[makeObviousTree] = {HoldAllComplete};
makeObviousFrame[expr_] := Map[Framed, Inactivate[expr], {0, -2}];
makeObviousTree[expr_] := TreeForm[Inactive[expr]]

Putting these function in front of some "complicated" expression, e.g.:

makeObviousFrame @
 Flatten[mkArray1D /@ 
   Partition[
    Select[mccRaw, (NumberQ[#[[1]]] || 
        StringMatchQ[#[[1]], "INPLANE" ~~ ___]) &], 28], 1]
makeObviousTree @
 Flatten[mkArray1D /@ 
   Partition[
    Select[mccRaw, (NumberQ[#[[1]]] || 
        StringMatchQ[#[[1]], "INPLANE" ~~ ___]) &], 28], 1]

gives:

Maybe this is helpful.

Henrik

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 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

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

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.