Shut up and program!

This is an update to “Shut up and calculate!” (which was posted here three weeks ago, 2008-08-12).

Many thanks to the readers who have suggested programming languages or environments for inquisitive computing. There are a dozen or so recommendations in the comments to the earlier post, and I’ve received even more by private correspondence. Here is a summary of the suggestions, in no particular order. (Numbers in parentheses indicate the number of times each system was mentioned.)

R (2). The open-source version of the S language for statistics. (Also accessible through Sage.)
Sage (1). Open-source mathematical software.
Haskell (2). Lazy functional programming language.
Python (2). Scripting and programming language.
MATLAB (2) and Mathematica (1). $$$ mathematical software.
Programmable calculators (3). The specific machines mentioned were the HP-15C, the TI-83 and the TI-V200.
Yorick (1). An open-source scripting language that emphasizes scientific computation.
Octave (2). Open-source mathematics software similar to MATLAB.
SuperCollider (1). Language for audio and music synthesis.
Fathom and Tinkerplots (1). Data-analysis and graphics software from Key Curriculum Press.
DERIVE (1).Successor to muMath; now discontinued.
Excel and other spreadsheets (2).
APL (1), C (1), Forth (2), Fortran (2). Old favorites.
UBASIC (1). BASIC with bignums and rationals; last release seems to be 1998; MS-DOS only.
Scala (1). Recent open-source language that uses Java runtime facilities or .NET.
“Roll your own” (2). Two readers politely suggested that if I think I know how a programming environment ought to work, then I ought to build one myself.

I’m impressed and surprised by the wide spectrum of responses. It’s not just that there were so many different answers but also that they come from some very distant corners of the computing universe. Several of the systems mentioned are new to me, and I plan to give them a look.

From all of the above it appears that we have some happy campers out there—people who have found programming tools that suit their needs. Others share at least some aspects of my discontent. But given the vastly differing preferences expressed here, it seems unlikely that any one solution could please everyone.

This entry was posted in computing.

win.by.switch <- 0 win.by.stick <- 0 for(replicate in 1:1e6) { prize <- floor(runif(1) * 3 + 1) pick <- floor(runif(1) * 3 + 1) if(pick == prize) { win.by.stick <- win.by.stick + 1 } else { win.by.switch <- win.by.switch + 1 } } win.by.stick win.by.switch

8 Responses to Shut up and program!

Darius Bacon says:

5 September 2008 at 2:52 am

http://github.com/darius/halp/ is an Emacs frontend for Python I just wrote that I like a lot already for exploratory programming — people have said it’s sort of like a Mathematica notebook (I can’t tell, not having Mathematica).

(I didn’t post it three weeks ago because it barely existed then. Perhaps it’s still too crude to mention.)
dave birnbaum says:

5 September 2008 at 2:34 pm

I’ve used Matlab and Octave is a free, open-source, equivalent that is mostly compatible. It can even load most Matlab M files. It’s available for Windows, Mac and Linux.

R is also a free alternative. It’s biggest disadvantage is its focus on statistical analysis but otherwise is an excellent program.

There’s also SciLab (French website) that is similar. Also free.

One issue with these programs is their focus on matrix/vector formulation. This is an advantage in making matrix or vector computation look simple but does require some rethinking of how one organizes one’s data. But worth the effort.

Personally, I use C and (more and more rarely) FORTRAN to do numerical work. Especially with things like Numerical Recipes available it’s easy to assemble a main program and calls to a few subroutines to do many quick problems like simple Monte Carlos. I did the Monte Hall problem in about 20 minutes when it first came out to “prove” it to our lunch group of physics PhD’s. Especially for more computationally intense problems the speed difference between a compiled language and the interpreted ones is significant.
bearophile says:

6 September 2008 at 7:33 am

Instead of using C I suggest the D language. The performance profile is similar (often about as fast, sometimes two times slower) it’s much nicer to program with, and it helps you avoid lot of bugs. Later, once your program runs, if you see that you need the last bit of extra performance, you can translate it to C usually without too much problems.
Peter Petto says:

7 September 2008 at 7:23 am

Although I’m busy at the moment preparing lesson plans for school this week and don’t want to get to far off track (I was reading blogs to stimulate my brain, really.)

I wanted to mention a programming language that has been very helpful to me. I’ll comment more about it in the future. It’s called J and is the latest incarnation of APL — it’s known as a matrix-oriented language (it is) and it’s also quite functional.

It’s worth a look, at http://www.jsoftware.com .
John S. says:

7 September 2008 at 12:15 pm

I was one of the two who mentioned R, but seeing david birnbaum’s reply above. I remembered that when I wanted to demonstrate the correct Monty Hall strategy to my colleagues, I did it on an Excel spreadsheet.

And now I am a bit surprised that no one mentioned Excel. It’s certainly not the ideal platform for inquisitive computing, and it costs a lot of money, but in my line of work (engineering) everybody has a copy and knows how to use it. The spreadsheet itself is versatile enough, but if you know how to use the Basic interpreter you can do almost anything. Over the years I’ve used it quite a lot, to get answers to all kinds of problems.
John S. says:

7 September 2008 at 12:15 pm

And now I see you mentioned Excel. Never mind ….
david birnbaum says:

10 September 2008 at 1:18 pm

Excel can certainly be useful. If the expense is a factor consider OpenOffice.Org which is a free, open-source equivalent to MS Office. If has a spreadsheet with a substantial fraction of Excel’s capabilities and it can read Excel files.
Mark Myatt says:

11 September 2008 at 1:00 pm
Arrogantly suggesting a way to extend this thread … The “Monty Hall” problem seems to have been suggested as a yardstick. It might be interesting to see how the favoured environments / languages handle this problem.

I have coded the problem in R using ‘procedural’ code and ‘vectorised’ code with a million replicates. My ‘procedural’ version is:
```
  win.by.switch <- 0
  win.by.stick <- 0
  for(replicate in 1:1e6)
    {
    prize <- floor(runif(1) * 3 + 1)
    pick <- floor(runif(1) * 3 + 1)
    if(pick == prize) {
      win.by.stick <- win.by.stick + 1 
      } else {
      win.by.switch <- win.by.switch + 1
      }
    }
win.by.stick
win.by.switch
```
This gives:
```
  > win.by.stick
  [1] 333675
  > win.by.switch
  [1] 666325
```
After running for about 18.6 seconds.

My ‘vectorised’ version is:
```
  prize <- floor(runif(1e6) * 3 + 1)
  pick <- floor(runif(1e6) * 3 + 1)
  table(ifelse(pick == prize, "STICK", "SWITCH"))
```
This gives:
```
   STICK SWITCH 
  333339 666661 
```
After running for 1.9 seconds.

The ‘vectorised’ version could be condensed to a one-liner:
```
 table(ifelse(floor(runif(1e6) * 3 + 1) == floor(runif(1e6) * 3 + 1), "STICK", "SWITCH"))
```
This gives:
```
  STICK SWITCH 
  332902 667098 
```
After running for about 1.6 seconds but the code is far from self-documenting.

I apologise in advance if this is a stupid suggestion. Feel free to gloat if I have misunderstood the “Monty Hall” problem …. that would put me in some esteemed company.