Friday, July 24, 2020

You Can Create Art & Beauty On a Computer

Samson's music program was an example. But to hackers, the art of the program did not reside in the pleasing sounds emanating from the on-line speaker. The code of the program held a beauty of its own. (Samson, though, was particularly obscure in refusing to add comments to his source code explaining what he was doing at a given time. One well-distributed program Samson wrote went on for hundreds of assembly language instructions, with only one comment beside an instruction which contained the number 1750. The comment was RIPJSB, and people racked their brains about its meaning until someone figured out that 1750 was the year Bach died, and that Samson had written an abbreviation for Rest In Peace Johann Sebastian Bach.)
A certain esthetic of programming style had emerged. Because of the limited memory space of the TX-0 (a handicap that extended to all computers of that era), hackers came to deeply appreciate innovative techniques which allowed programs to do complicated tasks with very few instructions. The shorter a program was, the more space you had left for other programs, and the faster a program ran. Sometimes when you didn't need speed or space much, and you weren't thinking about art and beauty, you'd hack together an ugly program, attacking the problem with "brute force" methods. "Well, we can do this by adding twenty numbers," Samson might say to himself, "and it's quicker to write instructions to do that than to think out a loop in the beginning and the end to do the same job in seven or eight instructions." But the latter program might be admired by fellow hackers, and some programs were bummed to the fewest lines so artfully that the author's peers would look at it and almost melt with awe.
Sometimes program bumming became competitive, a macho contest to prove oneself so much in command of the system that one could recognize elegant shortcuts to shave off an instruction or two, or, better yet, rethink the whole problem and devise a new algorithm which would save a whole block of instructions. (An algorithm is a specific procedure which one can apply to solve a complex computer problem; it is sort of a mathematical skeleton key.) This could most emphatically be done by approaching the problem from an offbeat angle that no one had ever thought of before but that in retrospect made total sense. There was definitely an artistic impulse residing in those who could utilize this genius-from-Mars techniques black-magic, visionary quality which enabled them to discard the stale outlook of the best minds on earth and come up with a totally unexpected new algorithm.
This happened with the decimal print routine program. This was a subroutines program within a program that you could sometimes integrate into many different programs—to translate binary numbers that the computer gave you into regular decimal numbers. In Saunders' words, this problem became the "pawn's ass of programming—if you could write a decimal print routine which worked you knew enough about the computer to call yourself a programmer of sorts." And if you wrote a GREAT decimal print routine, you might be able to call yourself a hacker. More than a competition, the ultimate bumming of the decimal print routine became a sort of hacker Holy Grail.
Various versions of decimal print routines had been around for some months. If you were being deliberately stupid about it, or if you were a genuine moron—an out-and-out "loser"—it might take you a hundred instructions to get the computer to convert machine language to decimal. But any hacker worth his salt could do it in less, and finally, by taking the best of the programs, bumming an instruction here and there, the routine was diminished to about fifty instructions.
After that, things got serious. People would work for hours, seeking a way to do the same thing in fewer lines of code. It became more than a competition; it was a quest. For all the effort expended, no one seemed to be able to crack the fifty-line barrier. The question arose whether it was even possible to do it in less. Was there a point beyond which a program could not be bummed?
Among the people puzzling with this dilemma was a fellow named Jenson, a tall, silent hacker from Maine who would sit quietly in the Kluge Room and scribble on printouts with the calm demeanor of a backwoodsman whittling. Jenson was always looking for ways to compress his programs in time and space—his code was a completely bizarre sequence of intermingled Boolean and arithmetic functions, often causing several different computations to occur in different sections of the same eighteen-bit "word." Amazing things, magical stunts.
Before Jenson, there had been general agreement that the only logical algorithm for a decimal print routine would have the machine repeatedly subtracting, using a table of the powers of ten to keep the numbers in proper digital columns. Jenson somehow figured that a powers-of-ten table wasn't necessary; he came up with an algorithm that was able to convert the digits in a reverse order but, by some digital sleight of hand, print them out in the proper order. There was a complex mathematical justification to it that was clear to the other hackers only when they saw Jenson's program posted on a bulletin board, his way of telling them that he had taken the decimal print routine to its limit. FORTY-SIX INSTRUCTIONS. People would stare at the code and their jaws would drop. Marge Saunders remembers the hackers being unusually quiet for days afterward.
"We knew that was the end of it," Bob Saunders later said. "That was Nirvana."

Source: Hackers, Heroes of the Computer Revolution, by Steven Levy
(C)1984 by Steven Levy
  • rss
  • Del.icio.us
  • Digg
  • Twitter
  • StumbleUpon
  • Reddit
  • Share this on Technorati
  • Post this to Myspace
  • Share this on Blinklist
  • Submit this to DesignFloat

0 comments:

Post a Comment