Subject:
|
Re: Robolab's string
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 18 Mar 2005 09:24:16 GMT
|
Viewed:
|
1957 times
|
| |
|
|
In lugnet.robotics, John Hansen wrote:
| |
As mentioned elsewhere I could be wrong about Robolab. But absent any
informative correction from the Robolab experts listening in I am left to my
own devices to make heads or tails of what Robolab is teaching our children.
And the more I examine the information I have access to regarding Robolab the
more puzzled I get. Perhaps someone can enlighten me. Take, for example,
the Robolab program below:
Here we have a simple Robolab program. There are lines (string) connecting
the various icons together. I’m thinking to myself, what do these lines
represent? Is it logic flow? I can see how that might be, in spite of the
lack of arrow heads indicating direction. I can make the leap that suggests
the procedural flow is always toward the stop light. But there are two pink
lines that puzzle me if the lines represent the flow of logic. One is
directly after the green up arrow and the other is directly after the red up
arrow.
In no case can the flow of logic in this program flow past an up arrow to the
icon beyond it. So what does that line mean? Why is it there? It is a
mystery. Can anyone help me understand why in Robolab you draw a line out of
an up arrow (jump icon) to the next icon in the sequence of icons leading
toward the stop light? If the lines represent logic flow then the only line
coming out of an up arrow icon would be a line connecting that icon directly
to its pair (the down arrow of the same color). Any other lines coming out
of an up arrow icon seem as if they would suggest something entirely and
completely false. Looking at the picture it would seem like the program logic
could flow through the green up arrow to the merge icon and then to the red
up arrow icon and finally to the green down arrow icon.
Thanks!
John Hansen
|
John,
the program you are proposing for discussion is a good example for bad
programming practise, you are absolutely right. I think Dijkstra was the first
to insist to banish GOTOs from well structured programming. This was one of the
things I didn’t like too much, when we started with ROBOLAB. Besides some rare
exceptions I won’t tolerate such a program in my classes and ask the kids to
learn a cleaner way, avoiding jumps and lands. However, since ROBOLAB doesn’t
know any WHILE TRUE or otherwise denominated “forever” loop, we admit that they
may use the arrows for that purpose.
Another weak point of ROBOLAB is that there is no valuable case management
(switch). This lack blows up graphical code with succesive if forks.
What we’ve learned with ROBOLAB programming is that there should be some
conventions for the kids to respect :
1. good wiring to keep the logic flow easy understandable.
2. well aligned icons
3. if the program extends over a screen size, use the LabVIEW “create sub.vi”
feature to build your own icon representing a program-module. 4. program icons
should always be very expressive, so that the program “reader” can easily guess,
what the icons stand for. 5. no GOTOs with rare and discussable exceptions
I’ve passed many hours with kids, introducing them to ROBOLAB. We’ve produced
incredibly powerful RCX-programs with this software. The best ones are the
“GASTON” control programs. Besides this we have developped a ROBOLAB-like
graphical environment to program the PIC 16F628. One of my students has
continued this development to include PIC 16F84, 16F819 and 18F452. The main
power of the ROBOLAB structure is that the icons represent intuitively
understandable program code lines or whole modules. If you are programming PICs
every day, you should use some C++ cross-compiling environment. But if, as it is
the case for most electronics practicians, you must use them occasionally only,
you’ve forgotten most of the code orthography and syntax, and you constantly
need references. Since we are programming PICs graphically, the speed of program
realizations has diminished to less than the half. The ROBOLAB /LabVIEW
structure gives us the facility to set up hardware proximity.
And we’ve not talked yet about the incredible debugging feature that ROBOLAB /
LabVIEW allow. I think, it is the truth, if I assert that anywhere in the world,
where people program a computer, most programming energy is injected into
debugging. If ever you have the time to play around with LabVIEW, you will
rapidly conclude that there doesn’t exist anything comparable to LabVIEW in
finding the bug !
Last point, and I definitely quit this discuission:
Did you have Latin during your studies ? It is said that this language is the
best language, because of its logical structure and other advantages... But
Latin is not spoken anymore.
When I was at school, I had to learn to manage logarithm tables and the
calculation rule. Believe it or not, once a year I do amaze my students with the
following challenge: I prove them that it is possible to compute faster with the
rule than with the calculator. Would I assert that we should go back to the
logarithm table? One of my most gifted maths teacher started each lesson with a
monologue about the dangers of electronic calculators: you won’t do correct
deductions anymore, you will loose the capacity to “see” the square-roots, the
trig rules and you won’t be able to do correct equations... Several years later
I saw him back, and he wore a shirt with “MacIntosh computers” written on it.
So, I asked him and he explained: ” Yes, I was right. If I see the kids today,
they don’t know to do good equation development anymore... But, computers are so
exciting !!!!
We only are at the beginning of a new programming aera through graphical means.
But LabVIEW or perhaps something that we don’t see yet will develop to become
the new programming standard. ROBOLAB is a pioneer in that domain. And its
success proves that we are on the right way. I wrote Ultimate ROBOLAB in
LabVIEW. Of course, I had to go into the code somewhere, but the graphical code
directy generates machine code. We don’t need no other compiler nor Assembler.
Ultimate ROBOLAB isn’t perfect at all. There remains much to do to have it
user-friendly enough and I hope there still are several well hidden bugs, so
that we have things to do. But, I assure you, RCX programming never was so
exciting.
Nqc is brillant, ... Dave you did a great job out there. BrickOS is a great
result of the open source idea and the programmers should have our estimation.
LejOS simply is amazing. And I love PbForth ! Ralph, that’s so cool. But forgive
me: all this was yesterday.
|
|
Message has 2 Replies:
 | | A structured programming question
|
| All, Not to start more discussion on structured vs. unstructured programming, and I hope this doesn't. This doesn't necessarily relate directly to the RCX, but I would like to tap some of the knowledge that is on this list. I have had no formal (...) (20 years ago, 18-Mar-05, to lugnet.robotics)
| | | Re: Robolab's string
|
| (...) The program I showed was the only way you can write a while (true) loop in Robolab with a break statement to terminate the infinite loop. It is Robolab's standard implementation of that good programming practice. My point was that strings (...) (20 years ago, 19-Mar-05, to lugnet.robotics, FTX)
|
Message is in Reply To:
| | Robolab's string
|
| As mentioned elsewhere I could be wrong about Robolab. But absent any informative correction from the Robolab experts listening in I am left to my own devices to make heads or tails of what Robolab is teaching our children. And the more I examine (...) (20 years ago, 17-Mar-05, to lugnet.robotics, FTX)
|
4 Messages in This Thread:
  
- 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
|
|
|
|
|
|
