| |
In lugnet.events.brickworld, Edwin Pilobello wrote:
| |
In lugnet.robotics, Brian Davis wrote:
| |
In the end, it seems there isn’t a text-version of an NXT-G program. So, the
question then becomes, can someone produce such a “translator” (that works
well enough not to further complicate the issue), or if not how do you get
around this (especially for teaching purposes)? To the first I don’t know
(but I can’t do it), and for the second I can think of two ways (teach better
NXT-G methods, or migrate to a language you like better).
|
Nice defense! I’m sure the NI engineers have anticipated the complexities
you’ve mentioned. Hence, no scary print-to-text. However, I’m not asking for
anything so ambitious. I hold that a print-to-text within the context of
plain NXT-G (no advanced options) is doable. It’s probably all that’s needed
for elementary school pedagogy.
|
Suppose you want a team of programmers to write some new software to do X, Y,
and Z. You give them some specifications and requirements for the software plus
free Mountain Dew, and they go off to design and write your software. After
several weeks or months they come back with the result of their labors.
It doesn’t work. Oh yes, it does X and Y, but it only does part of Z because you
forgot to tell them Z only happens during leap years. You also realize that you
needed the software to do A, B, and C, but only on Sundays, and the project is
already behind schedule and over budget, and shoehorning this new functionality
into the system will cost even more time and money. If the project even
finishes, it will be deemed a failure by those who use it. Better to kill it now
and cut your losses.
The problem is that your specifications were incomplete and insufficient to
describe the business needs you had.
Here’s the kicker: if you take the time to write some incredibly detailed
specifications that correctly anticipate every possible state the software will
encounter, you are, in effect, writing the actual software, except you’re not
doing it in code, but in an ambiguous human language.
You two have gotten into a discussion about some classic problems in computer
science. The above example is one of program specification languages vs.
programming languages, and NXT-G, being graphical, is more of the former than
the latter . . . in principle.
But NXT-G is somehow compiled into bytecodes, which means there is translation
going on. I suspect that the translation is both difficult and proprietary. By
its nature, a printout of NXT-G pseudocode generated by the software itself will
likely reveal their trade secrets. It would make a great subject for a comp sci
research paper, but it’s not something they’re going to want to share.
|
|
Message has 2 Replies:
 | | Re: NXT-G print to text?
|
| (...) Though it is VERY far from NXT-G print to text, printing a program at bytecode level is easy: just drop the compiled RXE file in BricxCC. Problem is that except for the most simple programs, the result is an obscure ratsnest! Philo (16 years ago, 6-Jan-09, to lugnet.events.brickworld, lugnet.robotics)
|
Message is in Reply To:
| | Re: NXT-G print to text?
|
| (...) Nice defense! I'm sure the NI engineers have anticipated the complexities you've mentioned. Hence, no scary print-to-text. However, I'm not asking for anything so ambitious. I hold that a print-to-text within the context of plain NXT-G (no (...) (16 years ago, 21-Jul-08, to lugnet.events.brickworld, lugnet.robotics)
|
13 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
|
|
|
|
|
|
