Written 26 January, 2009
Pretty Code
My first computer was a Commodore VIC-20. At $299, buying it took every penny I had. For several months I didn’t have $75 to buy a cassette or even $29.95 to buy a Space Invaders cartridge. I had only a keyboard, 3853 bytes of RAM, and an owner’s manual.
In retrospect, that was a good thing, for the owner’s manual included a most excellent tutorial in BASIC, the VIC’s built-in programming language. If I’d had Space Invaders I would probably never have cracked the cover.
But five minutes after I first turned on the computer, I had written my first program: 10 PRINT “Hi, Chey.” Thirty seconds later I had added a line that sent the program into a loop.
Five minutes after that my landlord was knocking on my door.
“Do you have any idea why my TV screen is showing your name over and over?”
Woopsie! Time to re-rig the video connection!
My first BASIC programs used a lot of GOTO statements; these caused the program to jump to a specified line. Then I discovered GOSUB, which sent the program to execute a subroutine and then return. Big improvement!
As I grew more proficient in BASIC, as I learned to use arrays and define functions, my programs grew more elegant (and often shorter). When I looked over my earlier attempts, I would wince. I grew proud of my code.
I’m reaching that point with LSL. I made a breakthrough when I figured out how to use listens and sensors, and another when I figured out how to do loops, and another when I learned how to manipulate lists. I’m anticipating a fourth breakthrough when I can finally read a notecard, and a fifth when I can reliably read from and send data to external databases.
Pretty code serves only two purposes: it helps others understand just what the programmer has done (which of course they can’t do when you sell them your product with a locked-up No Mod / No Copy script), and it gratifies the programmer’s ego. And yes, the script may consume less memory and require fewer system resources, but pretty code is written mostly just to write pretty code.
But here’s the deal: all that is really required of a script is that it work and work reliably. How you got the script to that point may be important to YOU, but it otherwise doesn’t matter. The important thing is the door opens each and every time you touch it, the texture changer swaps images every 15 seconds, the lamp turns on and off on command.
So take heart, all you people trying, like me to figure out LSL. If the code compiles and the prim behaves appropriately, you’ve succeeded—no matter the state of your code.
Pretty Code
My first computer was a Commodore VIC-20. At $299, buying it took every penny I had. For several months I didn’t have $75 to buy a cassette or even $29.95 to buy a Space Invaders cartridge. I had only a keyboard, 3853 bytes of RAM, and an owner’s manual.
In retrospect, that was a good thing, for the owner’s manual included a most excellent tutorial in BASIC, the VIC’s built-in programming language. If I’d had Space Invaders I would probably never have cracked the cover.
But five minutes after I first turned on the computer, I had written my first program: 10 PRINT “Hi, Chey.” Thirty seconds later I had added a line that sent the program into a loop.
Five minutes after that my landlord was knocking on my door.
“Do you have any idea why my TV screen is showing your name over and over?”
Woopsie! Time to re-rig the video connection!
My first BASIC programs used a lot of GOTO statements; these caused the program to jump to a specified line. Then I discovered GOSUB, which sent the program to execute a subroutine and then return. Big improvement!
As I grew more proficient in BASIC, as I learned to use arrays and define functions, my programs grew more elegant (and often shorter). When I looked over my earlier attempts, I would wince. I grew proud of my code.
I’m reaching that point with LSL. I made a breakthrough when I figured out how to use listens and sensors, and another when I figured out how to do loops, and another when I learned how to manipulate lists. I’m anticipating a fourth breakthrough when I can finally read a notecard, and a fifth when I can reliably read from and send data to external databases.
Pretty code serves only two purposes: it helps others understand just what the programmer has done (which of course they can’t do when you sell them your product with a locked-up No Mod / No Copy script), and it gratifies the programmer’s ego. And yes, the script may consume less memory and require fewer system resources, but pretty code is written mostly just to write pretty code.
But here’s the deal: all that is really required of a script is that it work and work reliably. How you got the script to that point may be important to YOU, but it otherwise doesn’t matter. The important thing is the door opens each and every time you touch it, the texture changer swaps images every 15 seconds, the lamp turns on and off on command.
So take heart, all you people trying, like me to figure out LSL. If the code compiles and the prim behaves appropriately, you’ve succeeded—no matter the state of your code.
3 comments:
In a professional setting in so-called RL, pretty code is generally a good idea since it will likely be maintained by more than one person. But in SL, I agree, if your object does what it needs to do without barfing errors or orbiting you, it doesn't matter how you accomplished it. You win!
The thing is that after enough time, others includes you. It's a lot easier to remember what you did if the code is pretty (and well-commented--which isn't the same thing as verbosely commented).
Whatcha, I can totally understand the importance of structured coding in business and other cooperate enterprises where code is passed from person to person. I wasn't even thinking about commercial applications. I can imagine the confusing if a new worker had to take over a code block that say powered the Manhattan phone grid and found things all amess!
You're right, Melissa, coming back to a script a year after you wrote it can be disorienting. Proper commenting can go a long way toward making things understandable.
In my case my early efforts are so straightforward it's not difficult to figure out what I did when I revisit. What's harder is figuring out WTF I was thinking!
Post a Comment