Some comments on "attitude" and "culture". One of the greatest influences on me have been the books on data graphics by Edward Tufte. It is one reason I believe in writing literate notebooks with textual explanations and multiple and carefully designed presentations. Tufte writes: " Those who discover an explanation are often those who construct its representation." Mathematica gives you plenty of tools for constructing representations and exploring their behavior.

And why textual explanation? Because if you can't give a simple clear explanation it should leave you a bit skeptical as to your level of understanding. The same goes for documentation of a routine. If it's difficult to document maybe it should be redesigned or scrapped for some other routine. Textual explanation and documentation are not onerous chores, they are part of the learning or creative process.

I tend to eschew the terms "code" and "programming" in favor of terms such as "writing definitions, axioms, rules and specifications". After all, we're trying to do math and science. WRI can hire the programmers. It's a matter of attitude and culture.

Lots of people in academia write papers and even books as part of the process of better learning the material. Do you think they always knew it all before they started? So even if it's self-study, writing literate notebooks is good practice. And they might very well be good enough to interest other people. The same applies to having students write literate notebooks, even if they are relatively short. When they're finished they actually have something to show off. Science and technology are no good if they can't be communicated.

Also, if students can design new and clear presentations along with explanations, they are not only learning but they are adding value because these do not always exist together now.

And thanks to Luther for starting this discussion.

If results had error bars, and regression analyses showed the correlation coefficient, a lot of what passes for "knowledge" in Sociology, psychology, and medicine would be seen as being very tenuous at best.

I think that this is a major cultural problem. No one gets through Physics 1 or any decent engineering course without learning that any measurement that lacks an estimate of error is useless. I used to work for a clinical lab, and the entire notion knowing what the error bars for a result were was antithetical to the thinking both of the management of the company and the clients.

As I recall, Tufte does discuss error, and I believe that there is a section where he shows radically different sets of data give identical least squares fits. However, this is not the main thrust of his discussion, as you point out.

This whole topic is overdue for a treatment that can be understood by people who just want to use software, and not have a deep understanding of numerical analysis. I'm pretty sure that Mathematica is a good tool to use for this.

The quintessential example that comes to mind for me is the Fleischmann–Pons claim of cold fusion.

http://en.wikipedia.org/wiki/Cold_fusion

Dusty trails indeed, and in my case, of the handful of engineering companies I've worked for, if I wasn't the only Mathematica user, there may have been 2 or 3 others that let it collect, you guessed it . . . dust. For some reason Matlab/Simulink dominates the engineering world and Mathematica is more popular in science, education and maybe finance. One area of computation that is bound to continue to explode is medical research. I wonder if Mathematica played a role in cracking the human genome.

Macsyma over a 300 baud modem pre-dates me somewhat but nice job in catching that error. I do remember running test cases with it from my CRC Standard Math Tables handbook and having much difficulty interpreting the results that Macsyma produced on my bulky, heat producing Cathode Ray Tube. Of course Mathematica has FullSimplify and similar commands to push results into a more human readable form.

On the topic of supportive learning materials in the 90's I subscribed to Mathematica in Education and Research put out by Telos/Springer. I found this journal to be highly readable and useful as I don't have advanced degrees. It was full of plots, images and code. Thinking back, I learned quite a bit from that little journal as it was very practical in nature.

Does anyone know if this or similar journal is still in print ? I'm aware of the Mathematica Journal, but I've found that to be too theoretical and advanced for my needs.

That was possibly a bug, so to speak, in the CRC reference at the time. It did not really account for choices of roots used, at least in the quartic formula. This may also have been an issue with the cubic. This was stuff I had to work through in 1992.

"Just playing with Mathematica is a good strategy for staying young"

I tried that Craig and it doesn't work! Running very very fast might work in a relative sense.

More accurately, playing with Mathematica is a good strategy for maximizing the use of your time.

Clearly, that is something I have to start doing.

I had heard of it as a Planck quote, but I have also heard that it was a quote of a quote. It is like Newton's standing on the shoulders of giants. I think that is a quote of a quote, too. The more modern version of Planck's quote is about progress or acceptance occurring one funeral at a time. Planck's quote was kinder and about acceptance occurring through the younger generation being more familiar with whatever is new and novel and having grown up with it. I am always reminded of the idea of continental drift and how hard it was for the geologists of not so long ago to get their heads around the idea despite the circumstantial evidence. Alvarez's asteroid extinction hypothesis is still being tested...as it should be.

I can understand the push back if it were something truly novel, but in my case it was a redo using more advanced techniques available through Mathematica. The approach was simply a re-reading of something and realizing there was a disconnect between what was said and what was actually done. I am of the opinion that everything should be periodically revisited in light of newer findings, insights, and techniques.

