Though you would best program in a language you were already familiar with, SPIN and PASM work together and are design specifically for the propeller. They cover the control of every aspect of the propeller and are stable languages. To use a propeller chip and not be familiar its two languages seems to me to be a rather serious mistake. I started on these languages knowing nothing about either of them. They were easy to master, fast and powerful. Give them some serious consideration, you will not be disappointed.
H
Not really. It's a natural consequence of C being very much on the lower end of the high-level language spectrum. C is really only a few steps up from assembler, and gets used for work that would previously have been done in assembler. 100% of an assembler program is non-portable. C does much better - maybe only 5% of your typical C program is non-portable ... but it does tend to be the tricky stuff.
I also see a problem with GCC and OBEX for Prop2 especially...
A lot of the advanced code we're going to want to use is GPL and it would be breaking the rules to say it's MIT...
I also see a problem with GCC and OBEX for Prop2 especially...
A lot of the advanced code we're going to want to use is GPL and it would be breaking the rules to say it's MIT...
The code in OBEX is usually written by Propeller users, right? In that case they can use any license they want. I don't think we plan to check GCC itself into OBEX do we?
I don't care much for the C++ on a microcontroller. All that class inheritance and memory management is beyond my interest, an i don't think it has lived up to the hype. But then i am a hardware guy that wants to control things and not a programming that wants to write elegant code.
Time was that nearly everyone doing embedded/real-time programming was a hardware guy (or gal). I started out doing analog and digital circuit design, which I really liked, but as time went on found myself doing more and more coding. (Micros were being put into anything and everything, and someone had to write the code for 'em.) Nowadays I would imagine it's still true that you have to be familiar with hardware, analog and digital, to do this sort of programming well, though no doubt there are exceptions. As for C++, I couldn't agree more; for smaller systems it just doesn't make sense. Besides, it's a monstrosity anyway.
I'll second (third, whatever) what others have said and recommend that you start with Spin/PASM and the PropTool. Take it from a fellow Propeller newbie: that's the best way to get up and running with the chip. And more than likely you'll be able to do your initial projects with that alone. Then, later on, if needed you can move to C, or Tachyon Forth (very nice!), or something more exotic. (Maybe by then someone will have made a nice Pascal tool-chain for Prop, comparable to, say, AVRco for AVRs.:) )
The code in OBEX is usually written by Propeller users, right? In that case they can use any license they want. I don't think we plan to check GCC itself into OBEX do we?
No, but in my experience, in the C world you would generally want to check in a much larger "chunk" of code than is true in the Spin world - e.g. a whole program or library, rather than just a code snippet (and for goodness sake, let's not get started on just what constitutes an "object" here!). In the C world such chunks would very often contain at least some code that is not MIT licensed (it would usually be GPL, but it could contain various other "free" licences as well).
That's kind of the point of using C in the first place - you can easily adapt masses of existing C code, from many different sources. Catalina itself is a good example of what can be achieved by doing so - it contains various chunks of "free" C code taken from a whole bunch of places. For most non-commercial purposes the licenses of code you find on the internet are "free", fully compatible and you don't need to worry about them at all (of course you would have to worry for software developed for commercial purposes, but not many people would want to put such software in the OBEX, so that doesn't really matter here **).
But who is going to go to the bother of tear their 10,000 line C program into separately licensed chunks just to be able to submit some portion of it to the OBEX?
Ross.
** Footnote for Catalina users: I have checked the licensing of all parts of Catalina to make sure that programs developed with Catalina are free of problematic license restrictions - e.g. all the library code is freely re-usable. However, this is not true of Catalina itself, since it is based on various components that are not free of such license restrictions (e.g. LCC). This means is that you can sell a product compiled with Catalina, but not a product that itself contains parts of Catalina (other than compiled versions of the library code, of course).
Blast! I didn't want to get yet another thread derailed into a discussion about licensing! :frown:
As for C++, I couldn't agree more; for smaller systems it just doesn't make sense. Besides, it's a monstrosity anyway.
This is in an argument that recurs here quite often and is demonstrably not true. C++ can be a sensibe choice even on small systems. I would link you to previous discussions here about it but I'm too tired to start searching for them now.
But do note that:
1) C++ is the language of the Arduino. How small are we wanting to talk about?
2) C++ enables you to construct a program from objects that look extremely similar to the object architecture of Spin programs.
3) There is no overhead in using C++ to do this as opposed to C but the syntax looks a lot nicer.
On the other hand, yes, C++ is a monster, huge and tortuous language. Notice the clever way the Arduino guys never actually say that the Arduino is programmed in C++ and all their documentation and tutorials and the Arduino IDE hide a lot of C++ features that would confuse the uninitiated or lead them into trouble.
But do note that:
1) C++ is the language of the Arduino. How small are we wanting to talk about?
Should I then use Arduino for my next professional project? I think not. C (or Pascal) on a plain AVR will do just fine, and probably cost me less time and trouble in the long-run. (Maybe I can use a smaller, cheaper chip too.)
2) C++ enables you to construct a program from objects that look extremely similar to the object architecture of Spin programs.
I can write structured programs in C that offer many of the advantages of object-oriented programming, more than enough for what I'm doing in a small space, without the headaches or bloat that comes with C++. Moreover, object-oriented isn't the only programming pardigm, or often times the one best suited for specific embedded projects. So, for Propeller coding, if Spin wasn't an option (I guess speed of execution being the issue), I'd go with C (or...?). And in terms of just programming objects, Spin seems to me a much cleaner way of doing that.
3) There is no overhead in using C++ to do this as opposed to C but the syntax looks a lot nicer.
As opposed to ... what? Programming an ATmega8515 to perform some basic functions (run an LCD, accept switch presses, read a sensor, and control, say, a heater)? I can do all that without worrying about a heap, etc., with code written in a very clean and maintainable form of C, at less cost and with less headache. And it's not as though C++ could gain me any big advantage in coding time or portability, either; certainly nothing like what I get moving from assembly to C. Why, then, would anyone think that C++ is better suited for such things? Pure nonsense. You could show me a hundred threads (and I've probably seen 'em anyway) and not one will clearlydemonstrate any such thing. The only thing they can show is that, in many cases, it can be done in C++ without too much difficulty or added cost, not that there is any compelling reason to do so.
On the other hand, yes, C++ is a monster, huge and tortuous language. Notice the clever way the Arduino guys never actually say that the Arduino is programmed in C++ and all their documentation and tutorials and the Arduino IDE hide a lot of C++ features that would confuse the uninitiated or lead them into trouble.
This is in an argument that recurs here quite often and is demonstrably not true. C++ can be a sensibe choice even on small systems. I would link you to previous discussions here about it but I'm too tired to start searching for them now.
Oh no! Do we have to go over this again? But at that I suppose it is better than yet another license argument!
Notice the clever way the Arduino guys never actually say that the Arduino is programmed in C++ ...
That's because it isn't - it's programmed in a cut down subset of C++ that eliminates precisely those "monstrous" bits that KC_Rob referred to - they simply won't work on such a small chip. But like Heater, I am soooo over this particular argument. It has been covered in many threads on this site, and the relevant information is also easily found via Google (it is even on the Arduino site ... but you have to search around a bit).
That's because it isn't - it's programmed in a cut down subset of C++ that eliminates precisely those "monstrous" bits that KC_Rob referred to - they simply won't work on such a small chip.
Yes, thank you.
But like Heater, I am soooo over this particular argument. It has been covered in many threads on this site, and the relevant information is also easily found via Google (it is even on the Arduino site ... but you have to search around a bit).Ross.
I'm over it too, and certainly wasn't wanting to resurrect it here. I've seen it a million times too, and in the end, it's always the same when you cut through the claptrap: That you (often) can doesn't mean that you should. The two things generally being confused.
Remember that Propeller-GCC is based on a GCC version that is GPL3 licensed and provides license exceptions for GCC libraries that are required for creating programs. It means that unlike earlier versions of GCC, there are no licensing issues with Propeller-GCC and programs you write - they can be any license you choose.
BTW: Ross, I plan to start a thread where we can discuss common C programming P1 and P2 hardware API proposals since P2 does not have directly mapped registers for all I/O pins. I hope you're up for that discussion as it would allow more portability.
Remember that Propeller-GCC is based on a GCC version that is GPL3 licensed and provides license exceptions for GCC libraries that are required for creating programs. It means that unlike earlier versions of GCC, there are no licensing issues with Propeller-GCC and programs you write - they can be any license you choose.
BTW: Ross, I plan to start a thread where we can discuss common C programming P1 and P2 hardware API proposals since P2 does not have directly mapped registers for all I/O pins. I hope you're up for that discussion as it would allow more portability.
Firstly, I'm not arguing in favour of C++ or any other language here. I seem to remember opening by saying it's a nice idea and fun to look into Spin PASM on the Prop. If only has a model of simplicity and elegance.
Secondly I don't disagree with most of what you say and have no wish to get into yet another language war.
However:
I can write structured programs in C that offer many of the advantages of object-oriented programming, ... without the headaches or bloat that comes with C++.
Yes, of course you can adopt an "object-oriented" approach in your C programming. My argument is simply that implementing a similar style program in C++ need not incur any extra cost in code size or speed. What you gain is simpler, cleaner looking code.
If you write any kind of code in C that uses "objects" I'm very sure you will end up using pointers to the properties of those object instances. If you create a similar object architecture in C++ all that happens is that those pointers become hidden and you get a convenient syntax to work with those objects. For example:
write (uart1, "some string");
might become:
uart1.write ("some string");
If you actually write out and compile some examples like this in C and C++ the generated code can end up being instruction for instruction the same!
Wish I could find my examples that I posted here a while ago.
There is not necessarily any bloat in using C++ but source code becomes clearer. That is why the Arduino uses C++ (Despite what RossH says), to simplify things for the intended users who are assumed to be programming novices.
If you have any "object oriented" programming techniques in C that are more efficient than what I'm hinting at above please do show an example I'd be very interested.
...Pure nonsense... claptrap...
Please don't be so dismissive and offensive. I'm not making my statements about the overheads (or lack of) of C++ vs C without having demonstrated the truth of them. Sorry I can't find the examples just now.
I am also not aiming to promote C++ as "the language to use", nor any other language. Use what works, suites your application and indeed suites yourself.
Firstly, I'm not arguing in favour of C++ or any other language here. I seem to remember opening by saying it's a nice idea and fun to look into Spin PASM on the Prop. If only has a model of simplicity and elegance.
Secondly I don't disagree with most of what you say and have no wish to get into yet another language war.
I certainly don't either. I made a merely tangential comment in agreement with something the OP said.
However:
Yes, of course you can adopt an "object-oriented" approach in your C programming. My argument is simply that implementing a similar style program in C++ need not incur any extra cost in code size or speed. What you gain is simpler, cleaner looking code.
I didn't say object-oriented, I merely said a structured (/modular) programming approach that offers many of the advantages without the hassle or costs; ie, an approach that is ideally suited for the type of projects and hardware capabilities I think we're talking about. Yes, I can write object-oriented code (or something very much like it) in C as well, but if, for some reason, I felt the need to do that I would just use C++ (or better still, another, cleaner OO HLL).
If you write any kind of code in C that uses "objects" I'm very sure you will end up using pointers to the properties of those object instances. If you create a similar object architecture in C++ all that happens is that those pointers become hidden and you get a convenient syntax to work with those objects. For example:
I think we're talking past each other here. For example, my C code for same might look more like:
There is not necessarily any bloat in using C++ but source code becomes clearer. That is why the Arduino uses C++ (Despite what RossH says), to simplify things for the intended users who are assumed to be programming novices.
Look, granted this is an imperfect analogy, but one close enough for our purposes. I rarely use floating point math on smaller systems. I find that I can generally get by without it just fine. Now, one can make many similar arguments for why I should use it. None are, in the end, all that compelling. Why bother when integer/fixed-point math can do the work effectively, without jumping through hoops?
Please don't be so dismissive and offensive. I'm not making my statements about...
How am I being "offensive" (and you're not)? We disagree, that is all. I've given good enough reasons for why I don't see it the same way without (intentionally) insulting or otherwise offending you or anyone else here. Moreover, the initial comment I made about C++ was relatively brief and tangential in nature (light-hearted as well). You pounced on that.
I am also not aiming to promote C++ as "the language to use", nor any other language. Use what works, suites your application and indeed suites yourself.
Please, please, there are no "C" guys here. If I have a good option that I can honestly justify, I'll use something besides C/C++. While I recognize their usefulness, and sometimes their strengths, I don't find either one to be an ideal programming language.
Perhaps I am being over sensitive but labeling someones comments as "pure nonsence" and "claptrap" is verging on the offensive. Anyway, let's skip over that. I'm all for having serious debates in a light hearted way.
Now, your example C code is exactly what I was talking about. Except you have moved the object pointer to the second parameter of your fputs() function.
I only want to point out that there is no heap used in C++ to do that kind of thing if your objects are statically instantiated. In fact experiment shows that having the object pointer as a parameter to the "method" functions in C will produce exactly the same code as allowing C++ to handle it under the hood.
That is how you can achieve a similar object style in C++ as Spin.
The floating point analogy is not in any way the same. Clearly if your processor has no floating point support the code generated will be bigger and slower if you use floating point rather than fixed point maths. However in the C vs C++ objects case the code generated can be exactly the same!
On that point I think we agree anyway. As my old boss used to say "If you think you need floating point to solve the problem you don't understand the problem":)
I will learn Spin/PASM well. If the combination will not meet my DIY projects i will try Tachyon and Catalina.
What i think i understand is, Catalina in the CMM mode would be good for larger programs that need to run faster than Spin.
Tachyon is even faster than Catalina CMM if i want to go that way with the advantage of interactive programming.
Does this seam about right. (Not absolutely right but about right.)
Regards,
rich
Rich,
It's good to hear you could pull your answer out of the fog of debate.
I agree that the Spin/PASM route is a great start. It allows you to learn the unique features of the Propeller architecture plus there are several sets of exercises and tutorials to help you learn. In addition to that, the majority of the population on the forum is Spin/PASM conversant and can help with questions and problems. Plus there are tons of examples in the OBEX, good, bad or indifferent.
If Spin/PASM do not meet the needs of your project, then you can choose the next fork in the programming road.
Most importantly, try stuff, ask questions and have fun!
Perhaps I am being over sensitive but labeling someones comments as "pure nonsence" and "claptrap" is verging on the offensive. Anyway, let's skip over that. I'm all for having serious debates in a light hearted way.
Was that directed at you personally, Heater? I think not. I can also point to how you have (on more than one occasion now) jumped on something I said in a derogatory if not derisive way.
I only want to point out that there is no heap used in C++ to do that kind of thing if your objects are statically instantiated. In fact experiment shows that having the object pointer as a parameter to the "method" functions in C will produce exactly the same code as allowing C++ to handle it under the hood.
How many C++ (or Arduino) projects do not use the heap? Not many, I suspect. You are correct on one count, though; using C++ under the hood in Arduino does provide some educational benefit for the ES programming newbies.
The floating point analogy is not in any way the same. Clearly if your processor has no floating point support the code generated will be bigger and slower if you use floating point rather than fixed point maths. However in the C vs C++ objects case the code generated can be exactly the same!
Can be, in very limited circumstances that almost no one uses, nor is there any overriding reason to use. In addition, the amount of overhead for floating point is likewise controllable (eg, use floating point without std formatted IO). So, yes, the admittedlyimperfect analogy does hold.
On that point I think we agree anyway. As my old boss used to say "If you think you need floating point to solve the problem you don't understand the problem":)
Opinions are like ....
Some are well formed, others a bit loose.
Some are just marketing.
What works, as always, depends on your individual perspective.
Some you are with for better or worse, until death do you part....which may be a good thing or a bad thing....my personal opinion on that is it's a good thing!
Comments
Ouch!
H
Not really. It's a natural consequence of C being very much on the lower end of the high-level language spectrum. C is really only a few steps up from assembler, and gets used for work that would previously have been done in assembler. 100% of an assembler program is non-portable. C does much better - maybe only 5% of your typical C program is non-portable ... but it does tend to be the tricky stuff.
Ross.
Past tense? (Some of us still do.
-Phil
A lot of the advanced code we're going to want to use is GPL and it would be breaking the rules to say it's MIT...
Most of the advanced codes I've seen in the wild have a GPL license...
I'll second (third, whatever) what others have said and recommend that you start with Spin/PASM and the PropTool. Take it from a fellow Propeller newbie: that's the best way to get up and running with the chip. And more than likely you'll be able to do your initial projects with that alone. Then, later on, if needed you can move to C, or Tachyon Forth (very nice!), or something more exotic. (Maybe by then someone will have made a nice Pascal tool-chain for Prop, comparable to, say, AVRco for AVRs.:) )
No, but in my experience, in the C world you would generally want to check in a much larger "chunk" of code than is true in the Spin world - e.g. a whole program or library, rather than just a code snippet (and for goodness sake, let's not get started on just what constitutes an "object" here!). In the C world such chunks would very often contain at least some code that is not MIT licensed (it would usually be GPL, but it could contain various other "free" licences as well).
That's kind of the point of using C in the first place - you can easily adapt masses of existing C code, from many different sources. Catalina itself is a good example of what can be achieved by doing so - it contains various chunks of "free" C code taken from a whole bunch of places. For most non-commercial purposes the licenses of code you find on the internet are "free", fully compatible and you don't need to worry about them at all (of course you would have to worry for software developed for commercial purposes, but not many people would want to put such software in the OBEX, so that doesn't really matter here **).
But who is going to go to the bother of tear their 10,000 line C program into separately licensed chunks just to be able to submit some portion of it to the OBEX?
Ross.
** Footnote for Catalina users: I have checked the licensing of all parts of Catalina to make sure that programs developed with Catalina are free of problematic license restrictions - e.g. all the library code is freely re-usable. However, this is not true of Catalina itself, since it is based on various components that are not free of such license restrictions (e.g. LCC). This means is that you can sell a product compiled with Catalina, but not a product that itself contains parts of Catalina (other than compiled versions of the library code, of course).
Blast! I didn't want to get yet another thread derailed into a discussion about licensing! :frown:
This is in an argument that recurs here quite often and is demonstrably not true. C++ can be a sensibe choice even on small systems. I would link you to previous discussions here about it but I'm too tired to start searching for them now.
But do note that:
1) C++ is the language of the Arduino. How small are we wanting to talk about?
2) C++ enables you to construct a program from objects that look extremely similar to the object architecture of Spin programs.
3) There is no overhead in using C++ to do this as opposed to C but the syntax looks a lot nicer.
On the other hand, yes, C++ is a monster, huge and tortuous language. Notice the clever way the Arduino guys never actually say that the Arduino is programmed in C++ and all their documentation and tutorials and the Arduino IDE hide a lot of C++ features that would confuse the uninitiated or lead them into trouble.
I can write structured programs in C that offer many of the advantages of object-oriented programming, more than enough for what I'm doing in a small space, without the headaches or bloat that comes with C++. Moreover, object-oriented isn't the only programming pardigm, or often times the one best suited for specific embedded projects. So, for Propeller coding, if Spin wasn't an option (I guess speed of execution being the issue), I'd go with C (or...?). And in terms of just programming objects, Spin seems to me a much cleaner way of doing that.
As opposed to ... what? Programming an ATmega8515 to perform some basic functions (run an LCD, accept switch presses, read a sensor, and control, say, a heater)? I can do all that without worrying about a heap, etc., with code written in a very clean and maintainable form of C, at less cost and with less headache. And it's not as though C++ could gain me any big advantage in coding time or portability, either; certainly nothing like what I get moving from assembly to C. Why, then, would anyone think that C++ is better suited for such things? Pure nonsense. You could show me a hundred threads (and I've probably seen 'em anyway) and not one will clearly demonstrate any such thing. The only thing they can show is that, in many cases, it can be done in C++ without too much difficulty or added cost, not that there is any compelling reason to do so.
I rest my case.
Oh no! Do we have to go over this again? But at that I suppose it is better than yet another license argument!
That's because it isn't - it's programmed in a cut down subset of C++ that eliminates precisely those "monstrous" bits that KC_Rob referred to - they simply won't work on such a small chip. But like Heater, I am soooo over this particular argument. It has been covered in many threads on this site, and the relevant information is also easily found via Google (it is even on the Arduino site ... but you have to search around a bit).
Ross.
I'm over it too, and certainly wasn't wanting to resurrect it here. I've seen it a million times too, and in the end, it's always the same when you cut through the claptrap: That you (often) can doesn't mean that you should. The two things generally being confused.
BTW: Ross, I plan to start a thread where we can discuss common C programming P1 and P2 hardware API proposals since P2 does not have directly mapped registers for all I/O pins. I hope you're up for that discussion as it would allow more portability.
No worries.
Ross.
Firstly, I'm not arguing in favour of C++ or any other language here. I seem to remember opening by saying it's a nice idea and fun to look into Spin PASM on the Prop. If only has a model of simplicity and elegance.
Secondly I don't disagree with most of what you say and have no wish to get into yet another language war.
However:
Yes, of course you can adopt an "object-oriented" approach in your C programming. My argument is simply that implementing a similar style program in C++ need not incur any extra cost in code size or speed. What you gain is simpler, cleaner looking code.
If you write any kind of code in C that uses "objects" I'm very sure you will end up using pointers to the properties of those object instances. If you create a similar object architecture in C++ all that happens is that those pointers become hidden and you get a convenient syntax to work with those objects. For example:
write (uart1, "some string");
might become:
uart1.write ("some string");
If you actually write out and compile some examples like this in C and C++ the generated code can end up being instruction for instruction the same!
Wish I could find my examples that I posted here a while ago.
There is not necessarily any bloat in using C++ but source code becomes clearer. That is why the Arduino uses C++ (Despite what RossH says), to simplify things for the intended users who are assumed to be programming novices.
If you have any "object oriented" programming techniques in C that are more efficient than what I'm hinting at above please do show an example I'd be very interested. Please don't be so dismissive and offensive. I'm not making my statements about the overheads (or lack of) of C++ vs C without having demonstrated the truth of them. Sorry I can't find the examples just now.
I am also not aiming to promote C++ as "the language to use", nor any other language. Use what works, suites your application and indeed suites yourself.
You C guys bicker as if you were forth guys
I think recently we've learned that C bickering is more portable than Forth bickering!
I love you guys. Thank you for that.
I didn't say object-oriented, I merely said a structured (/modular) programming approach that offers many of the advantages without the hassle or costs; ie, an approach that is ideally suited for the type of projects and hardware capabilities I think we're talking about. Yes, I can write object-oriented code (or something very much like it) in C as well, but if, for some reason, I felt the need to do that I would just use C++ (or better still, another, cleaner OO HLL).
I think we're talking past each other here. For example, my C code for same might look more like:
static FILE serial0 = FDEV_SETUP_STREAM(uart0_putchar, NULL, _FDEV_SETUP_WRITE); // NO HEAP!!
fputs("some string", serial0);
(or something even more basic)
Look, granted this is an imperfect analogy, but one close enough for our purposes. I rarely use floating point math on smaller systems. I find that I can generally get by without it just fine. Now, one can make many similar arguments for why I should use it. None are, in the end, all that compelling. Why bother when integer/fixed-point math can do the work effectively, without jumping through hoops?
How am I being "offensive" (and you're not)? We disagree, that is all. I've given good enough reasons for why I don't see it the same way without (intentionally) insulting or otherwise offending you or anyone else here. Moreover, the initial comment I made about C++ was relatively brief and tangential in nature (light-hearted as well). You pounced on that.
Exactly what I'm saying too.
No need to debate C/C++ merits.
I will learn Spin/PASM well. If the combination will not meet my DIY projects i will try Tachyon and Catalina.
What i think i understand is, Catalina in the CMM mode would be good for larger programs that need to run faster than Spin.
Tachyon is even faster than Catalina CMM if i want to go that way with the advantage of interactive programming.
Does this seam about right. (Not absolutely right but about right.)
Regards,
rich
Perhaps I am being over sensitive but labeling someones comments as "pure nonsence" and "claptrap" is verging on the offensive. Anyway, let's skip over that. I'm all for having serious debates in a light hearted way.
Now, your example C code is exactly what I was talking about. Except you have moved the object pointer to the second parameter of your fputs() function.
I only want to point out that there is no heap used in C++ to do that kind of thing if your objects are statically instantiated. In fact experiment shows that having the object pointer as a parameter to the "method" functions in C will produce exactly the same code as allowing C++ to handle it under the hood.
That is how you can achieve a similar object style in C++ as Spin.
The floating point analogy is not in any way the same. Clearly if your processor has no floating point support the code generated will be bigger and slower if you use floating point rather than fixed point maths. However in the C vs C++ objects case the code generated can be exactly the same!
On that point I think we agree anyway. As my old boss used to say "If you think you need floating point to solve the problem you don't understand the problem":)
Rich,
It's good to hear you could pull your answer out of the fog of debate.
I agree that the Spin/PASM route is a great start. It allows you to learn the unique features of the Propeller architecture plus there are several sets of exercises and tutorials to help you learn. In addition to that, the majority of the population on the forum is Spin/PASM conversant and can help with questions and problems. Plus there are tons of examples in the OBEX, good, bad or indifferent.
If Spin/PASM do not meet the needs of your project, then you can choose the next fork in the programming road.
Most importantly, try stuff, ask questions and have fun!
How many C++ (or Arduino) projects do not use the heap? Not many, I suspect. You are correct on one count, though; using C++ under the hood in Arduino does provide some educational benefit for the ES programming newbies.
Can be, in very limited circumstances that almost no one uses, nor is there any overriding reason to use. In addition, the amount of overhead for floating point is likewise controllable (eg, use floating point without std formatted IO). So, yes, the admittedly imperfect analogy does hold.
Yep.
Some are well formed, others a bit loose.
Some are just marketing.
What works, as always, depends on your individual perspective.
Some you are with for better or worse, until death do you part....which may be a good thing or a bad thing....my personal opinion on that is it's a good thing!