Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Notice: We are no longer accepting new posts, but the forums will continue to be readable.

Topic: Mathematica and Lisp
Replies: 83   Last Post: Mar 5, 2013 10:12 PM

 Messages: [ Previous | Next ]
 Murray Eisenberg Posts: 2,105 Registered: 12/6/04
Re: Mathematica and Lisp
Posted: Jan 16, 2013 1:39 AM

On Jan 14, 2013, at 11:31 PM, David Bailey <dave@removedbailey.co.uk.math.umass.edu> wrote:

> I do tend to agree that teaching Mathematica as a first programming
> language, would be a bad idea, because so much happens behind the scene
> - for example the way in which multiple definitions for a function get
> reordered to improve efficiency. I would imagine that some students
> would get a hazy idea of what the were asking the computer to do, or how
> expensive it might be.

It all depends on just what you want somebody to accomplish when learning his/her first programming language.

I've thought about that a lot over the some 30 years that I taught FORTRAN, Pascal, APL, J, and Mathematica in university math courses. (My very first programming language was Assembly for a Univac I, followed shortly by octal-coded machine instructions for a paper-tape input computer, and then FORTRAN II -- all while I was an undergraduate. A decade later, BASIC, APL, Pascal; subsequently, J and Mathematica. Even later, a smattering of C, Perl, Python, Java. I've even dabbled a tiny bit with Forth and Snobol.)

So what is essential for a first exposure to programming? To me, the essentials are:

(0) Understanding carefully what the problem is, including what is given and what is to be found.

(1) Identifying the objects (data) and what is to be done with them (operations, functions, procedures).

(2) Breaking up a larger problem into its constituent parts.

(3) Isolating the big ideas from the smaller technical points.

(4) Expressing things within the constraints of a precise syntax.

(5) Suitably modularizing the code in accordance with (2) and (3).

(6) Making the code readable through judicious choice of names along with sufficient but non-redundant comments.

(7) Making the code maintainable -- by the original author or others.

(8) Being able to test and debug the code.

(9) For numerical work, understanding and coping with roundoff and other errors due to the limitations of finite precision.

(10) Recognizing when and knowing how to code an operation repetitively -- whether explicitly (iteratively or recursively) or implicitly (functionally).

(11) Recognizing when and knowing how to express conditionals (whether via an explicit If, Which, etc., or instead as is possible in Mathematica, separate definitions of the same function for different cases).

Must the first-language learner get closer what s/he is "asking the computer to do" than might be the case with Mathematica? If so, how should you reasonably decide how deep to descend? (If you don't know what the ultimate actual binary code is, how could you know what the computer is _actually_ doing?)

My experience, in fact, is that the higher the language level -- such as that possible with Mathematica or APL or J -- then the easier it is to master these essentials. All too often I have seen students unable to ascend to effective programming with a higher-level language if their minds were rotted by the first exposure being to too low-level a language. (And that is despite my personal learning path that ascended from the ridiculous to the sublime.)

---
Murray Eisenberg murray@math.umass.edu
Mathematics & Statistics Dept.
Lederle Graduate Research Tower phone 413 549-1020 (H)
University of Massachusetts 413 545-2838 (W)
710 North Pleasant Street fax 413 545-1801
Amherst, MA 01003-9305

Date Subject Author
1/11/13 amzoti
1/12/13 Richard Fateman
1/12/13 David Bailey
1/14/13 Richard Fateman
1/14/13 David Bailey
1/16/13 Richard Fateman
1/18/13 David Bailey
1/22/13 Richard Fateman
1/22/13 David Bailey
1/24/13 Richard Fateman
1/25/13 Richard Fateman
1/26/13 Murray Eisenberg
1/26/13 Murray Eisenberg
1/26/13 W. Craig Carter
1/16/13 Murray Eisenberg
1/16/13 Richard Fateman
1/16/13 David Bailey
1/18/13 Murray Eisenberg
1/31/13 Noqsi
2/2/13 Daniel Lichtblau
2/3/13 Richard Fateman
2/2/13 Richard Fateman
2/3/13 David Bailey
2/5/13 Richard Fateman
2/6/13 David Bailey
2/6/13 Richard Fateman
2/3/13 Andrzej Kozlowski
2/5/13 Richard Fateman
2/6/13 David Bailey
2/5/13 Bill Rowe
2/6/13 Joseph Gwinn
2/3/13 Matthias Bode
2/3/13 Noqsi
2/6/13 Richard Fateman
2/6/13 David Bailey
2/6/13 mathgroup
2/4/13 Alex Krasnov
2/6/13 Noqsi
2/8/13 Richard Fateman
2/9/13 János Löbb
2/9/13 Richard Fateman
2/10/13 michael
2/10/13 Bill Rowe
2/8/13 Andrzej Kozlowski
2/8/13 Noqsi
2/9/13 Richard Fateman
2/10/13 David Bailey
2/9/13 Matthias Bode
2/15/13 Noqsi
2/17/13 David Bailey
2/18/13 Joseph Gwinn
2/18/13 David Park
2/22/13 Richard Fateman
2/23/13 David Bailey
2/23/13 Richard Fateman
2/25/13 David Bailey
2/26/13 Richard Fateman
2/27/13 Bill Rowe
2/27/13 Richard Fateman
3/2/13 Bill Rowe
3/3/13 Richard Fateman
3/3/13 Noqsi
3/5/13 Richard Fateman
3/5/13 Vince Virgilio
3/3/13 Bob Hanlon
1/16/13 Noqsi
1/16/13 Richard Fateman
1/18/13 Noqsi
2/23/13 Dr. Peter Klamser
2/25/13 Richard Fateman
2/26/13 Noqsi