Improve PBP with integrated configuration

[Kirk Fraser]

> Pretty easy to cater to the PIC so the programmer doesn't have to learn how it works.

Excellent typo - I think you meant Stamp, but your sentence describes succinctly what needs to be improved in PBP - make it so the programmer doesn't have to learn how the PIC works! Stamp Basic automatically decides based on the programmer's code whether to make a pin digital or analog so the programmer doesn't need to know how that is done. That's what a computer language compiler is for, so the programmer programs at a more abstract level than assembler.

PBP's design is a generation too old, from the days of Peek and Poke programming. If PBP has to cover different internal code for different PICs then the programmer should only have to name the processor such as "include 18F4550.bas" or use the drop-down menu to get PBP to generate the right code for that chip. Any need to resort to ASM should be pre-empted by the redesign of PBP, as should any need to set up a configuration, especially the code to get the chip to simply work. However, the PBP redesign should be done carefully to avoid the language complexity and code bloat that came in as Microsoft moved from GBasic to Visual Basic.

My qualifications for making suggestions to improve the PBP product include several years of working with a Stanford student to specify a new higher level computer language which he built in VBasic.