3 ms·
Beauty is in the eye (and hand) of great programmers
Digging through my (paper) library the other night I came across the listing (on green-bar, fan-fold) of the implementation of a LISP system written around 1967. I used it quite a bit back in the day. It is implemented in old-school FORTRAN. By old-school, I mean a FORTRAN that only had computed IF statements, as in
IF (X) 3,4,5
which means
if x<0 then goto 3
if x=0 then goto 4
if x>0 then goto 5
This is a listing of a punched-card deck. Columns 73-80 are sequentially numbered so that, if you dropped your card deck, you could sort the cards by those columns. The increment per-line is 100 so the numbers are 00000100, 00000200, 00000300, etc. This allows new cards to be put in between existing cards while maintaining the sort sequence, e.g. 00000150.
This program is a work of beauty. Many of the statements have numeric labels so they can be reached by GOTO or computed IF statements. This programmer chose the label numbers so they are in ascending order (so you know where to look for a jump target). They are 4 digit labels where the left-most digit is the main task (e.g. handle recursive function calling), the next digit is a subtask within the main task, etc.
The FORTRAN function names mirror the intended LISP names, e.g. CAR, CDR, etc. so it is clear to a LISP programmer what the semantics will be. The call stack is named STACK, etc.
Every grouping has a comment line (character in column 1), e.g.
C EVALUATE THE FUNCTION
I am typing in the source code so I can share it with the LISP history site. Something this beautiful deserves to be preserved. This programmer is an artist.
Read source code. You can tell how good a programmer is just by looking.
- greenyoda 6y ago> They are 4 digit labels where the left-most digit is the main task (e.g. handle recursive function calling), the next digit is a subtask within the main task, etc. Even old-school FORTRAN (FORTRAN II) had SUBROUTINEs and FUNCTIONs for breaking down a program into smaller pieces. So there doesn't seem to have been a need to have a monolithic main program that's organized into subtasks using only statement labels and GOTOs. Still, I agree that old code can be beautiful.
- daly 6y agoThe computer systems running this LISP code had 4k of memory. There are a few subroutines (e.g. APUSH, FPUSH, CAR, CDR, etc.) but the inner loop looks pretty much like a tightly coded state machine. I suspect most of the FORTRAN statements will compile to single instructions (on some architectures). FORTRAN level subroutine/function calls would use a stack and chew up memory. My PDP-8/f System was a small machine with a paper tape reader/punch on the teletype. Running the multi-pass FORTRAN compiler, linker, and library code paper tapes (including intermediate tapes) could take all day. I usually just hand-patched the final binary paper tape (using a small plastic holder and a 1-hole punch). The fact that I could run LISP and interact "on the fly" was an amazing advance. Later, when I worked for Unimation trying to computer-control industrial robots I got a Data General NOVA. Unfortunately I didn't have a FORTRAN compiler. All the robot work was done in hex machine code. Oh, if I only had a LISP!
- giantg2 6y agoIf you read my source code, you'll say I'm the programmer equivalent of a Yugo (car).
- draw_down 6y agoPersonally I don’t care about beautiful code or “good programmers”. I care about making something helpful and useful, maintaining it over time, taking users’ feedback to make it better. Writing fancy looking code is so much easier than all that stuff, it’s academic really. I can't tell you how much I would rather write a bunch of code than conduct user research, or read the feedback to see where we need to improve. Because coding is so much easier than doing those things. But doing those things is more valuable, because the value is in the artifact, the thing that the code is in service of. Beauty, or any other value, in the actual code itself is inert, it's dead. It has no worth unless it solves a problem for someone, or is instructive for a coder who's learning how to solve a problem for someone. The exception to what I'm saying is that the code must be legible, people need to read it and understand what it does. But that is not beauty; beauty is an aesthetic proposition, legibility is a utilitarian proposition. Longer, more verbose code is better than "elegant" concise code, if the longer code is easier to understand.