Panther2Picaxe

[Miles Fletcher]

In April 2010. a group of six programmers (myself included) from the UK and America got together and created Panther, a computer programming language aimed at young people wanting to start programming. It uses a block-like construction to make up code, removing a lot of typing and therefore syntax errors, yet supplying a host of features that let you manipulate the Panther world and sprites inside it as well as interacting with the web and your computer (such as reading/writing to files, reading HTML from web pages and more).

Currently Panther is based on an existing program called "Scratch" which is an open-source language used in schools worldwide, but our next version will no longer be based on Scratch as we are building Panther 2.0 from the ground up.

We are constantly looking to expand our popular programming language and I suggested that using Panther to program a microchip would be a very interesting move and that Picaxe would be a brilliant chip to work with as it is good quality, cheap, easy to use and available worldwide making it appealing to our current users.

I know that the aim of the Picaxe programming editor is to be as simple and easy to use as possible so that children in schools can use and learn from the chips, and we believe that the brilliant block-like layout of Panther would be ideal for making Picaxe programming even easier and therefore appeal to a younger age group, lowering the age boundary of picaxe users.

The finished program will be distributed as a FREE, open source EXE with a smalltalk VM image file. The block script, once run, writes itself to an "output.bas" file and then activates the picaxe comiler to download the script to your picaxe!

Here are some screenshots from the in-development Panther2Picaxe images showing some example mockup blocks and a script in Picaxe basic (with the output script added next to it). The team and I would very much like to hear what you Picaxe users think of the idea, if you have questions or suggestions, feel free to post!

You can see the current Panther site here.

 

[cdngunner]

I have seen this type of programming before.......
I just cant put my finger on it, either PLC or servos or drives.

I deffinately have seen this format of programmng before.

 

[Miles Fletcher]

I have seen this type of programming before.......
I just cant put my finger on it, either PLC or servos or drives.

I deffinately have seen this format of programmng before.

I'm not saying we invented it! (Android have started using this form of programming language for their app creator, Alice, Scratch, WebBlox and Panther use it too.) We're just allowing it to be used for Picaxe programming purposes!

 

[eclectic]

I'm not saying we invented it! (Android have started using this form of programming language for their app creator, Alice, Scratch, WebBlox and Panther use it too.) We're just allowing it to be used for Picaxe programming purposes!

A naive question, based on your marketing site.

Does it /will it make any money for you?

e

Sorry, I shouldn't be so cynical / sceptical;
You are giving this all away, aren't you?

 

[Miles Fletcher]

Was my question naïve?

No, the Panther2Picaxe software will be completely free and open source.

EDIT: No, Don't worry, It's a very good question

 

[cdngunner]

I am developing a facebook page and have given a mention to Rev.Ed Picaxe and your Panther. Kinda nice since my company is LeopardRov.

When I redo my website (hopefully soon) I will have one page for robotic education and will mention both companies on there too.

Maybe if Rev. Ed. will kick in a few freebie Picaxes I could run a yearly robotics competition based on the Picaxe.....

A thought for anyone (technical) listening.

 

[MartinM57]

Interesting. I've stared at the lower picture for a few minutes trying to get my head round it.

I don't know what ages you're aiming at and I'm no educationalist, but it seems a bit too close to real coding to me e.g. you have to understand variables, input pin numbers, that you have to put a return at the end of "check_button" even though the calling blob says ""goto script check_button and return" (and what would happen if I forgot to add the return blob at the end?) etc

