A lisp macro virgin tells all





(defun accumulate (combiner lst initial)
(let ((accum initial))
(dolist (i lst)
(setf accum (funcall combiner accum i)))



* open parenthesis: `(`
* close parenthesis: `)`


* parenthesis for;
* function calls; `print(“hello”)`
* curly brackets for;





for x in range(100):
for y in range(100):
for z in range(100):
# do something to matrix[x,y,z]


for {x 100, y 100, z 100}:
# do something to matrix[x,y,z]


But now look at the lisp version;

I could, theoretically, write this

(domanytimes (x 100 y 100 z 100)


(dotimes (x 100)
(dotimes (y 100)
(dotimes (z 100)



# body here

and you’ll find you can’t.






(domanytimes (x 100 y 100) body)


(dotimes (x 100)
(domanytimes (y 100) body))

and then again to give you

(dotimes (x 100)
(dotimes (y 100)


(defmacro domanytimes (loop-list &body body)
(if (eq (length loop-list) 0)
;; we have our form to execute
`(progn ,@body)
;; we have more loops to arrange
(let ((fst (car loop-list))
(snd (cadr loop-list))
(rst (cddr loop-list)))
`(dotimes (,fst ,snd)
(domanytimes ,rst ,@body)))))

There. Wasn’t that fun? 😉



[perl]: http://www.perl.com/
[pcl]: http://gigamonkeys.com/book/

Five languages for talking about programs.

Only one of which is a computer programming language.

At work, we’re designing a new product. It’s a process that involves non-technical users, IT managers, programming colleagues, me, and the computer. It involves a lot of talking, a lot of language. At one end, it’s making sure the users are happy with the system’s capabilities. While talking to them, we use non-technical language, diagrams, and demonstrations. Way at the other, it’s actually typing code.

This makes me think it might be useful to split the languages we’re talking into four;

**User Langage:** Non-technical, example-laden, visual, and concrete. This is where you get into general discussions, produce photoshop mockups of the system, draw rough-and-ready whiteboard pictures, write XP user stories, write user manuals.

**Manager Language:** Your manager needs to know the technical and algorithmic overview, but he doesn’t need to see every class that’s going into the design. This language is the language of high-level functional specs, some UML diagrams, conceptual diagrams.

**Colleage Language:** At this level, you’re going to have to assure yourself that the code you write and the code your colleagues write start meshing together. Precision starts being important, and a real burden. Probably where most of the real thinking goes on. I think one of the reasons Pair Programming works is because it forces you to get into a lot more of these types of discussion, which reduces the possibility that the team’s work won’t gel together.

**Self Language:** This is the idiosyncratic, outboard-brain style of writing that you get into to make sure you understand what you need to be doing. This can be personal pseudocode, notes-to-self, todo lists, or code comments.

**Computer Language:** The code itself.

I think a great deal of the actual design and thinking involved in creating new products goes on above the level of the computer language. When people discuss, say, “Python Vs Java” or “Ruby vs Lisp”, it’s valuable enough, but the choice of language probably isn’t that important in determining the success of the project. I think these language strata go some way to explaining why. Most of the communication goes on between people.

Modifying large codebases in dynamic and static languages

I’ve been wondering recently about dynamic languages, and static languages, and the relative benefits.

I’m struggling with this question because I write C#3 by day, and am learning python in the evenings. I’m only writing small python scripts at the moment and I’d like to write larger pieces, but I’m concerned about how easy it’ll be to make certain types of change.

For example. You’ve got 100,000 lines of code. You also have a logging function that’s looks like this;

void Log(string message)

And it’s called about 200 times in your code. You decide you need a severity; so you change the signature to

void Log(string message, LoggingSeverity severity) { .. }

Now, how long does it take to find all the calls to the Log() function that need to be updated? Under C#, about ten seconds. Once every call has been fixed, the code is almost certain to work correctly.

Consider, on the other hand, the python function

def log(message):

What happens if you change the signature to

def log(message, severity):

There is no way to tell where the log message is called. You’ve just introduced 200 bugs.

It’s made even worse by duck typing; maybe you have two loggers — a deployment logger which writes to a database, and a test logger which writes to stdout. You update the database logger so it has severity. Your tests continue to pass, but your deployed system will fail.

So it seems to me that static languages give you much more power to make changes to large codebases. I’d love to know if, and where, the mistakes are in my thinking.