Archive for the 'Programming' CategoryPage 3 of 3

Perlis Quote

It is easier to write an incorrect program than understand a correct one.
Alan J. Perlis

Too true.

Of couse, understanding an incorrect program is harder than understanding a correct one. I think that says something about the relative difficulty of debugging versus programming.

Lisp

So I’ve begun to learn Lisp, and I’ve been quite pleased by the abundance of free (as in beer) resources.

The full-texts to the books Practical Common Lisp and On-Lisp (by Peter Seibel and Paul Graham, respectively) are available on the web.

You can also take MIT’s 6.001 course online. This is an introductory CS class which is based on the legendary text Structure and Interpretation of Computer Programs. The SICP site contains the full-text of the book, sample programming assignments, and a complete set of videotaped lectures for the course (text, lectures).

The internet is freaking amazing. 10 years ago, my less-than-stellar grades precluded any possiblity of ever viewing an MIT lecture.

(SICP lectures found via LtU)

Update: There’s a much more complete list of freely available Lisp resources here.

(Thanks again, LtU)

Pop Count

Larry Osterman recently blogged about some various methods for computing the population count (or pop count) of a machine word. For the uninitiated, pop count is the canonical name for the function which counts the number of asserted bits in a binary number. Larry’s blog entry was excellent, as usual, but it was of the comments that blew me away. Jeu George added a link to his blog describing the MIT HAKMEM pop count. Here it is:


unsigned popCount( unsigned x )
{
   unsigned r = x - ((x >> 1) & 033333333333)
                  - ((x >> 2) & 011111111111);
   return ((r + (r >> 3)) & 030707070707) % 63;
}

I spent hours figuring out how it worked.

Continue reading ‘Pop Count’

A Trend Towards Run-Time

The essence of JIT is that it defers a substantial portion of compile-time to run-time. In a JIT scenario, we generate machine code just-in-time to execute it.

Now consider “scripting” languages like Perl, Python, Ruby, etc. These guys don’t even bother parsing ahead of time. My 2+ GHz processor hardly breaks a sweat.

OK lets review:

  1. Programming is hard
  2. Good design is difficult
  3. Optimization sucks
  4. Processor cycles are free

Clearly, if I can spend processor cycles to make programming easier, it’s worth it.

So why am I blathering on about this? Well, I thought there was nothing left for us to usefully push into run-time. I was wrong: we can still combine edit-time and run-time. Check out the Subtext programming language and this cool demo.




Creative Commons Attribution-NonCommercial 3.0 United States
Creative Commons Attribution-NonCommercial 3.0 United States