Software Carpentry

Helping scientists make better software since 1997


Steve Eddins has posted an xUnit-style testing harness for MATLAB called MTEST on the MATLAB Central File Exchange.  It’s a nice piece of work, and I hope numerical programmers will make heavy use of it.

Written by Greg Wilson

2009/02/11 at 21:11

6 Responses

Subscribe to comments with RSS.

  1. Of course, a preferable path (in my view, and maybe yours) would be to get people hooked on NumPy + ipython + matplotlib, and, as it continues to mature, SciPy (all of which are making extensive use of nose).

    David Warde-Farley

    2009/02/12 at 01:58

  2. “””would take several thousand programmer-years to reproduce and verify the functionality of the core MATLAB toolboxes”””

    That’s a bit of FUD on your part.

    I don’t need most core toolboxes. For stuff like image processing (which is what I do), I don’t know of anything I could do in Matlab that I can’t do already in Python.


    2009/02/12 at 12:36

  3. I hope you didn’t take my comment above to be dismissive of the whole enterprise.

    I still appreciate knowing about this project. In fact, I am going to mention it in lecture today.

    In my “programming for scientists” class we are currently in the “software carpentry” module and we covered unit testing on Tuesday. I am focused on Python, but I always try to emphasise that the concepts have implementations in other languages.


    2009/02/12 at 15:28

  4. I’d argue that both top-to-bottom source code availability for scrutiny, as well as reducing financial barriers to entry, are reasons to prefer open source when doing science (personally I swore off MATLAB when our license server crashed over a Christmas break and I was unable to get any more work done for over a week because of it). There is obviously going to be incurred cost when doing scientific research (equipment, raw materials, etc.) and software can be a worthwhile investment, but the idea that I should have to pay for a MATLAB license in order to verify someone else’s analysis results (rather than reproduce their entire experiment) doesn’t sit well. (While the MATLAB toolboxes are a different kettle of fish from MATLAB proper, the ones that I’ve used were of variable quality, often poorly documented or containing implementations that were slower than ones I could write myself — thus, I’m not sure sticking with them because they already exist is necessarily a good strategy.)

    There are reasons that I’d say it’s better for the programmer, as well. MATLAB never having been designed as a general purpose programming language means that some relatively common operations are painful — string manipulation is one glaring example. One might respond that MATLAB’s strengths are in numerical problem solving, but this isn’t an excuse for its string handling deficiency: even splitting up systematically assigned filenames into their constituent parts in order to do some batch processing on an entire directory takes far more thought and code than it should (strtok? In 2009? Seriously?). There are definitely syntactic gains, even some specific to NumPy, where operator overloading has been used to great effect (e.g. broadcasting).

    David Warde-Farley

    2009/02/12 at 16:38

  5. […] response to comments on my post about MTEST that said, “People should use open source tools instead,” I can only reply, “If […]

Comments are closed.

%d bloggers like this: