[SciPy-user] Matlab, Scipy and teaching science

[Robert Kern]

Peter Bowyer wrote:

> My idea was to teach the basics using Python and scientific 
> modules.  However, the question I am consistently coming up against 
> is "Why not teach the students Matlab?".  It's a very good point and 
> one I can think up no clear answer for.  If the students stay in 
> Physics or a related field they will be using Matlab (and 
> C/C++/Fortran if needed).  Therefore is there any reason not to teach 
> Matlab as the introduction to programming?
> 
> My arguments at present are that Matlab is a proprietary tool so the 
> cost to students in obtaining copies will be not inconsiderable 
> (considering it will only be used for a short course), and that 
> Matlab is a specialised tool, so those not interested in going on 
> into a physics related field will not find it of any use (unlike Python).

[I should state before I begin that I have nothing but the deepest
resentment and animosity towards Matlab.]

Matlab cripples scientists who learn it as their first introduction to
"real" programming. They continue to do *everything* in Matlab even when
Matlab is the most hideously wrong tool to use because they've learned
Matlab and using any other language would mean spending the effort to
learn the new language. When they are convinced to learn another
language, it's usually a low-level language so they can write faster
code. But then they only write that low-level code as interfaces to
Matlab so they can continue to do high-level things relatively easily.

Unfortunately, the real benefits that a high-level language ought to
provide are largely absent from Matlab. You can't really do any serious
modularization of your code. Data flows all over the place. If I have to
work with somebody else's Matlab code and it's more than a page long, I
just throw it away and rewrite it in Python from scratch. Maybe I'll
pick out some snippets here and there for guidance, but as a whole, the
Matlab code is worthless *for communicating ideas*. When you're a
research scientist, your code is only partially about getting the right
answer. It's also very important that other people can understand what
the code is doing and can build on your code.

And don't get me started on using taxpayer-funded grants to develop
research code that requires ludicrously expensive proprietary software
to run.

As you say, they might have to learn Matlab anyways to deal with other
researcher's code, but if you get them started right with Python, they
won't be contributing to the problem.

> The arguments for Matlab are stronger:
> 1) It's a standard tool, widely used

Undeservedly so.

> 2) It is easier to install and maintain

And comparison in this regard ought to include the management of
Matlab's floating license BS. Ease of installation and maintenance
doesn't mean anything when you can't run it because too many other
people on your campus are currently using it.

> (discounting the Enthought 
> edition for a moment, Python is CRAP compared with other langauges - 
> where is the Package manager to make life easier?)

We're working on it.

  http://peak.telecommunity.com/DevCenter/EasyInstall

Also, any number of Linux distributions have fairly complete collections
of Python packages integrated with their own package manager.

At the recent SciPy '05 conference, Aric Hagberg told me that he ran a
student summer program at LANL where they had to make a choice between
purchasing Matlab licenses for a few dozen students or using Python. Of
course they used Python. To help with the installation issue, they built
a Linux LiveCD with all of the relevant software already installed. The
students could just pop the CD into their computer and boot into a nice
Linux environment that was known to work. Since all of the software on
the CD was open source, the students could take that environment with
them when they left the program.

> 3) The editor has a good interface (v7 and above) which IDLE lacks 
> (no data inspector 'right there')

IDLE isn't the only editor/IDE for Python.

> 4) Integrated help for all the scientific functions

We have fairly good docstring coverage in scipy at least. We need to
build some searching capability, though.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter