Programming

I've been programming since I was about ten --- that was on a delapidated TRS-80 Model I, with 16k RAM, which someone had donated to my school. It had no storage device (or maybe we just didn't have any disks?), so we wrote BASIC programs that could fit into our own memory. I remember being very proud to get it to plot quadratic functions.

I can handle BASIC. I've acquired some skill at Fortran, at any rate Fortran 90. (Heck, I wrote a genetic algorithm in it once.) I fell in love with LISP when I took freshman CS at Cal. I've even worked in assembly on, may the gods have mercy, a Commodore 64. But.

I'm learning C. I have delayed doing so as long as possible; now I have to deal with a simulation program which will only save its results in Windows bitmap graphics files. As initiation rites go, I think I'd prefer tattooing without anæsthesia. Malloc is evil. So is the distinction between "=", which is the assignment operator, and "==", which is the equality operator, said distinction having just cost me an evening. I have no words to express my feelings about things like "%=". C is, quite literally, taking over my mind: I very distinctly remember a dream last week which was about cooking but in C. [10 March 1996; the dreams went away.]

I've actually developed a great deal of affection for C (doubtless this is what the psychologists call "effort justification," also known as the sunk cost fallacy), and for instance now do all my numerical coding in it. I am however having to learn C++, which is such a silly instance of object orientation that I almost believe the joke about how it was invented to keep programmers in business indefinitely. On the other hand, I've also been learning Perl and Expect, and they are pure delights; in both cases I was writing useful programs within an hour of opening the manual. Expect in particular is wonderful for making Unix do things for you, and for hiding a physicist's idea of a user interface. --- Probably not the least reason for my affection for C is having to write control code for a fairly complicated and undocumented piece of hardware in Forth... [24 June 1998]

Learning a little Java was instructive. Now Jean-Baptiste Rouquier, who's my student for the summer, has persuaded me that I need to learn Caml. Unfortunately, there's no O'Reilly Caml in a Nutshell handbook (perhaps because it'd cause too much confusion with Programming Perl), just the 400-page manual. [2 July 2004]

Abelson and Sussman, Structure and Interpretation of Computer Programs [2nd edition on-line. Somebody please tell me why I sold my copy?]
Timothy Budd, Understanding Object-Oriented Programming with Java
Cormen, Leiserson, Rivest and Stein, Introduction to Algorithms
Jutta Degener, Programming in C page
Brian W. Kernighan and Dennis M. Ritchie, The C Programming Language
Don Libes, Exploring Expect and the Expect Home Page
Steve Oualline
- Practical C Programming
- Practical C++ Programming
William H. Press, Saul A. Teukolsky, William T. Vetterling, and Brian P. Flannery, Numerical Recipes in C and Numerical Recipes in Fortran [2nd editions of both are on-line]
Randal L. Schwartz Learning Perl
Peter Seebach, comp.lang.c Infrequently Asked Questions
David Touretzky, Common LISP: A Gentle Introduction to Symbolic Computation [On-line]
Larry Wall and Randal Schwartz, Programming Perl

Gregory R. Andrews, Foundations of Multithreaded, Parallel, and Distributed Programming
Beck, Extreme Programming Explained [A friend who actually does software development for a (partial) living raves about this]
Nathaniel Borenstein, Programming as if People Mattered: Friendly Programs, Software Engineering, and Other Noble Delusions
Brookes, The Mythical Man-Month
Martin Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry
John M. Chambers, Software for Data Analysis: Programming with R
Mathias Felleisen et al., How to Design Programs: An Introduction to Programming and Computing [blurb]
Frantisek Franek, Memory as a Programming Concept in C and C++ ["Most professional programmers learn about [the role of memory] entirely through actual experience of the problems it causes"... Blurb]
Ben Fry, Visualizing Data
Gamma, Helm, Johnson and Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software
Jon D. Harrop, OCaml for Scientists
Daniel Jackson, Software Abstractions: Logic, Language, and Analysis [blurb]
Brian W. Kernighan and Rob Pike, The Practice of Programming
Ben Klemens, Modeling with Data [Blurb, ch. 1; author's book site]
Donald E. Knuth, The Art of Computer Programming [Review by Danny Yee, not that it needs one...]
Hans P. Langtangen, Python Scripting for Computational Science
Xavier Leroy (et cie), The Objective Caml System [Online in a plethora of formats]
Lutz and Ascher, Learning Python
David Mertz, Text Processing in Python [Review by Danny Yee; full text free online in ASCII.]
Suley Oliveira and David E. Stewart, Writing Scientific Software: A Guide to Good Style [Blurb]
John Ousterhout, Tcl and the Tk Toolkit
Mark Pilgrim, Dive Into Python [Full text free online, but I bought the hardcopy anyway once I really started reading --- publishers take note.]
Chris Raistrick et al., Model Driven Architecture with Executable UML [Blurb. If I understand this even close to correctly, this is something like compiling an abstract model specification into executable code, which would be cool. Of course I'd have to learn UML first...]
Casey Reas and Ben Fry, Processing: A Programming Handbook for Visual Designers and Artists
Mike Silver (ed.), Programming Cultures: Architecture, Art and Science in the Age of Software Development
Steve Skiena, The Algorithm Design Manual
R. D. Tennent, Specifying Software: A Hands-on Introduction [Blurb]
Greg Wilson, Beautiful Code: Leading Programmers Explain How They Think
Glynn Winskel, The Formal Semantics of Programming Languages: An Introduction

Notebooks

Programming