I will go further and say that there is no only a place for an interactive language on the Propeller; it is a necessity for the educational and introductory modes of learning the Propeller.
What we do not need is another 700 page tome that tries to prove that this platform and this language is a better value. Long texts never get read; but interactive software can capture a new user and have then hooke in seconds...SECONDS!!!!!
That intereact language doesn't have to be Forth.. it could be Basic, or something else. It certain would hurt to have several interactive languages represented.. even Ladder Logic. The point is to gain new users and to give them the feeling that they can grow into knowing more without having to go elsewhere.
I've been thinking about this, too. Modern video games are written so that the player is taught how to play the game, as he plays it. How to do that for a microcontroller is challenging. I suppose incremental goal-based objectives would be the key. Whatever microcontroller had that going for it could become pretty popular. People enjoy genuine challenges much more than gratuitous ones. Learning a microcontroller would be way more gratifying and edifying than a video game.
These two posts are spot-on regarding learning the prop. It could be any micro, the same applies.
This is all well and good if we are only after the education and hobbyist market.
But for the commercial market, we have to go further. Professionals may just get the above to try out the micro. But then they are going to want to see what the chip can really do and what languages are supported. Of course they will have their favourite language.
Now, it is obvious for the P1 & P2 that pasm is one language that must be used. However, it does not have to be learnt first, or indeed at all by some. The main use of pasm is for doing the time critical and/or deterministic code portions. Much of this pasm code is likely to be in objects meaning that pasm doesn't need to be understood. Any true professional will pick this up if and when they find the need to do so.
Next, we need the higher level language. And here is where the differences really set in, for what is standard language use. Every language has its own set of quirks. Spin is no different. Lets look at some language differences... Differences that are really differences just for the sake of being different...
REPEAT LOOPS...
repeat i from 0 to 9
.....code
for I=0 to 9
....code
next
for (i=0; i<10; i++)
{
....;
}
CASE STATEMENTS
case x
$01: ....code
........
other: ....
Select Case n
case 0
......
case 5 to 8
......
case else
......
End Select
switch (n)
{
case 0:
....;
break;
case 5:
....;
break;
default:
....;
break;
}
Why do we have all these differences? Why over the years haven't these constructs become standard? Could it be that the architects want to make their language different just for the sake of it???
IMHO, what we need is a standard for these "same' constructs such that pre-parser will convert to the particular language nuances at compile time.
It uses any generic editor and syntax highlighting, I've used windows & linux.
It doesn't have a simulator, it just runs directly on the real prop, and uses one or more cogs to monitor the others
It depends I guess on what you are trying to teach, but download and hope, is not really much of an aspiration.
Monitors are also quite restrictive, and not the best way to learn a chip, but may be tolerable for simple send & test tasks.
Editors are the easy part of the equation, getting it to be variable-value aware (hover watch) and chip-simulate takes rather more work, but it is streets ahead of working blind.
For a chip that is out of the main-stream, good simulation is going to be an important 'design win' tool.
I've had too work in Algol, BASIC, Coral 66, PL/M, C, Pascal, Ada, PHP, Python, JavaScript, and probably a few others I have forgotten. For a long time it seemed every major project I worked on was in a different language. It's a real drag having to learn all the nitty details of something new but basically the same again and again.
That is why I overlooked the Prop for a long time. The Spin language. Oh no, YAFL to deal with. No thanks.
I guess we stand as much chance of getting language designers to standardize on the basic language constructs, "sequence", "selection", "iteration" as we have getting Americans to spell properly or use grammar:)
On the other hand there are major difference in languages at a higher semantic level. Difference in the types they support, degree of type checking, dynamic or static, variable scoping rules, object oriented or not, functional, procedural, declarative, Etc Etc.
So it can be confusing when two languages look syntactically the same but behave very differently. Compare C and JavaScript.
Odd fact: The second favorite language of Guido van Rossum, the creator of Python, is C. How different can they be? Of course Python is implemented in C.
Currently my favorite languages are C and JavaScript. I noticed that any language whose name starts with "P" is awful.
Don't believe me? Check out Pascal, PHP. Python, Perl:)
Pascal, as Free Pascal Compiler and Lazarus IDE is still alive.
I know, what I meant by 'back in the day' is that I used to program in Pascal (and Fortran 77) in the past, not anymore. Turbo Pascal (on the micros) and CAT-Pascal (on the minis) - I bet not many know what kind of Pascal that was. These days C (straight ANSI C, not C++) and Perl cover almost everything I need to do.
We are using Free Pascal here for a commercial product as I speak. This code comes out of a university project where it seems the academics still like Pascal.
It's OK except:
1) It has been a royal pain moving it onto various ARM architectures we support. There are a whole bunch of ARM variants with different ideas about floating point support. Starting from none, you have to use do software float routines to quite good hardware float. Problem is Free Pascal out of the box never compiles your code to use floating point hardware instructions and it's a pain to have to rebuild the tool chain to do so. Our app uses a lot of floating point.
2) The syntax is hideous.
3) Original Pascal had a serious problem with strings. Every different length string was a different type. So Pascal's type checking would not let you write a function that accepted different lengths of string.
Comments
This is all well and good if we are only after the education and hobbyist market.
But for the commercial market, we have to go further. Professionals may just get the above to try out the micro. But then they are going to want to see what the chip can really do and what languages are supported. Of course they will have their favourite language.
Now, it is obvious for the P1 & P2 that pasm is one language that must be used. However, it does not have to be learnt first, or indeed at all by some. The main use of pasm is for doing the time critical and/or deterministic code portions. Much of this pasm code is likely to be in objects meaning that pasm doesn't need to be understood. Any true professional will pick this up if and when they find the need to do so.
Next, we need the higher level language. And here is where the differences really set in, for what is standard language use. Every language has its own set of quirks. Spin is no different. Lets look at some language differences... Differences that are really differences just for the sake of being different...
REPEAT LOOPS...
repeat i from 0 to 9 .....codefor I=0 to 9 ....code nextfor (i=0; i<10; i++) { ....; }CASE STATEMENTScase x $01: ....code ........ other: ....Select Case n case 0 ...... case 5 to 8 ...... case else ...... End Selectswitch (n) { case 0: ....; break; case 5: ....; break; default: ....; break; }Why do we have all these differences? Why over the years haven't these constructs become standard? Could it be that the architects want to make their language different just for the sake of it???IMHO, what we need is a standard for these "same' constructs such that pre-parser will convert to the particular language nuances at compile time.
It depends I guess on what you are trying to teach, but download and hope, is not really much of an aspiration.
Monitors are also quite restrictive, and not the best way to learn a chip, but may be tolerable for simple send & test tasks.
Editors are the easy part of the equation, getting it to be variable-value aware (hover watch) and chip-simulate takes rather more work, but it is streets ahead of working blind.
For a chip that is out of the main-stream, good simulation is going to be an important 'design win' tool.
I've had too work in Algol, BASIC, Coral 66, PL/M, C, Pascal, Ada, PHP, Python, JavaScript, and probably a few others I have forgotten. For a long time it seemed every major project I worked on was in a different language. It's a real drag having to learn all the nitty details of something new but basically the same again and again.
That is why I overlooked the Prop for a long time. The Spin language. Oh no, YAFL to deal with. No thanks.
I guess we stand as much chance of getting language designers to standardize on the basic language constructs, "sequence", "selection", "iteration" as we have getting Americans to spell properly or use grammar:)
On the other hand there are major difference in languages at a higher semantic level. Difference in the types they support, degree of type checking, dynamic or static, variable scoping rules, object oriented or not, functional, procedural, declarative, Etc Etc.
So it can be confusing when two languages look syntactically the same but behave very differently. Compare C and JavaScript.
Odd fact: The second favorite language of Guido van Rossum, the creator of Python, is C. How different can they be? Of course Python is implemented in C.
Currently my favorite languages are C and JavaScript. I noticed that any language whose name starts with "P" is awful.
Don't believe me? Check out Pascal, PHP. Python, Perl:)
-Tor
-Tor
We are using Free Pascal here for a commercial product as I speak. This code comes out of a university project where it seems the academics still like Pascal.
It's OK except:
1) It has been a royal pain moving it onto various ARM architectures we support. There are a whole bunch of ARM variants with different ideas about floating point support. Starting from none, you have to use do software float routines to quite good hardware float. Problem is Free Pascal out of the box never compiles your code to use floating point hardware instructions and it's a pain to have to rebuild the tool chain to do so. Our app uses a lot of floating point.
2) The syntax is hideous.
3) Original Pascal had a serious problem with strings. Every different length string was a different type. So Pascal's type checking would not let you write a function that accepted different lengths of string.