Based on my experience teaching a robotics class for the past several months, I've come to the conclusion that GCC is way more "machinery" than is needed for teaching the amount of C required to do the work. What I propose -- and what would save an enormous amount of redundant library-coding effort in the long run -- is a stripped-down (and lightly-augmented to be object-aware) version of C that compiles to Spin byte codes and can use Spin objects. This is really all that is needed for education. Students do not need pointers to functions, memory-model awareness, or a bunch of other crufty esoterica to complete an effective robotics curriculum. I know that C purists will balk at the object-aware part, but it would be a very minor diversion from Standard C. The objective, of course, is productivity in teaching, in learning, and in library creation and maintenance -- not in reciting the catechism of Standard C or delving minutely into its finer theological mysteries. Save the latter for a PC programming class instead of one devoted to microcontrollers and/or robotics.
Based on my experience teaching a robotics class for the past several months, I've come to the conclusion that GCC is way more "machinery" than is needed
I can see very clearly that the normal "machinery" of using GCC, or any other C/C++ compiler is a road block in introducing anyone to the world of programming.
Some how the Arduino guy's have worked around that problem. Millions of Arduino users are writing C++ code and they don't even know it!
I can see very clearly that the normal "machinery" of using GCC, or any other C/C++ compiler is a road block in introducing anyone to the world of programming. Some how the Arduino guy's have worked around that problem. ...
To give credit where credit is due, so has Steve (jazzed) with SimpleIDE, which hides most of the nasty makefile stuff. It's kinda like UPS: when everything goes smoothly, stuff gets delivered on time; but throw in a bad zip code (i.e. a glitch or slight misconfiguration), then you have to be more hands-on to make everything turn out allright. IOW, there's still a wolf in that sheep's clothing.
It's a dilemma, really. Educators demand C because they think it will be valuable to their students once they leave school. That's the vocational approach. OTOH, there are those like me who want a language like Spin that paves the way to project completion, while still teaching algortithmic fundamentals. That's the liberal arts approach. The issue I have with the vocational approach in a robotics curriculum at least is that the C that's being learned to solve basic robotics problems, given a library of functions, is not really C in all its ugly glory, but just a nested loop or two, some conditionals, a bunch of function calls, and very little else. So, given that they're not really learning C, why not teach a language that's friendlier for beginning programmers, which most of my students are?
I can tell you, though, that educators (That includes teachers and administrators.) who've never written a line of code will still recite the C mantra, and that's the call that Parallax has had to answer.
Based on my experience teaching a robotics class for the past several months, I've come to the conclusion that GCC is way more "machinery" than is needed for teaching the amount of C required to do the work. What I propose -- and what would save an enormous amount of redundant library-coding effort in the long run -- is a stripped-down (and lightly-augmented to be object-aware) version of C that compiles to Spin byte codes and can use Spin objects. This is really all that is needed for education. Students do not need pointers to functions, memory-model awareness, or a bunch of other crufty esoterica to complete an effective robotics curriculum. I know that C purists will balk at the object-aware part, but it would be a very minor diversion from Standard C. The objective, of course, is productivity in teaching, in learning, and in library creation and maintenance -- not in reciting the catechism of Standard C or delving minutely into its finer theological mysteries. Save the latter for a PC programming class instead of one devoted to microcontrollers and/or robotics.
-Phil
I don't understand the point of this suggestion. If you're willing to use a modified version of C you may as well just use Spin. Your modified C isn't really C anyway.
It doesn't matter. Call it "RoboC" if you like. As long as it's a usable subset of C, with a minor tweak to permit calling Spin object methods, it will be C enough for the classroom and satisfy those educators who demand C. Plus, you get the advantage of not having to write the low-level "Learn" libraries twice.
What matters in a clasroom situation is efficiency -- getting the kids from A to Z in the very limited face time that's scheduled. The classroom is no place for linguistic purism if it inhibits learning.
It doesn't matter. Call it "RoboC" if you like. As long as it's a usable subset of C, with a minor tweak to permit calling Spin object methods, it will be C enough for the classroom and satisfy those educators who demand C. Plus, you get the advantage of not having to write the low-level "Learn" libraries twice.
What matters in a clasroom situation is efficiency -- getting the kids from A to Z in the very limited face time that's scheduled. The classroom is no place for linguistic purism if it inhibits learning.
-Phil
Are you suggesting that Parallax abandon PropGCC and instead develop this RoboC? If not then they will still have to develop the "Learn Libraries" twice, once for PropGCC and the second time for Spin/RoboC. If you're really talking about just a subset then there is no reason not to just use PropGCC and teach the subset. This is similar to what the Arduino people are doing with C++. They have a full C++ compiler under the hood but they've added some syntactic sugar on the surface to make C++ a little more appealing to novices. Whether it actually achieves that goal is a matter of opinion.
PropGCC may well have commercial applicaitons with the Propeller, although Ken indicates that Spin/PASM is, so far, the favored choice. But those who prefer C for those apps will likely not be interested in AcitivityBot stuff. So there would be no reason to duplicate Learn library efforts there between PropGCC and RoboC. Ken has plainly stated that there are not enough resources under Parallax's roof to create parallel C and Spin Learn libraries. If RoboC had access to the Spin library version, that would save future duplications of effort. Of course, there's a huge front-end load to this scheme. But I'm taking a longer view than just the preliminary set-up cost.
So I guess my short answer is eventually to abandon PropGCC for educational purposes and concentrate on its commercial apps, because there will certainly be more for the Prop 2 when it becomes available. This might mean leaving PropGCC behind altogether for the P1 if commercial users continue to prefer Spin/PASM.
So do I think the PropGCC effort has been wasted? No, of course not! If P1 commercial users want it, it's there. If P2 commercial users want it, and I'm sure they will, the work that's already been done will only make the transition easier.
BTW, I'm basing a lot of my comments on my experience with NQC (not quite C) for Lego Mindstorms. Even I, an unreformed anti-C bigot, liked using it.
PropGCC may well have commercial applicaitons with the Propeller, although Ken indicates that Spin/PASM is, so far, the favored choice. But those who prefer C for those apps will likely not be interested in AcitivityBot stuff. So there would be no reason to duplicate Learn library efforts there between PropGCC and RoboC. Ken has plainly stated that there are not enough resources under Parallax's roof to create parallel C and Spin Learn libraries. If RoboC had access to the Spin library version, that would save future duplications of effort. Of course, there's a huge front-end load to this scheme. But I'm taking a longer view than just the preliminary set-up cost.
So I guess my short answer is eventually to abandon PropGCC for educational purposes and concentrate on its commercial apps, because there will certainly be more for the Prop 2 when it becomes available. This might mean leaving PropGCC behind altogether for the P1 if commercial users continue to prefer Spin/PASM.
So do I think the PropGCC effort has been wasted? No, of course not! If P1 commercial users want it, it's there. If P2 commercial users want it, and I'm sure they will, the work that's already been done will only make the transition easier.
BTW, I'm basing a lot of my comments on my experience with NQC (not quite C) for Lego Mindstorms. Even I, an unreformed anti-C bigot, liked using it.
-Phil
If your main goal is to avoid duplicating effort between Spin and C in the creation of libraries then another solution would be to create all libraries for C and then make use of them from Spin by way of spin2cpp. Those who like a simpler language can code in Spin but still take advantage of the C libraries created for both education and professional/hobbyist use. This has the advantage that the libraries would perform better being coded in a compiled language.
The Arduino approach is a preprocessor that turns sketches into something the avr gcc compiler can compile. That's something that could be done for an educational environment with the prop.
So the kids can write proper C code in their functions, but the preprocessor can handle making sure it's all wrapped in the proper stuff to make it compilable. SimpleIDE already does a fair amount of this, it should just be taken a little further.
As for the Spin version of stuff, I believe it's just a matter of resources for Parallax. If someone here want's to provide the Spin version of all the LEARN content that is currently only in C, then I am sure Ken would be happy to get it put up on the LEARN site. You'd have to be patient with them on that part though too, since they only have so much resource available to update and add to the website.
Dave, to me, translating from Spin to C++ is a backward step, since Spin/PASM is the Prop's native language. It's like translating from English to Latin and back again. Going directly from Latin to English makes much more sense.
Roy, what I'm saying is that the Spin/PASM version of the Learn library could be all that is necessary -- no C code or additional resources required, once the initial speed bump has been breached. Parallax can then relax and continue to contribute with the resources they already have.
GCC, quite frankly, is a bad fit for Parallax's educational mission, given their available resources. It's like providing a six-speed stick-shift Maserati to beginning drivers, when a C minibus bolted onto a Spin chassis would do the job more simply and effectively. This is no hypothetical; it comes from my direct experience in the trenches.
Phil,
Except that Parallax's education customers demand C. I don't think Parallax would have done any of the C work if not for the demand from it's education customers for it.
... I don't think Parallax would have done any of the C work if not for the demand from it's education customers for it.
That's what I've suspected all along. Then why the heck have we burdened them with the full-on might of GCC and its myriad memory models when C-Lite+ with links to extant Spin object libraries would have sufficed? The historical trajectory that's brought us to this point appears to be missing some key logic along the way. What am I missing here? Can you fill me in, please?
Phil,
It largely comes down to resources. Parallax didn't (and still doesn't) have the internal resources. They got GCC because of a few external people contributing to make it happen. It got them a solution, maybe it wasn't the most optimal solution in your opinion, but it's a solution. I think GCC on the prop is a fine solution to have around, but I agree with you that a friendlier/simpler level needs to be there for introducing it to new learners. I believe Parallax has been working towards that goal with the SimpleLibrary stuff and the LEARN site and SimpleIDE. It's just a matter of time/resources to get it the little bit farther along.
Your explanation makes sense. Writing a compiler from scratch is no mean feat. Though not exactly low-hanging fruit, the ready availability of GCC did simplify things for the dev team. It's just unfortunate that going that route has entailed duplication of effort on the library front.
If all you want to do is use Spin objects in C, it is possible with David's spinwrap program - it is superior to anything else I've seen so far. All that needs to be done is include that in the SimpleIDE build process.
However, I don't think there is any way to satisfy you because your hatred for C has left you snow-blind.
Dave, to me, translating from Spin to C++ is a backward step, since Spin/PASM is the Prop's native language. It's like translating from English to Latin and back again. Going directly from Latin to English makes much more sense.
Spin is not the native language of the Propeller, PASM is. PropGCC can compile directly to PASM or it can generate LMM code which is just PASM executed from hub memory. So you could say that PropGCC is closer to a native language for the Propeller than Spin is since Spin only generates bytecodes. The fact that there happens to be a Spin bytecode interpreter in ROM is the only thing that makes Spin any more native to the Propeller than C.
That's what I've suspected all along. Then why the heck have we burdened them with the full-on might of GCC and its myriad memory models when C-Lite+ with links to extant Spin object libraries would have sufficed? The historical trajectory that's brought us to this point appears to be missing some key logic along the way. What am I missing here? Can you fill me in, please?
Thanks,
-Phil
I don't see why having lots of options makes something difficult to use. Maybe the problem is that SimpleIDE exposes too many of those options to the educational user. Maybe there should be an student version that always compiles in CMM mode and hence requires no special board configuration. There is no need to dumb down the language itself to present a simplified version to the student.
So you could say that PropGCC is closer to a native language for the Propeller than Spin is since Spin only generates bytecodes.
"... only generates bytecodes." Only? I'm not convinced that bytecodes are not the most efficient use of hub RAM for top-level execution. C programs always seem to entail more memory bloat than their equivalent Spin programs. One might argue that C programs are faster, since they compile to PASM or LMM. But for educational programs, that does not matter.
IMO, the ideal situation for educational use would be a compiler that compiles C to Spin bytecodes and that allows C programs to call Spin library methods directly, without having to translate them to C++ first and then back again to PASM. This, of course, would entail breaking Standard C a little bit. But, again, who cares? It does not matter.
IMO, the ideal situation for educational use would be a compiler that compiles C to Spin bytecodes and that allows C programs to call Spin library methods directly, without having to translate them to C++ first and then back again to PASM.
It has been pointed out before that the SPIN bytecodes are not very good for efficiently encoding C programs (and the keyword here is efficiently - yes, they are both Turing Complete languages and therefore each language could be implemented in the other - but not efficiently). To use the Spin bytecodes reasonably efficiently, you would have to limit yourself to a small subset of C - one that would not be much more than SPIN with curly brackets.
"... only generates bytecodes." Only? I'm not convinced that bytecodes are not the most efficient use of hub RAM for top-level execution. C programs always seem to entail more memory bloat than their equivalent Spin programs. One might argue that C programs are faster, since they compile to PASM or LMM. But for educational programs, that does not matter.
IMO, the ideal situation for educational use would be a compiler that compiles C to Spin bytecodes and that allows C programs to call Spin library methods directly, without having to translate them to C++ first and then back again to PASM. This, of course, would entail breaking Standard C a little bit. But, again, who cares? It does not matter.
-Phil
I didn't say bytecodes aren't a good idea for code density. I'm just saying they aren't "native to the Propeller" other than that there is a Spin bytecode interpreter in ROM. The CMM memory model in PropGCC is probably the best choice for boards that don't have external memory and it essentially uses bytecodes. I think, if you look back in the forum discussions, you'll find that Parallax considered implementing a simple subset of C using Spin bytecodes but for some reason abandoned the project. I thought about it myself but was put off by the fact that the Spin bytecodes are not documented very well. In fact, they aren't documented at all by Parallax. Yes, I know that the source code for the Spin bytecode interpreter is available but I don't want to have to pour through that to figure out how the instruction set works. If there had been a good document describing it then there might be a C-to-Spin-bytecode compiler by now. It would be slower than PropGCC CMM mode though.
It has been pointed out before that the SPIN bytecodes are not very good for efficiently encoding C programs (and the keyword here is efficiently - yes, they are both Turing Complete languages and therefore each language could be implemented in the other - but not efficiently). To use the Spin bytecodes reasonably efficiently, you would have to limit yourself to a small subset of C - one that would not be much more than SPIN with curly brackets.
I'm not sure what you mean by "efficiently". Spin bytecodes are very compact, so they are quite efficient in that sense. I assume you are referring to execution speed, and it's true that Spin does execute slowly. However, a C program compiled to byte-codes wouldn't be any slower than a Spin program. There is no need to limit a C-to-Spin-bytecode compiler to a subset of C. cspin handles C structs, and I am currently adding the ability to handle multi-dimensional arrays, function pointers and the conditional assignment statement. This is converted into Spin source, which can then be compiled into bytecodes.
I see the following at the beginning of this thread and I have to wonder the following:
a. Is this really true?
My impression is that SPIN would always be around at least to provide the means to load PASM. And as I read further into the thread, it seems to be Ken Gracey's opinion as well.
@Heater
Try being informative about Parallax policy rather than just dumping a rather bombastic personal opinion that is likely to confound new comers.
I'm not sure what you mean by "efficiently". Spin bytecodes are very compact, so they are quite efficient in that sense. I assume you are referring to execution speed, and it's true that Spin does execute slowly. However, a C program compiled to byte-codes wouldn't be any slower than a Spin program. There is no need to limit a C-to-Spin-bytecode compiler to a subset of C. cspin handles C structs, and I am currently adding the ability to handle multi-dimensional arrays, function pointers and the conditional assignment statement. This is converted into Spin source, which can then be compiled into bytecodes.
I admire your perseverance, Dave. But your resulting "Spin bytecode" C programs will execute slower even than CMM (the slowest C currently implemented on the Propeller). And they will probably end up larger as well.
Try being informative about Parallax policy rather than just dumping a rather bombastic personal opinion that is likely to confound new comers.
Try to read and comprehend what I write
In the very next post there, after all of 10 minutes, I write "To be less flippant. Spin is not going anywhere as it's built into the Propeller." So clearly if the humour is not recognized immediately I even spell it out for you.
In the rest of that post you see that I totally agree with you and make much the same statements.
Comments
-Phil
I understand your point and I can only imagine how frustrating that must be. Spin versus C = Easy versus Hard.
Some how the Arduino guy's have worked around that problem. Millions of Arduino users are writing C++ code and they don't even know it!
-Phil
That's really funny to me because I've been working on "zip code" all day today.
So, what to do when things go wrong?
For this reason we had BASIC back in the day.
For this reason we have JavaScript today:
http://www.espruino.com/
http://https://tessel.io/
Kids should not be worrying about this bit or that. Let them make something that works.
If they are curious they will scatch their heads and wonder about the bits.
It's a dilemma, really. Educators demand C because they think it will be valuable to their students once they leave school. That's the vocational approach. OTOH, there are those like me who want a language like Spin that paves the way to project completion, while still teaching algortithmic fundamentals. That's the liberal arts approach. The issue I have with the vocational approach in a robotics curriculum at least is that the C that's being learned to solve basic robotics problems, given a library of functions, is not really C in all its ugly glory, but just a nested loop or two, some conditionals, a bunch of function calls, and very little else. So, given that they're not really learning C, why not teach a language that's friendlier for beginning programmers, which most of my students are?
I can tell you, though, that educators (That includes teachers and administrators.) who've never written a line of code will still recite the C mantra, and that's the call that Parallax has had to answer.
-Phil
What matters in a clasroom situation is efficiency -- getting the kids from A to Z in the very limited face time that's scheduled. The classroom is no place for linguistic purism if it inhibits learning.
-Phil
So I guess my short answer is eventually to abandon PropGCC for educational purposes and concentrate on its commercial apps, because there will certainly be more for the Prop 2 when it becomes available. This might mean leaving PropGCC behind altogether for the P1 if commercial users continue to prefer Spin/PASM.
So do I think the PropGCC effort has been wasted? No, of course not! If P1 commercial users want it, it's there. If P2 commercial users want it, and I'm sure they will, the work that's already been done will only make the transition easier.
BTW, I'm basing a lot of my comments on my experience with NQC (not quite C) for Lego Mindstorms. Even I, an unreformed anti-C bigot, liked using it.
-Phil
So the kids can write proper C code in their functions, but the preprocessor can handle making sure it's all wrapped in the proper stuff to make it compilable. SimpleIDE already does a fair amount of this, it should just be taken a little further.
As for the Spin version of stuff, I believe it's just a matter of resources for Parallax. If someone here want's to provide the Spin version of all the LEARN content that is currently only in C, then I am sure Ken would be happy to get it put up on the LEARN site. You'd have to be patient with them on that part though too, since they only have so much resource available to update and add to the website.
Roy, what I'm saying is that the Spin/PASM version of the Learn library could be all that is necessary -- no C code or additional resources required, once the initial speed bump has been breached. Parallax can then relax and continue to contribute with the resources they already have.
GCC, quite frankly, is a bad fit for Parallax's educational mission, given their available resources. It's like providing a six-speed stick-shift Maserati to beginning drivers, when a C minibus bolted onto a Spin chassis would do the job more simply and effectively. This is no hypothetical; it comes from my direct experience in the trenches.
-Phil
Except that Parallax's education customers demand C. I don't think Parallax would have done any of the C work if not for the demand from it's education customers for it.
Thanks,
-Phil
It largely comes down to resources. Parallax didn't (and still doesn't) have the internal resources. They got GCC because of a few external people contributing to make it happen. It got them a solution, maybe it wasn't the most optimal solution in your opinion, but it's a solution. I think GCC on the prop is a fine solution to have around, but I agree with you that a friendlier/simpler level needs to be there for introducing it to new learners. I believe Parallax has been working towards that goal with the SimpleLibrary stuff and the LEARN site and SimpleIDE. It's just a matter of time/resources to get it the little bit farther along.
Your explanation makes sense. Writing a compiler from scratch is no mean feat. Though not exactly low-hanging fruit, the ready availability of GCC did simplify things for the dev team. It's just unfortunate that going that route has entailed duplication of effort on the library front.
-Phil
If all you want to do is use Spin objects in C, it is possible with David's spinwrap program - it is superior to anything else I've seen so far. All that needs to be done is include that in the SimpleIDE build process.
However, I don't think there is any way to satisfy you because your hatred for C has left you snow-blind.
IMO, the ideal situation for educational use would be a compiler that compiles C to Spin bytecodes and that allows C programs to call Spin library methods directly, without having to translate them to C++ first and then back again to PASM. This, of course, would entail breaking Standard C a little bit. But, again, who cares? It does not matter.
-Phil
It has been pointed out before that the SPIN bytecodes are not very good for efficiently encoding C programs (and the keyword here is efficiently - yes, they are both Turing Complete languages and therefore each language could be implemented in the other - but not efficiently). To use the Spin bytecodes reasonably efficiently, you would have to limit yourself to a small subset of C - one that would not be much more than SPIN with curly brackets.
Ross.
Don't let Chip hear you say that!
Ross.
I see the following at the beginning of this thread and I have to wonder the following:
a. Is this really true?
My impression is that SPIN would always be around at least to provide the means to load PASM. And as I read further into the thread, it seems to be Ken Gracey's opinion as well.
@Heater
Try being informative about Parallax policy rather than just dumping a rather bombastic personal opinion that is likely to confound new comers.
I admire your perseverance, Dave. But your resulting "Spin bytecode" C programs will execute slower even than CMM (the slowest C currently implemented on the Propeller). And they will probably end up larger as well.
Ross.
Try to read and comprehend what I write
In the very next post there, after all of 10 minutes, I write "To be less flippant. Spin is not going anywhere as it's built into the Propeller." So clearly if the humour is not recognized immediately I even spell it out for you.
In the rest of that post you see that I totally agree with you and make much the same statements.