Your blobs also (currently, I'm sure they can be changed) just use raw PICAXE command terms ("high", "low") rather than simpler things like "turn on"/"turn off" etc. Presumably schools/home need simple hardware boards to go with this with LEDs, motors, etc and the blobs that directly relate to these sort of things would be better

I would have thought you have to abstract/hide the programming a bit more or else your requiring the kids to still have skills associated with proramming - understanding if-then-else, nesting stuff, calling stuff etc - to achieve something.

I think the "script" metaphor is confusing as it's used for inline labels and subroutines. I think there should be some differentiation. And as before the "return" concept is a bit strange.

Do you have an educationalist (whatever that means - maybe I just made the word up) in your team for an insight on how kids learn stuff, or are you approaching it from the "we're wacky up and coming programmers, lets play around with what we think are useful drag'n'drop visual metaphors in a smalltalk environment, have some dead clever underlying code generation techniques and see what we get"?

Not dissing at all - genuinely interested....

 

[cdngunner]

never mind...the one I saw before was actually keyed differently

 

[MartinM57]

...and you've got a code generation problem (b0 vs b1) and a logic error (b0/1 never incremented, so you have an infinite loop). People like to see accuracy/rigour when presented with new things like this, so worth fixing.

Should it be a prime requirement that you can't produce invalid/unanticipated code from arranging the blobs - like forgetting to put the return blob at the end of "check_button". Is that a requirement that you have a solution for?

 

[hippy]

I've seen a few 'slot together block' programming languages but haven't had much experience with them and can't comment on their educational use or helping students learn.

There's nothing wrong though with abstracting programs into a higher level form whether to make it easier to understand or produce or to prevent errors. In the error prevention cause I'd have designed blocks such that a subroutine ( 'script' ) would be a wrapper block into which other blocks could be slotted and therefore has an implied return at the end. This also follows the principles of block structured code, and I'd also lose all semblance of GOTO.

I'd also agree with MartinM57 in questioning how abstract block commands should be, whether a one-to-one mapping of PICAXE commands or more abstract "if room too hot" and "turn fan on", with what "too hot" is etc separately defined. That follows natural abstraction which is usually implemented by macros, symbol definitions and other means. In fact, IMO, the biggest advantage of any compiler is that it can generate the most complicated code to do the job while still keeping the top level incredibly simple and as abstract as the user wants it. With the right compiler, "if room too hot" may actually be an incredibly complicated determination even though it's seen as a simple boolean result. That's perhaps more following the Forth model of programming.

I suppose it all depends on what one's attempting to produce and what its aim is, and all of us will have varying opinions on what we think is best; programming purists will likely go to the highest level of abstraction while others will argue you cannot beat machine code. Ultimately it's what the programmers it's aimed at think which decides success or failure.

 

[SAborn]

Personally i think the picaxe is rather simple as it is, and if you had dedicated your program to the raw Pic or another chip that was more difficult to program i could then see a much bigger use and a wider application.

From my experience with teaching kids to program a picaxe, is they grasp it much easier than us adults.

Im not one to cotton wool ball kids with learning applications, as this dont help them to develop their knowledge beyond what the building blocks allow.

Stacking blocks together is fine for on screen simulation, but i dont see it as a practical method for a already simple chip to program.

 

[westaust55]

Rev Ed already have a more graphical programming solution in the form of Logicator.

The majority of PICAXE users here use the Programming Editor and text orientated BASIC programming language.

That already gives a problem for many to try and support those who do use Logicator.

Irrespective of who releases the Panther software, I envisage that many will come here rather than go to the source of the software so it may become one more PICAXE programming system for folks here to try and help resolve.

 

[Dippy]

I've seen something like it elsewhere too...
I think you are wise plugging your product - but be careful of advertising on this Forum.

Personal Opinion:-
I guess I've been using linear and 'visual' code for so long now that I wouldn't know what a kiddy would want or understand.
My first programme was
10 Print "Hello"
- and I found that very easy.

It looks very pretty and obviously was a helluva lot of work so well done!

I prefer the purity of text for micro programming.
And if I were doing beginners stuff I would prefer traditional flow programming as it clearly shows , er umm, decision-based flow. And that is, after all, 90% of programming.

I don't like the use of the word "script" for juniors.
In PICAXE BASIC you have "subroutine" .


Maybe you should present this directly to Rev-Ed. ?
They won't bite , so don't be scared.
In theory, if it is a benefit to learning, it may increase the status of PICAXE.
If it could promote PICAXE (and products) then Rev-Ed would be daft to dismiss it.
If they have a vague interest they may ask their friends in Education.

Good luck.

 

[MartinM57]

Maybe I'm expecting/reading too much into it or not got the message about what it's really for.

All (!) you've done is take individual PICAXE BASIC commands and control structures (if-then-else etc) and convert them, one at a time, into a blob format that you can construct in a visual manner (as long as you already understand quite a lot about programming), which you can them convert (relatively easily) back into PICAXE BASIC. So you've taken out some typing and prevented mis-spelling of commands.

If that is all you are after then it looks very nice and might appeal. EDIT actually I think it looks a bit of a mess TBH - lots of colours, inconsistent width, artificial joining of separate blocks with the generic "comment" blob. It's just one big linear colour explosion-athon. Imagine someone presenting a non-trivial Panther blob-o-gram that doesn't work and asking for debugging assistance

Will Panther cover every possible PICAXE command (BUTTON? ) and control structure (WHILE, DO, CASE, INTERRUPT etc), or just an "educational" subset?

 

[MartinM57]

Maybe you should present this directly to Rev-Ed. ?

Should be easy - they must only be a 2d. bus ride away from Miles

 

[Technical]

Actually Miles did his Year10 work placement here at Revolution a couple of years back, and they have already asked us for permsission to use the compilers.

'Scratch', which was developed by MIT and is very popular in schools in some countries, made popular this format of programming, so Miles & co are using an existing style of clip together blocks that is already popular in various parts of the world (although not so much in some countries like the UK). So it is really making a PICAXE connection to an existing style that they are doing, rather than developing a new style.

So if it is free and allows people to use a format they are already familiar with for PICAXE work, then it could be useful to those people. We agree it is really just a 'graphical' version of the BASIC, but an advantage of this is within education is that it is generally 'spelling/syntax' mistake free (since the cells are predefined). Of course there are also lots of disadvantages to predefined blocks, so it will not be for everyone.

 

[Miles Fletcher]

Thanks for the excellent questions, you all pose some very good points.

I think it is certainly a good idea to rename the blocks (not blobs, sorry! ) so that they have more physical meaning to young users (e.g. high 1 is represented as "turn on 1" to the user) and as the mockups above are currently images of very easily edited pieces of code, the name can be changed quickly to a more sutiable one at this stage. The reason the mockups present names that match the code commands are that I thought experienced users who would be able to provide good suggestions might grasp the way the blocks could be used to represent picaxe code faster - perhaps that was a mistake...

As far as looped sections go, I think that we can create loop blocks that add "endif" or a similar command to the code after the blocks placed inside them quite easily, meaning that it won't be possible to forget to close a loop or statement.

I would like to represent different parts of the script as different, draggable sections, though this would mean a way to work out where the program flows after one section is complete would have to be found. After all, the flow will currently, if unspecified, pass to the script directly below if no goto command is used, if two scripts can be next to each other there could be a problem.

Sadly no, we don't have a member of our team who understands how children learn, whatever that field of study may be called, though our youngest member is 13 and an excellent programmer, He's sure to be able to suggest what he sees as easy, or ask friends of a similar age what they like the look of. The Scratch team, many of whom I know well through my time on the site will likely be happy to provide suggestions for block naming as many of them are teachers!

 

[Miles Fletcher]

As "technical" has just said, I have presented the idea to them some time ago when the concept of moving to microchips was first suggested, and we got the go ahead. This thread is to get some ideas, opinions and suggestions and I'm delighted with the mix of support, problems and questions!

I think that the main thing I would like to (at least at first) achieve with this software is to draw the huge community that exists in the Scratch world towards Picaxe, and provide them with an easy, natural step between programming computers in block format and programming microchips in that same, familiar way. The challange, I think, will be to maximise the benifits of a stacking language and try hard to minimise the problems associated with it, some of them have been stated above and I have made a note of them, as solving or providing a decent enough solution will make the whole experience easier and more useful for everyone.

 

[Dippy]

I wish you all the best of luck Miles.

Forgive me for sounding cheeky, but a bit of Market Research is crucial and pretty basic before trying to place a new 'product' on the market. Don't you watch Dragon's Den?
No point spending time or parent's money if A) People don't want it , and/or , B) people don't understand it.

