| |
In lugnet.events.brickworld, Edwin Pilobello wrote:
> > It's not there. Conclusions may now be drawn :).
> >
> > Nor has anybody come along and made a reasonable "graphic
> > description language" that translates a chunk of NXT-G into
> > something like C or pseudocode.
>
> Obviously, NI is so confident they've reached their design goal: that every 9
> year old should be able to program in NXT-G without calling tech support.
<grin>. I said "conclusions may now be drawn", not "all conclusions are equally
likely to be correct". You seem to be assuming that NI is stupid or
overconfident. I'm pretty sure that's not the case. When there's something I
don't understand about a situation, I generally try to follow these rules:
1) First, never ascribe to malice what can be sufficiently
explained by stupidity or ignorance. It's amazing to me
how often this rule explains human behavior.
2) Second, don't automatically assume malice or stupidity
if there are likely factors you don't know about or
haven't considered.
I suspect it's quite possible that there are at least two possibilities you may
not be considering. The first is that getting a proper human-readable text
representation of a graphic language like NXT-G or LabVIEW is rather difficult.
While it may look simple on the surface ("a Switch is just an 'if' statement, or
maybe a 'switch & case' statement), thinking about wire validation and data
dependancy, not to mention the funny tricks you can pull by multiple calls to
single FW routines (like Move or Motor) and multiple sequences makes this very
difficult to represent correctly ("this branch of the switch will set this
variable equal to whatever is wired in from that other parallel sequence, but
only after that other sequence reaches that point and after the value that the
switch is making its choice based on is also supplied from a third, independent
sequence that in turn is only activated at certain times by the first
sequence"... and if you think that's made up, it's a pretty good description of
a code problem I was working on). On top of this are non-reentrant subroutines
(My Blocks, with parameter passing as well as both local and global variables)
as well as reentrant subroutines (most of the stock blocks), etc.
The reason I mentioned "nobody else has done it" is to point out that if it was
easy, I suspect others would have cracked it and tried it... not that NI is
"just sitting on it" and it's easy to do.
The other reason that NI may be highly reluctant to do this is plain & simple
intellectual property. They have a vested interest in graphical languages and
their representation, and while the LabVIEW community has often taked about
wishing NI would open-source LabVIEW, they haven't... for very good, sound,
buiseness reasons.
> In my classes, 9 and 10 year olds blow through such a low level of
> expectation within an hour of two of completing Tribot or Spike.
> Then what?
Well, you could always point out that it might really be helpful to start
thinking in terms of modular, self-documenting code, instead of "tinkering to
get it to work". A good example of this in text-based languages is "spaghetti
code", using GOTOs all over the place or doing the same thing in multiple places
without subroutines (and then correcting one of these later and not remember the
other five places you sprinkled this in your code).
> IMO, any ambitious program could use a print to text option to
> help in debugging.
I would agree - but I'm still programming in NXT-G, and handling it rather
nicely (in fact it's taught me some things about code management that I
successfully avoiding learning all these years under text-based systems).
Understand I agree with you, I'd dearly love a text-based option... which is why
at some point, for some projects, I'll eventually switch to pbLua (much faster
and supports the Mac platform) or ROBOTC (much faster, very powerful debugger,
but not... yet?... for the Mac).
> I therefore conclude that NI suffers from myopia or that
> they haven't been paid enough for it.
All I can say here is that I *know*, from personal experience, that at least
some of your assumptions are provably, factually wrong. And given what I know, I
wonder how many other assumptions that you & I have are certainly incorrect as
well... and make drawing accurate conclusions difficult or impossible.
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).
--
Brian Davis
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | Re: NXT-G print to text?
|
| (...) Obviously, NI is so confident they've reached their design goal: that every 9 year old should be able to program in NXT-G without calling tech support. In my classes, 9 and 10 year olds blow through such a low level of expectation within an (...) (16 years ago, 19-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
|
|
|
|
