Programming
20 Aug 2008 21:39
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]
See also: Computers; Abstract Computation; Math I Ought to Learn; Parallel and Distributed Programming; Christopher Alexander
- Recommended:
- 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
- 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 as postscript files]
- 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
- To read:
- 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
- Martin Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry
- 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]
- Gamma, Helm, Johnson and Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software
- Jon D. Harrop, OCaml for Scientists
- Ben Klemens, Modeling with Data [Book website, with free full-text draft]
- 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
- Phoenix Project at CMU [Compiling high-level language programs into distributed, asynchronous circuits]
- 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...]
- Mike Silver (ed.), Programming Cultures: Architecture, Art and Science in the Age of Software Development
- Steve Skiena, The Algorithm Design Manual
- Glynn Winskel, The Formal Semantics of Programming Languages: An Introduction