I'm not sure if this Forum is the best place for M.R. as it is full of stubborn old coves

Perhaps you could tell us what your end-goal is?
Or, as all the jargodicks, call it; your "Mission Statement".

 

[Miles Fletcher]

I wish you all the best of luck Miles.

Forgive me for sounding cheeky, but a bit of Market Research is crucial and pretty basic before trying to place a new 'product' on the market. Don't you watch Dragon's Den?
No point spending time or parent's money if A) People don't want it , and/or , B) people don't understand it.

I'm not sure if this Forum is the best place for M.R. as it is full of stubborn old coves

Perhaps you could tell us what your end-goal is?
Or, as all the jargodicks, call it; your "Mission Statement".

Not cheeky at all, I have no formal business experience so it's a very good point, and welcome! I think maybe asking some questions to members of the Scratch website is a very good idea!

It's mostly the fun and the challange of making something like this for me
I'm 18. My parents don't fund me or my hobbies, so it's only my own time and money I'm potentaily wasting!

How's this for an end goal?

"To provide a graphical version of the Picaxe programming software designed as a go-between language that introduces Scratchers to the world of microchip programming and to allow new, young programmers to gain an understanding of chip coding in an easily grasped learning environment."

 

[westaust55]

Thanks for the excellent questions, you all pose some very good points.

I think it is certainly a good idea to rename the blocks (not blobs, sorry! ) so that they have more physical meaning to young users (e.g. high 1 is represented as "turn on 1" to the user) and as the mockups above are currently images of very easily edited pieces of code, the name can be changed quickly to a more sutiable one at this stage.