When I started my career, I was performing contract R&D and we were selling applied physics and technology. I remember plowing though the journals to get ideas for applications, since I knew what my customers' problem areas were from a technology perspective. If something was novel, I tested it for applicability to various applications. Got some things so wrong, but got some very right, too. It was a fun time to get into the technology business.

The times were different. We took chances. Even a dumb idea might have a nugget of goodness buried somewhere inside.

Good points and I plead guilty to the leakage observation. I was in the "business" at one time and have seen a variety of cultures at work. My knee jerk was a recollection of the times I was burned as a "customer". Within software developers is an undercurrent of certainty that they know best or, as with many technical people, they come across a better way of doing things while working on some project...so they shift gears without letting anyone know. This is the bane of project managers.

I recall meeting a past graduate school colleague at a conference. He had set up a company that was successful and one of its lines of business was developing specialized scientific analysis software for the DoD in the areas of spectroscopy. We chatted and he discovered I was associating with the same types of customers and developers as he was, so he asked me my opinion on what it would take to commercialize his products for a wider audience. One of my own staff had developed a different type of specialized analysis software and we were wrestling with the same question: how to expand the market for that intellectual property. I had no answer for my friend or myself. Some fifteen or so years later, the software my group had developed did show up as a commercial product developed independently elsewhere, and their secret was the user interfaces and easy of use, which our intellectual property never possessed....nor did we have the capacity to address that issue. Plus, the market for the new product had never occurred to us.

Mathematica's documentation is as good as it has to be for Wolfram not to suffer any commercial consequences. Wolfram is blessed by an outstanding product and a user community that is so smart that it overcome the deficiencies in the documentation...plus, to be crass about it, Wolfram sells support services. I think where Wolfram may be somewhat short sighted is that such issues as are being raised in this thread indicates that they could promote a ground swell of broader acceptance and use by "commoditizing" their product. This is just the businessman in me speaking. I would reject the idea of a slimmed down or crippled version just to get a cheaper product out, but too many bells and hidden whistles is pretty frustrating in any product. As an example, I just bought a new phone that uses Android and I tried to set up my voice mail account. I had to go on-line to find someone to tell me where the set up was hidden and it was definitely hidden. The documentation did not even address voice mail but it supplied overkill (from my perspective) in the areas of applications and data.

Mathematica is what it is and from a commercial perspective, Wolfram is doing what it needs to do to stay on top of their game...they have a business strategy that does not depend on better transparent documentation. Mathematica is the best mousetrap around from my perspective. Could it be better? Probably, but define better.

I concur with your assessments and those of Park based on a more general exposure to technologists with particular preferences. I started with a blank slate in terms of exposure and preferences, since I had avoided programming at any level after my early pre-PC experiences with Fortran and Basic and more punch cards than any one graduate student should have to carry. I was never required to do much programming, starting with my first job at Michigan (we used a Wang with punch cards!!!) to Battelle, where I was fortunate to manage a talented group of scientists and technologists who loved programming. Now as I close in on my dotage, I am on my own.

I had to find a muscular program to work out some problems that had never been properly solved because all work on those problems stopped a hundred years ago. A reading of a basic paper showed that the author had not actually done what he said he was going to do and did something else because there were no tools like Mathematica available then.The author did what he could. I reread the paper and identified an asyllogistic conclusion and set out to test the author's methodology. I got results that contradicted the text books. However, I did not know if the fault was mine (mis-interpretation or mis-statement of the real problem) or whether the issue was Mathematica (again, was it my use of mathematica or something within Mathematica), or were the results true? So, after research that led to no resolution on any of the points, I asked.

The results of my consulting with several faculty were disappointing. Other than criticizing Mathematica and my methodology, I simply could not get anyone to actually read the statement of the problem as originally presented nor my interpretation and subsequent modeling using Mathematica. I had expected push back but not total out of hand rejection of my thesis, and the criticism of Mathematica seemed to be a way out for actually having to address the issues and possible consequences that the problem presented. I am, at this point, working down the list of criticism eliminate them. Hard slog.

Hello Danny and Luther, That makes three of us who started with punch cards.

A bizarre as it might seem, I think punch cards were a beneficial way to learn to program. I spent so much more time thinking about the program and doing thoughtful debugging because submission of a job was so painful. I confess that I often do debugging now with less reflective thought because I can do dozens of haphazard experiments in minutes--this probably speeds the debugging process as often as it slows it down.

I was sold on symbolic computation (pre-wolfram-language) when I was able to solve classical mechanics homeworks faster and more accurately than my classmates. I remember that just being able to do a taylor expansion around a point and copy down the results and redraw crt-rendered plots into my homework felt like cheating.

I also remember my own "inertia" of switching from "symbolic-program-x" which was free at Berkeley (and had opaque syntax that I had learned moderately well) to Mathematica 1.

Craig