Communicating with StarLogo

["Miklos Gyorgy" <MIKLOS@ttt-atm.ttt.bme.hu>]

Hi!

Andy wrote:
> As for making the compiler figure out when you're doing this, I think it
> would take some effort. Right now, the compiler does enough checking to
> make StarLogo work. Adding additional type-checking might be a good
> project to work on. For me, I usually like fewer errors/warnings from the
> compiler, since I'd rather see my code run and fail than not run at all.


There may be a lot of different opinions on how much and what kind of
feedback StarLogo could/should give to the user. Here are my thoughts
about this.

I like to think of programming as a way of communication. And since the
communication goes between two "creatures" from two different "species",
that is, it's a human-machine interaction, it may give rise to a great
deal of misunderstanding on both sides.

As StarLogo is primarily a learning tool, its users are mainly
non-professional students. The experience is that the students who
don't have too much experience in programming tend to be frustrated
when after correcting all the syntax errors see that the computer
does not obey their wishes; they are not aware that even for an
experienced programmer debugging may take longer than coding.

So, after the first phase of communication through the medium of
StarLogo and the error/warning messages it sends back, usually the
second phase of debugging, modification and improvement begins.
(In fact, the two phases are usually mixed.)

Not much has been said about debugging in StarLogo so far,
that's why I have collected some hints for doing it; it may
be helpful especially for those new to programming and StarLogo:

-Print the important variables, either in the command center, or you can
create new monitors in the interface window.
-You can also set the variables by issuing commands during the run of the
program (or while the program is paused).
-You can use the *turtle monitors*. It's addition to SL2.0 has made
debugging much-much more flexible. There you can view or modify turtle
properties on the fly.
(For the symmetry, it would be nice to have patch monitors and an observer
monitor in future versions.)
-Often it is useful to insert commands that use colors to show whether
some critical events with turtles/patches have happened or not.
-You can temporarily convert forever buttons to once buttons and go
step by step.
-If you want to have a deeper look only at a certain phase of the program
execution, you can include special commands to release forever buttons
when certain conditions are met. (You may not have to modify anything for
it,
you can set up a new forever button which does this.)
-When locating an error, you can 'remark out' (put a ; in front of) the
unnecessary stuff and concentrate only on the heart of the matter.
-It may help to decrease the amount of randomness or eliminate it
altogether
while debugging. Then everything is deterministic which may be easier to
track.
-You may want to see special cases to your program which are well known.
This
may involve reducing the number of entities (turtles, patches), or setting
up a special configuration of turtles/patches by hand or by a small
procedure.


Despite all the hints that I tried to compile above, I don't know whether
other members of the StarLogo community would agree with me in that it is
generally somewhat more difficult to debug in StarLogo than in other
programming languages.
In serial languages, you can usually go step-by-step through all the
instructions and check to see if everything goes as it should.
In StarLogo, the smallest step that you make is usually a press of a
button on the interface window (which usually involves one procedure
call), or you can choose to issue the instructions one by one in the
command center. Even if you issue only one instruction, it may result
in hundreds of actions due to the parallel nature of StarLogo.
StarLogo is for experimentation with complex systems, but to some extent
it may also increase the complexity of debugging.

Normally in an engineering task, a big bug is a big problem, a small
bug is a small problem. If you build a house and it collapses, that's a
big problem. If the window is not perfectly beautiful, it's not.
In software development, however, it is often just the other way round.
If your computer collapses and explodes, or more seriously, your code
does not compile, or it compiles but does not function, that's a problem,
but you find the reason and correct it. If, however, there is a tiny
bug, such as an ill-formed expression, an unhandled branch, or an
overlooked automatic type conversion, that's a big problem because
you will not notice it: you think your program is functioning when it's
not. This is especially the case if you are dealing with simulations
which involve some calculations and randomness and you can't predict
the outcome. And in StarLogo we are usually in this domain and can't
predict the outcome, that's why we use our computers after all.

In view of this, my preferences are just the opposite to Andy's. I would
rather see my program fail at compile time or produce some warning
messages than have it running with the chance of having a
hard-to-detect bug in it. But it is easy to satisfy both tastes
by letting the amount and type of messages that the system sends
be customizable, as it is usually done.

In short, my feedback to the MIT folks developing StarLogo is that
StarLogo should provide as much feedback to the user as is possible
by giving 'intelligent' messages, and by giving warnings, suggestions
when something is suspicious. I know that this takes an extra effort,
but the result is well worth it. This is especially useful when we think
of StarLogo as a tool in education.

A way of doing this would be to figure out the most frequent
types of errors, misunderstandings, and make StarLogo a better
communicator in these cases. The starlogo-users list could make
some constructive contributions to this.

Here is a concrete suggestion to finish this rather theoretic letter:
would it be possible to provide the line number when there is an error?
Currently, only the procedure name is given. Sometimes it is obvious to
find the place of the error, but at other times you have to look for it
for some time. And the compiler has already done the search for us.

Cheers,
Gyorgy