Using "Turn On" instead of "High" can be fraught with problems followed by why does this not work.

(a) use a PICAXE output to drive an LED directly (with a series current limiting resistor) some other device and yes, "High" turns on the LED.

(b) use a PICAXE output to drive a low side transistor to control the LED some other device directly and again yes, "High" turns on the LED.

(c) use a PICAXE output to drive a high side transistor to control the LED or some other device directly and now we need to use a LOW on the PICAXE output to turn on the transistor so the LED or whatever operates.


It is possible that there may be folks who are very experienced in general electronics and therefore able to design circuits that are high side switching but have less knowledge in programming and thus find the likes of Logicator or the proposed new Panther software easier to comprehend.
Such folks may therefore find the command for "Turn On" does not turn on their circuit as expected.

 

[hippy]

A common term in software engineering used to overcome the high/low nature of a signal is that one "asserts" it to take it to its active state and "deasserts" it to take it to its inactive state. Not something those new to programming may immediately grasp.

A software purist would argue that one should never set a signal high or low explicitly and to control a LED say on the PICAXE the following would be preferable ...

myRedLed = LED_ON
myRedLed = LED_OFF

Where LED_ON and LED_OFF are defined by symbol elsewhere.

Of course there's a problem should there be two LED's, one active low another active high. You cannot use the same = LED_ON for both and achieve the same behaviour.

One can then argue that it's best to use booleans ...

myRedLed.On = TRUE
myGreenLed.On = FALSE

and handle the relationship between the entity assigned to and physical pin plus any inversion elsewhere.

Then you're back into the argument as to whether any particular programming language should closely match what's actually going on electrically and at the hardware level, or whether the language should be more or completely abstract.

The main argument for abstraction is that the same program will work on any hardware without any change to the program itself, all that needs altering is the mapping of what the program uses to what the hardware is.

 

[premelec]

Natural language to code

My preference in developing something for kids would be that they could write an instruction in some natural spoken language which would then propose some code and ask about ambiguities where they exist and then the kid could look at the generated code and get some idea how what was wanted could be manifested in code.

I recall seeing BASIC about 35 years ago and thinking why would anyone want to do this - so many instructions to add two numbers for instance - input a ; input b ; c = a + b ; print c - when a simple four function calculator is so straight forward. Eventually I got sucked into writing thousands of lines of code and understood what it's about. I don't think that kids immediately understand what its about any more than doing rote long division and such. Something has to interest them in the process - perhaps pictorial function blocks do it though they just confuse me

Obviously some people do a lot better with abstractions and shortcuts and one language or procedure will never suit everyone. There are things in PICAXE coding that still seem obscure to me - pins... But I learn to work with whatever it takes to get it to work.

Whatever works - empiricism !

 

[graynomad]

I'm too old and have been programming for too long to have a valid opinion about what kids need to get them interested in learning programming/electronics.

I don't see why one doesn't just spend 3 days with an assembler to get a LED flashing

Westaus55's points about on/off/high/low are valid, maybe the system should have constraints, ON/OFF only apply to the two most common scenarios, LED/resistor to GND and low-side transistor. That's surely enough for a school kid to play with and get the electronics bug. If they don't get it then all the other options are moot.

If the system is tied to tutorials all this would be covered.

But in general I like the look and the idea of this, and Miles, ten points for having a go.

 

[John O]

There are things in PICAXE coding that still seem obscure to me - pins... But I learn to work with whatever it takes to get it to work.

Whatever works - empiricism !

I can handle 'pins' as I see it as a collection of them to make a byte. What I don't think I'll ever get my head round is why 'high B.0' is correct but 'B.0 = 1' is not. Or, conversely, why 'pinB.0 = 1' is correct but 'high pinB.0' is not.

John.

 

[Miles Fletcher]

