Subject:
|
Re: Robolab as a tool for teaching programming
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 16 Mar 2005 23:34:08 GMT
|
Viewed:
|
3978 times
|
| |
| |
In lugnet.robotics, Steve Hassenplug wrote:
|
1) I think flowcharting is a good skill to have as a programmer.
2) I dont think a programming language should teach flowcharting
|
I would agree, but it was you who said Programming with Robolab is much like
creating a flow-chart and if you really want to know where spaghetti code
comes from, we should talk to those who think flow-charting is a waste of time
here: http://news.lugnet.com/robotics/?n=23581
It was from these statements that I got the impression, perhaps mistaken, that
people here were arguing that Robolab helps teach kids the good programming
skill of flowcharting. My contention is that because of the significant
departure in Robolab from standard flowcharting techniques the end result of
what kids learn from using Robolab is a bad set of flowcharting skills.
Interested readers can see my other posts for additional details.
|
3) I think someone who can create a flowchart could program in Robolab
better/faster/easier than they could program in NQC.
|
I dont think pre-existing flowcharting skills will benefit a Robolab newcomer
because the only substantial commonality is the drawing of lines between boxes.
In flowcharting, however, these lines are always directional and the flow can be
(and usually is) in any direction. The rules of flowcharting are consistently
broken in Robolab. Anyone interested can consult Google for information about
good flowcharting skills and compare that information to the images of many
sample Robolab programs on the official Robolab website to see where the two
bodies of knowledge diverge in non-trivial ways. In other words, to learn
Robolab coming from a standard flowcharting world you will have to forget much
of what you know and do things that were formerly forbidden in order to write
nearly all non-trivial Robolab programs.
On the other hand, pre-existing flowcharting skills will benefit an NQC newcomer
in exactly the same way that they will benefit any person learning a traditional
programming language. The flow of logic, decision making, and procedural steps
that would be familiar to a person experienced with flowcharting will translate
directly to programming in traditional text-based languages such as NQC. And
they can use their skills exactly as they learned them to design, code, and test
their NQC programs.
|
It has (A) a loop that doesnt use a jump icon, instead, it uses a while
type structure and (B) it shows how comments can be added to the code,
pretty much by creating a text-box whereever you want.
|
While the loop Tom shows appears in his example to be something like a while
loop it isnt substantially different (as far as I can tell) from the jump (up
arrow) and land (down arrow) Ive been discussing thus far. Its graphic is
certainly different and it takes an itty bitty numeric parameter to indicate how
many times it should do whatever it does. And I think the associated end of the
loop has to be down stream unlike the jump/land combinations. But as with the
jump/land combination there is no direct association (that I can see) between
the two icons aside from their color (or, Im guessing, an optional attached
number indicating the label number). There is no clear indication (involving
lines connecting two icons) that suggests to a new user that when you reach the
icon with this particular image your program will return back to that other icon
with that other particular image. A line with an arrow indicating the direction
of logic flow would make the connection clear. As it is you need to unlearn
your flowcharting skills and learn this new (and somewhat peculiar) Robolab
skill.
Try to nest two of these loop thingies, as you might two for loops in NQC:
for(i=0; i<4; i++)
{
PlaySound(SOUND_DOWN);
Wait(100);
for(j=0; j<5; j++)
{
PlaySound(SOUND_CLICK);
Wait(100);
}
}
My guess is that if you can nest them at all (I cant tell from the examples
Ive seen) you probably can only tell the end of the inner loop from the end of
the outer loop by its color.
The text box comment is certainly a nice feature, but it seems to me that
attempting to use such a technique to comment your code in any meaningful way
would quickly make it hard to view the program itself surrounded as it would
become by little white boxes containing text that are associated with a portion
of the program solely by their proximity.
|
That doesnt allow you to #define values or labels, but it does provide a way
to describe in depth what the values may represent.
|
I suppose. Id quibble with in depth. And then Id argue that Robolabs use
of slightly different line styles to differentiate between program logic flow
and attached bits of required information is fraught with peril.
This
, this
, this
, and this
for example. A tool that encourages or requires these sorts of interconnected
messes is not one I would recommend for use in teaching kids how to program.
|
|
NQC provides numerous modern
higher-level programming constructs that help new programmers develop good
programming habits and skills.
|
Do you know which of these constructs are (or are not) provided by Mindscript?
|
Id say that MindScript is certainly equal to NQC in this regard. It has issues
of its own, for sure, but none that I would seriously argue against.
|
Ive not seen anything in the rules that says you cant use BricxCC. But,
ScriptEd seems to work fine for writing code.
|
My understanding from the two years I coached a team (and asked the question) is
that BricxCC is not allowed since it is not a LEGO-provided tool. I could be
wrong. Using ScriptEd to write MindScript compared to using BricxCC to write
MindScript is like driving a Yugo compared to driving a Lamborghini. I wouldnt
ask a kid to use ScriptEd unless I thought they deserved serious punishment.
|
|
To account for that you
would need to additionally check the value of redflag prior to the check of
AmbientTemp or Message().
|
How would adding a redflag check change the results?
|
In this situation the end result is identical but it involves executing code
needlessly, and therefore, a slower robot. The logic of the OR I presented in
NQC code would never actually check AmbientTemp or read the IR Message source if
the first part were true (i.e., your redflag was already equal to 1). If you
wanted to accurately represent the NQC code using a technique like you presented
then to be exact it would not check AmbientTemp or check the IR Message if
redflag were already set to 1. Thats all I meant.
To do it exactly like NQC youd need to write your Robolab program so that it
acts like the LASM code seen here:
chk 2, 50, 0, 9, 1, t0000019
chk 2, 4, 0, 0, 47, t0000033
t0000019:
chk 2, 31, 1, 9, 0, t0000033
chk 2, 13, 2, 15, 0, t0000043
t0000033:
plays 1
wait 2, 200
plays 2
jmp t0000049
t0000043:
wait 2, 400
plays 0
t0000049:
Whether that is possible or not given the icons available in Robolab, I dont
know.
Im also wondering how you might do the two items shown below in Robolab:
PlaySound(SOUND_DOUBLE_BEEP);
/*
#ifdef __SPY
Wait(200);
#else
Wait(100);
#endif
*/
PlaySound(SOUND_DOWN);
In other words, can you draw compile-time code differences into your Robolab
program and can you temporarily comment out portions of the code without
having to extricate them from the existing sequence of connected boxes?
John Hansen
|
|
Message has 2 Replies: | | Re: Robolab as a tool for teaching programming
|
| On Wed, March 16, 2005 6:34 pm, John Hansen said: (...) ... (...) wow. I guess I don't have a reply to that. My wife (not a programmer) has used Robolab. She said it was like making a flowchart. I assume you're suggesting Robolab has no flow of (...) (20 years ago, 17-Mar-05, to lugnet.robotics)
| | | Re: Robolab as a tool for teaching programming
|
| John, You make some good points regarding Robolab but I'll confess at the outset here that I'm a big fan of Robolab. After having used Robolab with my FLL teams the past two years I can say that it is a powerful tool that works well for teaching (...) (20 years ago, 17-Mar-05, to lugnet.robotics, FTX)
|
Message is in Reply To:
| | Re: Robolab as a tool for teaching programming
|
| On Wed, March 16, 2005 11:01 am, John Hansen said: (...) My only reason for commenting was that this has been used as an argument before. You've done a nice job of conveying the fact that you're willing to consider that other languages may be (...) (20 years ago, 16-Mar-05, to lugnet.robotics)
|
114 Messages in This Thread: (Inline display suppressed due to large size. Click Dots below to view.)
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
Active threads in Robotics
|
|
|
|