I’ve become fascinated by Second Life scripting, and I think I’m getting fairly good at it. This blog isn’t intended so much as an introduction to scripting, as an exploration of how to do scripting well. There are some introductory articles as well. I hope you find all of them helpful.
Introductions to LSL Concepts
This section contains articles introducing the ideas and statements used in Linden Scripting Language.
An introductory article on events, probably the most unique aspect of Linden Scripting Language, and one of the most important.
An introduction to states, another unique and important aspect of LSL.
This article on comments is also a nice little discussion of states, another unusual and important aspect of Linden Scripting Language.
Style in Scripting
I’ve been lucky enough to have some good teachers, who tried to pound some good ideas about programming as communication into my head. I’ve been trying to apply those ideas here in Second Life, and I’ll write about what I’ve learned.
Many of these ideas will seem strange to people who have been programming for a while. Maybe they are strange. Still, I find them very useful, and people who have read my scripts say that they are very easy to understand and to change. So … read, think, and maybe give these ideas a try. I’ll be interested to hear what you experience if you try them.
I have been taught to make my code say what I mean. This is called “Programming by Intention” or “Intentional Programming”. Give it a look: I think you’ll find it interesting and maybe even useful.
Working on the Piano of Damocles, I find a problem and while fixing it, improve the code a bit. This article presages the much longer series on refactoring.
Let’s face it, we put comments into our programs because they’re not easy to understand. Can we make them easier to understand so as to need fewer comments?
It often happens that after we let a program rest for a while, we can see ways to do better. It’s worth doing because it makes the program better, and it prepares us to do better work next time.
I’d like to grow up to be a craftsperson in scripting. So I pay attention to how things go, and try to learn lessons from it. Here are the lessons so far:
Too much pressure makes bad things happen.
Second Life makes it very hard to collaborate. Centralize changes with a single person?
As we change code rapidly, especially as a team, we need to save our changes consistently.
It’s hard to write small modules in Linden Scripting Language, but it pays off.
We really need a way to work together on code sometimes. It’s hard in SL. Pastebin is one way.
Refactoring is a process of improving the design of a script by making small reversible changes. To be certain that we don’t make a mistake and break the program, we need to use tests, called “characterization tests”. I’ve written a long series of articles on a refactoring example.
I start out innocently enough, with a large working program of Dizzi’s, that animates the legs of a horse by making different prims visible and invisible. The first thing to do is understand the script a bit, then start writing tests.
Here I talk a little bit about the approach I’ll take, which is to work in very small steps and always be willing to step back if something doesn’t look good. Then I add more tests to be sure I don’t break something.
I thought I’d get to improving the code in this article but as we talked about it, you and I, I realized that I was about to change something without tests protecting me. So I invent a new test and make it work. I’m writing these little blurbs after completing the series, so I happen to know that we’ll decide to change this test way down in article nine. Can you see why?
Here, I start to improve the code. As I often do, I look for duplication of code, which usually offers a change to make things more compact and therefore, usually, better.
In this article, I discover that the original code isn’t quite consistent. Sometimes it makes new leg positions visible and then makes the others invisible, and sometimes the other way around. I decide to make the new version consistent, and adjust the tests accordingly.
I discover in this article that one of my tests is wrong and so the code is wrong as well. In addition, we’ve encountered a new situation in the original code, where it turns off more things than it turns on. We improve the tests and make the code perform this new function.
The script is now using the new “changeVisibility” idea, and I begin to look for a way to put in the idea of a “leg” abstraction. It turns out that I find a leg position abstraction, which looks pretty nice.
With the leg position idea in the code, I try a change that will reduce all the constant definitions at the front of the program. It doesn’t make the code better, and I back it out. Lesson learned? Nothing profound. Try little things, and if we don’t like them, undo them. When changes are small, we don’t mind learning that way.
The series is done as far as I’m concerned, and I summarize key ideas: tests, tiny steps, removing duplication, improving clarity.
Arrgh! Dizzi, in reviewing what was done, decides that it’s better to make the new leg position visible first, and then make the old one invisible. When I resolved the inconsistency in the original, I went the other way! Now we have to change everything!
This change really was a surprise to me: I thought I was done. How hard was it? Well, if refactoring improved the code, it should be easier than it would have been. Take a look!