I think you have to agree that a "turn on/off" command is as bad as a "high/low" command in the sense that when a darlington driver or transistor circuit is added, the high becomes low, the off become on. Either I should supply a way for a teacher or user to edit what a block does (e.g. a window opens when you "right-click>edit" a block, with the Picaxe command the block equates to, and change it so the "turn on" block contains the "low" command and such. Otherwise, I suppose it's up to them to notice that in this particular circuit it's the wrong way round, and live with it, same as the high/low commands.

With the exception of the loop blocks that represent two pieces of code on either end of other blocks, I think this would be a nice, customisable extra that is easy to add and would allow slightly more experienced users to take more control over the program.

I'm torn between providing a block for every picaxe command, and having the more commonly used ones (for a learner) as blocks, with a blank command block containing nothing but a text box which will allow any specialist commands to be typed in. The second option might be more appropriate.

 

[StigOfTheDump]

I think you have to agree that a "turn on/off" command is as bad as a "high/low" command in the sense that when a darlington driver or transistor circuit is added, the high becomes low, the off become on.

I think high and low are best. It is all to do with perception of what is going to happen.

If you open a tap the water flows.
If you open a switch the current stops.
If you open a drawbridge the cars stop and the ships go.

Every child knows that when someone goes down on a see-saw somebody else goes up. Depending on the agegroup they may or may not understand, that the parent has to sit halfway up the see-saw, to be lifted by the kid. In the first half of a football match a player has to put the ball in one net. In the second half he needs to put it in the other net to achieve his goal.

The trick is to align what is happening at each stage with something that they already understand.

 

[Dippy]

Everyone has to learn the consequences of their actions sooner or later.
Start them off straight away , don't spoil them.


I tend to agree with hippy on this.

Aren't we talking about a language which controls/defines a processor I/O - not the overall circuit. Or what??
Your block/blob could get really messy if you start trying to be 'everything to all men'.

If you have add-ons which modify the signal then you have to learn to understand the system.

Or maybe your blobs should have a mouseover zone which describes the system behaviour of using that command. Like tooltip (ooer) in VB.
Or maybe a "?" button on your blob - when clicked a multi-line Comment Pop-Up appears.

Often a few words in a normal comment aren't enough to describe the true goings-on , especially for a total novice.
(I'd like the opportunity to have extra comments in any language. I guess Ec will now be searching every compiler database in the world to see if it already done )

 

[techElder]

I have used so called "natural" language programming.

At the best of it, even though I was typing in a "natural" way, I was still using a fixed-word interpreter.

It was just programmed to ignore all of the superfluous and/or extraneous words that were added to connect the words of the language.

One still had to learn the 'basic' commands and their syntax.

 

[hippy]

What I don't think I'll ever get my head round is why 'high B.0' is correct but 'B.0 = 1' is not. Or, conversely, why 'pinB.0 = 1' is correct but 'high pinB.0' is not.

John.

Start with the case of earlier PICAXE having just a number to define the pin (0-7) and consider "If pin1 =" - What that says is get the value of what pin1 reads. If you had "If 1 =" that would be a simple get the number 1.

Now for "High 1" that's "Set a pin high, the pin to use is number 1".

If you had "High pin1" that's "Set a pin high, the pin number to use is the value of what pin1 reads". Depending on what pin1 reads you will either set pin 0 or pin 1 high.

It's not actually incorrect, it's just not allowed by the Programming Editor, because people using that are probably not intending what does happen to happen. It's an attempt to 'save them from themselves'. Some will agree with that decision, others may not. If you want to actually do "High pin1" you can use -

b0 = pin1
High b0

The issue perhaps reveals itself more if one considers "High 1" can be written as -

b0 = 1
High b0


Onto "B.0=1" and "pinB.0=1", if we stick with the old pin number concept, for the first you'd really be writing '0=1' and that doesn't make much sense, but "pin0=1" does make sense.


The real difference between "B.0" and "pinB.0" is that the first is a constant which defines a pin, the second is a variable through which a pin level can be read or be set. So ...

B.0 = 1 ' makes no sense as above
pinB.0 = 1 ' sets pin B.0 level to 1

b0 = B.0 ' puts the pin number into b0
b0 = pinB.0 ' reads the level on pin B.0 into b0

High B.0 ' sets a pin high, that pin number is B.0
High pinB.0 ' set a pin high, that pin number is 0 or 1 depending on level on pin B.0

If B.0 = 1 ' If pin number is 1 ...
If pinB.0 = 1 ' If the level read from pin B.0 is 1 ...

 

[Hansen]

O.O

I try it, both why shut it have internet connection ?

And it hard to use compare to the normal editor

I remove it again and go back to the EASY ProgramEditor

 

[Miles Fletcher]

O.O

I try it, both why shut it have internet connection ?

And it hard to use compare to the normal editor

I remove it again and go back to the EASY ProgramEditor

Pardon? Are you saying you downloaded the block version of Picaxe?! It's not avaliable yet! I think you downloaded Panther, which attempts to connect to our website and display the latest news when opened. The internet connection is not mandatory for the software to work, and Panther is for programming your computer, not a chip

You joined in 1970?! Wow! Didn't know Picaxe was around that early...