Scribbler GUI suggestions
David Bayliss
Posts: 58
First let me say that the scribbler GUI is excellent - none of the below are criticisms. However, as someone who worked in automated code generation for a decade (the Clarion language / Templates were my baby) I thought the following might be worth considering -
a) Raising the limit on the number of subroutines allowed - currently it is eight. My thirteen year old exhausted the limit in less than a day
b) IF I understand the generated code then currently the subroutine nesting limit tolerated by the GUI is one less than that of PBASIC
c) The 'music' module always generates FREQOUT statements; these can rapidly fill up the EEPROM (one of my sons first programs was to have his robot play the star wars them tune whilst marching forward and 'shooting' people). The 'what is a microcontroller' manual uses a loop and eeprom encoding mechanism - this would be tighter.
d) The condition logic allows for a single condition and also for a conjunction (AND) between two conditions. Having a disjunction (OR) option too would be very nice.
e) An 'embed' control would be fundamentally enabling. This is just a box which allows someone to type in basic which is slotted into place. The value is that it allows people to 'dabble' in the core language without having to abandon the comfortable gui.
The above are all (I think) relatively minor and should not involve major source changes. A much bigger one would be -
f) Consider allowing the code generation of the components to be driven by templates (ASCII boilerplates for the generated code). This would allow 'algorithms' to be design in the gui and then potentially ported to other solutions. Put another way - it could give you a degree of cross-chip portability which seems to be lacking.
Again and in closing - I'm not trying to be rude or critical here - as I said - I lived this for ten years - I'm trained to look at a product and come up with a ToDo list. I was actually astonished at the slickness of the GUI and the quality of the generated code. But I don't let that stop me [noparse]:)[/noparse]
David
a) Raising the limit on the number of subroutines allowed - currently it is eight. My thirteen year old exhausted the limit in less than a day
b) IF I understand the generated code then currently the subroutine nesting limit tolerated by the GUI is one less than that of PBASIC
c) The 'music' module always generates FREQOUT statements; these can rapidly fill up the EEPROM (one of my sons first programs was to have his robot play the star wars them tune whilst marching forward and 'shooting' people). The 'what is a microcontroller' manual uses a loop and eeprom encoding mechanism - this would be tighter.
d) The condition logic allows for a single condition and also for a conjunction (AND) between two conditions. Having a disjunction (OR) option too would be very nice.
e) An 'embed' control would be fundamentally enabling. This is just a box which allows someone to type in basic which is slotted into place. The value is that it allows people to 'dabble' in the core language without having to abandon the comfortable gui.
The above are all (I think) relatively minor and should not involve major source changes. A much bigger one would be -
f) Consider allowing the code generation of the components to be driven by templates (ASCII boilerplates for the generated code). This would allow 'algorithms' to be design in the gui and then potentially ported to other solutions. Put another way - it could give you a degree of cross-chip portability which seems to be lacking.
Again and in closing - I'm not trying to be rude or critical here - as I said - I lived this for ten years - I'm trained to look at a product and come up with a ToDo list. I was actually astonished at the slickness of the GUI and the quality of the generated code. But I don't let that stop me [noparse]:)[/noparse]
David
Comments
I'm the author of the GUI, so I'll try to respond to your suggestions here:
a) Smart kid! The limit of eight was arrived at more by the number of easily-distinguished colors and the amount of "eye space" available on the screen than anything else. Judicious use of the flags will enable one subroutine to be used for multiple purposes and would be a good pedagogical exercise for your son.
b) Several of the built-in functions require their own subroutine calls, which restricts the number of nested user calls to three.
c) I tried the loop method, but discarded it due to the gaps it caused between notes, which compromised the sound quality. I thought better sound would lead to a better overall experience than more and longer tunes. It was a judgement call on my part, which legitimate arguments could be made for or against.
d) There is an OR, sort of, if you don't mind a little redundant code:
is equivalent to
Of course, this does get a little unwieldy after awhile. It's been a few years since I wrote this, so I'm not sure why a real OR was not included. My suspicion is that it had something to do with where to put the "rejoin" point in the flow diagram, with no way to do it unambiguously when the only program construction operations are insert and delete.
e) The PBASIC code generated by the GUI is very tight insofar as variable space is concerned. The GUI also carries a guarantee that no incorrect code will be generated. Both of these conspire against the kind of freedom your suggestion entails, I'm afraid. You can always create a program with the GUI, then edit it in the PBASIC IDE. You just have to be careful not to trample on variables that may hold state information critical to the program's operation.
Thanks much for your kind comments about the GUI. I'm glad your son is having such a good time with it! And I always appreciate input like this, especially from someone who understands the issues involved in creating such a programming frontend.
-Phil
b) I had a suspicion that was the case - but i figured I'd mention it just in case.
c) Interesting - I'm suprised the overhead on a loop is that painful - even for an interpreted language I would have expected a pure for loop to manage milliseconds of overhead
d) Yes - this was when we first hit the subroutine limits - he was 'faking' an OR using dual execution paths but then found he couldn't subroutine out the OR contents. I'm not sure I understand the point about program rejoin points - you already have the cascaded AND; a join would just be an alternative to the AND ...
e) The EMBED is definately one of the more controversial suggestions - and I fully understand it break the guarantees - but that is kinda the point [noparse]:)[/noparse] Yes he can (and does) generate the code and then edit it - but you obviously lose the ability to develop further in the GUI. My (old) product is still sold at www.softvelocity.com a decade after I finished with it. What we found is that the embeds allow a much smoother transition from GUIers to 'handcoders' - essentially they pulled people deeper into the product.
--- while I'm writing I remembered a couple more
g) Some kind of variable other than a pure flag (his biggest project to date is a program to get out of mazes - developing 'memory' to avoid mistakes with 6 flags is difficult)
h) He got fooled by the heads/tails paradigm. He could understand h/t was 50/50 but had difficulting grasping that 4 heads meant 1/16. Dice might be a nice option too.
i) tied into g - a multi-way choose (presumably creating an ON GOSUB construct)
============
Finally and again to be clear to any readers - I'm only writing this because I firmly believe that this GUI is strong enough already to be worth writing about
David
Revisiting the OR, perhaps it's time to introduce your son to DeMorgan's Theorem: a OR b = NOT(NOT a AND NOT b).
-Phil