C on P1 can be a hard sell compared to SPIN+PASM for a lot of reasons.
Thanks for all of your comments. I'm afraid I don't have time to reply to them all but I wanted to ask about this one. Could you explain why you think that C on the P1 is a hard sell?
From my point-of-view, I see the stereotypical C smugness toward any language that is not C.
From my point of view it is the reverse. It's hard to get anyone here to acknowledge that there might be any value an any language other than Spin. I think the smugness is on the Spin side not the C side. I have used Spin myself and acknowledge that it has many strengths. As well, I realize that C has some weaknesses and I certainly won't claim that it is the best language ever invented. My interest in C is simply that I can write a program on one computer and run it on another. I know many people here will say that there is no such thing as a portable program but it just isn't true. What is true is that most programs require a bit of effort to port, many require a fair amount of effort, and some can't be practially ported at all. For me, those are in the minority and I've been quite successful porting large programs from one machine to another with minimal changes even going from 8 bit to 16 bit to 32 bit processors. I don't get that with Spin. If I want to reuse code I've written in the past I have to completely rewrite it in Spin and it isn't always easy to map from other languages to Spin. This is why I generally choose C. If I was writing something that I knew I would never want to run on any other processor I might very well choose Spin instead. As may be obvious from my comments on Forth and Basic and various other languages, I'm a language junky and can find something I like about almost any language. I don't think smug applies.
Thanks for all of your comments. I'm afraid I don't have time to reply to them all but I wanted to ask about this one. Could you explain why you think that C on the P1 is a hard sell?
An OBEX FULL of Spin/PASM objects for making the P1 do some amazing things compared to a very limited set of C library routines implementing a very few of those OBEX objects.
An active hobbyist(and professional) community that is continuing to create amazing things with Spin/PASM.
An active HOBBYIST(and professional) community that doesn't really want to retool from something they are productive (personally and financially) with and lose fun, productivity, creativity and money in the process.
A LARGE number of Parallax products that provide Spin examples and demos when you go to their product pages looking for examples.
An excellent PEK document that is all about Spin and PASM.
An excellent P1 product manual that is all about Spin and PASM.
It's unfair(DUMB) to tell a new user that finds the Propeller and possibly a companion product or interesting OBEX object (or project someone else did) that is a Mac or Linux user either, "sorry, the PropTool is Windows only" or "well, here's SimpleIDE which can do Spin but look, it also does C!!!! No, we don't have theat OBEX object in C or a demo for that product in C....but look, SImpleIDE really makes it possible to do C on the Propeller!"
An OBEX FULL of Spin/PASM objects for making the P1 do some amazing things compared to a very limited set of C library routines implementing a very few of those OBEX objects.
Exactly. Right now, the P2 is going to be a sequel to a movie too few people have seen.
I'm not against C at all, in fact, I'm quite for it as I think it serves Parallax's long and short-term interests. That said, development of a C compiler for the Propeller should not push a nice, simple, cross-platform tool for Spin/PASM to the side. The key is give customs easy access to the Propeller -- on their favorite platform. At the Hackaday event last week I asked an Arduino user if he'd ever considered using the Propeller. His response? "What's a Propeller?"
Get people hooked on the coolness of the hardware, then give them choices -- which in the Propeller world are wildly varied (Spin, BASIC, C, Forth).
Steps I think would help:
-- create a nice, simple, x-platform tool for the Propeller (Spin/PASM) -- the xBasic IDE is nearly there.
-- port the [wonderful, and fully vetted by educators] Stamps In Class materials to the Propeller (Spin and C variants)
Well, I guess I sidetracked this discussion to a discussion about why long-time forum users aren't more supportive of Parallax's efforts in C. None of what I said was meant to imply that we should sidetrack Spin. In fact, I'd be willing to offer to help update SimpleIDE and/or the xbasic IDE to better support Spin. I fully agree that Spin should be offered on equal footing to C. However, I think Parallax deserves some support in their efforts to promote the Propeller into educational environments where C is mandated. In that case it isn't a matter of which language is better. That choice has already been made by someone outside of Parallax and these forums. But it would be helpful if people who are introduces to the Propeller that way could find support here rather than being told to abandon C and move to Spin. This anti-C sentiment on the forums could derail Parallax's efforts to make headroads into these educational settings.
There are two kinds of obstacles that can impede productivity: roadblocks and speedbumps. A roadblock is a one-time thing that, once passed, becomes irrelevant. An example would be the learning curve for a new language, such as Spin. Speedbumps are the things we encounter and that slow us down every day. Examples include syntactical gingerbread and things like prototypes that exist only to save the compiler writer from having to include an extra pass.
I'm not anti-C. Heaven knows the language I came from to learn Spin (Perl) is more convoluted than C, and I still like it. But it has its place, as does C. It's just that I don't think the Propeller is one of those places, especially given the far more hardware-appropriate language already tailored for it. It's okay for Parallax to use C as bait to lure new customers to the Propeller, but once that door is open, even more effort should be expended to steer those same customers to Spin. Once they've passed that roadblock they will no longer have to endure the Chinese water torture embodied by braces, semicolons, prototypes, and header files, and they can start just writing code and being productive.
So I guess I respectfully disagree with Jon that C is good for Parallax's long-term objectives -- at least not beyond the shorter term goal of chumming the sea of C programmers closer to the boat.
Well, I guess I sidetracked this discussion to a discussion about why long-time forum users aren't more supportive of Parallax's efforts in C. None of what I said was meant to imply that we should sidetrack Spin. In fact, I'd be willing to offer to help update SimpleIDE and/or the xbasic IDE to better support Spin. I fully agree that Spin should be offered on equal footing to C. However, I think Parallax deserves some support in their efforts to promote the Propeller into educational environments where C is mandated. In that case it isn't a matter of which language is better. That choice has already been made by someone outside of Parallax and these forums. But it would be helpful if people who are introduces to the Propeller that way could find support here rather than being told to abandon C and move to Spin. This anti-C sentiment on the forums could derail Parallax's efforts to make headroads into these educational settings.
OK, here's the original Posting that triggered Heater's question at the beginning of this thread:
Hi all,
I want to programm my Parallax Propeller with MacOS.
I recently found the BST Propeller Suite from Brad Campell.
I downloaded bst-0.19.3.osx.zip, unzip and run the application. But if I select a spin file for open, no source window appears.
There is only the menu bar visible.
Is there a trick to use bst on 10.6.8?
I also tried the following versions:
bst-0.19.2-Pre1.osx.zip
bst-0.19.4-pre12.osx.zip
bst-0.19.4-pre13.osx.zip
bst-0.19.4-pre14.osx.zip
But no success at all.
Thank you for every hint!
regards,
Bart
The OP was asking about BST (which is a Spin Tool) and it not working on his Mac.
The obvious answer to someone wanting to program in Spin on a Mac is to try SimpleIDE, it does Spin ALSO.
The OP went on to state that it wasn't obvious that SimpleIDE did Spin also
I don't think a proper response to the OP's question should have been, "No, you don't want to use Spin to program your Propeller, you want to use C which is supported through SimpleIDE."
I don't recall any posts telling someone that wanted to use C to go use Spin or the other way around. I don't think there are any conspiracies either way. If someone wants to use a certain OBEX object or standard Spin library item but they don't have a Windows system, the correct answer isn't "learn C, convert the item from Spin to C and SimpleIDE is the best way to go".
For the most part, there is support but you can't expect hobbyist to retool due to a corporate decision. I'm not here because I HAVE to be, I'm here because I CHOOSE to be! I like the Propeller, I like the little bit of Spin and PASM I know, it's FUN! I don't like C, I've been in and out of C for my entire professional life - I don't like it, it's not enjoyable, it's not fun, it's not relaxing. I like the language that shall go nameless, it's fun!
If someone asks about C and I can help, I help, I don't steer them away.
Just as it's hard for someone that doesn't "do C" understand the views of a seasoned C professional on the language, it's just as hard for someone that's a seasoned C professional to understand someone that doesn't like C or want to learn C.
People can only give advice or recommendations where they have experience (or at least they should). I can't tell you how great C is, I can't tell you things it doesn't do. I can tell you things don't like, I can tell you things I do like, I can tell you of Propeller successes and neat projects I've seen done in Spin, I can't tell about as many in C.
Spin has a lot of momentum...C needs to catch up. Are forum members going to drop what they know and enjoy working on to pick up C and start an OBEX conversion? Probably not. Ar forum members going to take an active campaign against C on the Propeller, certainly not. Are folks going to say, "You really needs to try C on the Propeller!" if they themselves haven't and don't actively use it?
Which takes us back to Heater's original question: "Why isn't SimpleIDE promoted more as a viable solution to a number of potential new customer's Spin problems?"
There are two kinds of obstacles that can impede productivity: roadblocks and speedbumps. A roadblock is a one-time thing that, once passed, becomes irrelevant. An example would be the learning curve for a new language, such as Spin. Speedbumps are the things we encounter and that slow us down every day. Examples include syntactical gingerbread and things like prototypes that exist only to save the compiler writer from having to include an extra pass.
I'm not anti-C. Heaven knows the language I came from to learn Spin (Perl) is more convoluted than C, and I still like it. But it has its place, as does C. It's just that I don't think the Propeller is one of those places, especially given the far more hardware-appropriate language already tailored for it. It's okay for Parallax to use C as bait to lure new customers to the Propeller, but once that door is open, even more effort should be expended to steer those same customers to Spin. Once they've passed that roadblock they will no longer have to endure the Chinese water torture embodied by braces, semicolons, prototypes, and header files, and they can start just writing code and being productive.
So I guess I respectfully disagree with Jon that C is good for Parallax's long-term objectives -- at least not beyond the shorter term goal of chumming the sea of C programmers closer to the boat.
-Phil
I think you're making to big a deal of the "chinese water torture". I got past that a few days into programming in C. I admit that it is mildly annoying to have to write a prototype for every function that has never impeded my progress. If you really think that is an issue then the Arduino preprocessor could be used to provide that extra pass. While I like Spin in many ways, I don't think it is a step up from C. It has less power and expressiveness even if it is a bit more verbose than you'd like in certain areas. There are no dynamic objects in Spin, there are no pointers to anything other than longs, words, and bytes, no function pointers, etc. It is well suited to small programs and very well suited to the Propeller but I maintain that it is not a step up from C/C++. Okay, crucify me for saying that. Say I'm a C/C++ snob. There are actually languages that I think are more powerful than C/C++ though. I'd prefer Lisp myself and probably also JavaScript or Python. I even like Ruby but I'm not sure some of those are appropriate for microcontrollers. However, both Spin and C/C++ are and I think C/C++ have more power and are more appropriate for large programming projects. I'm not sure you're doing someone who knows and understands C/C++ a favor by encouraging them to switch to Spin. They may want to do it (like I might) because Spin is an interesting new language to learn but I doubt they will find that they are able to do more with Spin than C/C++.
So I guess I respectfully disagree with Jon that C is good for Parallax's long-term objectives
I think we're in agreement, Phil; like you, I view a C compiler for the Propeller as bait to attract new users to the hardware. To use your analogy, the biggest roadblock for some new users is not having a simple tool to program the Propeller on their favorite OS. Forgive my broken record approach, but Steve's xBasic IDE is very close and, I think, could really be helpful (if modified for Spin). The panel that shows what's inside the project libraries is especially useful.
However, I think Parallax deserves some support in their efforts to promote the Propeller into educational environments where C is mandated. In that case it isn't a matter of which language is better. That choice has already been made by someone outside of Parallax and these forums.
David,
What I have quoted above is exactly the point. I (and I believe many programmers) are tired of C being shoved down our throat.
So many schools and businesses are so drunk on the "C" cool-aid that they won't even consider any other language.
BASIC "Oh that is so quaint.",
Assembler "Don't you use dip switches to write your code ?"
Forth "Why is all the math backwards ?"
Spin "That's all we need...Another programming language."
Anything except C "Never heard of that language..."
C "Oh yes, you are a good conformist. Your program must be the best that could ever be written, let me offer you a job."
Sorry to be so sarcastic, but this is fairly close to my experience.
I'm puzzled by objections to C on the Propeller. It's just another tool in the toolbox. Use the right tool for the job. Quite often Spin/PASM is the right language to use on the Prop. However, if your porting some code that's already written in C, then C is probably the right language to use. Some people think in RPN, and don't care about portability, so Forth may be the most efficient way for them to program. A lot of people are comfortable with Basic, and have worked with Stamps or the SX using SX/B, so PropBASIC may work best for them.
Allowing people to program the Prop in C or C++ will get more people to use the Prop. Along the way they might try out Spin or one of the other languages. I don't see how this can be bad for the Prop.
I'm beginning to be of the opinion that there is no such thing as the BASIC language. It's just a named tacked onto any old language to make it seem like it will be appropriate for "beginners".
Anyway, good luck promoting Spin as a more modern language that is a step up from C/C++.
While I like Spin in many ways, I don't think it is a step up from C. It has less power and expressiveness even if it is a bit more verbose than you'd like in certain areas. There are no dynamic objects in Spin, there are no pointers to anything other than longs, words, and bytes, no function pointers, etc
I've never said that Spin could not be improved. And these are some of the areas where it is, admittedly, a bit weak. But I think the ultimate solution is to make those improvements, not to use their lack as an argument for abandoning it in favor of C.
I've never said that Spin could not be improved. And these are some of the areas where it is, admittedly, a bit weak. But I think the ultimate solution is to make those improvements, not to use their lack as an argument for abandoning it in favor of C.
-Phil
Great news! Can you also port it to other processors so the code I write for it isn't locked to the Propeller. Parallax might like that but I don't think the industry as a whole will accept a language tied to a specific processor.
Can you also port it to other processors so the code I write for it isn't locked to the Propeller.
Why would I want to? I doubt there are very many programs written for the Propeller's ujnique hardware that could port easily to another processor -- in any language. It's easier and yeilds better results just to start over when switching to another processor -- unless you're switching from one vanilla, C-optimized variant to another.
Why would I want to? I doubt there are very many programs written for the Propeller's ujnique hardware that could port easily to another processor -- in any language. It's easier and yeilds better results just to start over when switching to another processor -- unless you're switching from one vanilla, C-optimized variant to another.
Okay then, show me an example of a PropGCC program that uses multiple cogs, counters, locks, bit-banged serial I/O, and waitvid that will port to, say, an ARM without essentially starting over.
There probably not many cases when something written for the Prop is ported to something else. However, there are probably a lot of cases where the reverse is true. If it's already written in C in may be easier to run it that way instead of converting the code to Spin.
Okay then, show me an example of a PropGCC program that uses multiple cogs, counters, locks, bit-banged serial I/O, and waitvid that will port to, say, an ARM without essentially starting over.
C supports standard ways to do multiple tasks, locks and serial I/O using pthread, mutex locks and standard I/O. That is very portable. The counter stuff may require a bit of work depending on what you are doing with the counter.
waitvid is more a dependency on the hardware display. Switching from one display to another would require writing a low-level driver for it.
Who's objecting? I think what concerns many of us is that there seems to be a hair-on-fire approach to promoting C while abandoning all the hard work that has been put into the creation of Spin/PASM objects. Remember, whether anyone likes it or not, Chip chose to develop Spin for the Propeller instead of using C. We all know that he's a thoughtful person and doesn't do these things lightly. His belief, I believe, is that Spin would allow new programers to take advantage of the unique aspects of the Propeller. Anyone who tortures themself with C (c'mon, I'm teasing), can easily adapt to Spin.
<broken record>Create a nice, great, easy-to-use, cross-platform IDE for Spin/PASM development. Then adapt the IDE to additional [non-native] languages (C, BASIC, Forth, etc.)</broken record>
Okay then, show me an example of a PropGCC program that uses multiple cogs, counters, locks, bit-banged serial I/O, and waitvid that will port to, say, an ARM without essentially starting over.
-Phil
I'm sure it is possible to write a Spin program that couldn't possibly run on any other processor. It's that way with any language if you don't do a good job of abstracting your interfaces to the hardware. I'll bet though that most of the code in the Spinneret web server could be run on another processor by just changing the driver that talks to the WizNet chip. There are likely other examples as well. One that comes to mind is FemtoBasic or even Sphinx, the Spin compiler that runs on the Propeller.
Who's objecting? I think what concerns many of us is that there seems to be a hair-on-fire approach to promoting C while abandoning all the hard work that has been put into the creation of Spin/PASM objects.
I don't think anyone is advocating abandoning Spin. I agree that there should be an officially supported cross-platform IDE for Spin and I fully expect that to happen. I just don't think that it is necessary to view C as a "gateway drug" to pull people into Spin. I think both languages have value and one isn't an "upgrade" to the other.
Not to name names, but I think Phil, Bean and a few others are objecting.
The more I know about the internals of Spin, the more I'm impressed by it's elegance. However, Spin is lacking in a number of areas, which causes newbies and experience programmers to get caught in various traps. There are a few enhancements that could be done to Spin that would make it a much better language for newbies and experienced developers.
<broken record>Create a nice, great, easy-to-use, cross-platform IDE for Spin/PASM development. Then adapt the IDE to additional [non-native] languages (C, BASIC, Forth, etc.)</broken record>
This sounds nice in principle but I think that what is good for Spin may not be the best approach for other languages. For example, the single main file that includes sub-objects works well with Spin and makes it unnecessary to support a "project manager". This doesn't work as well for C/C++. There will need to be additional features to address requirements of each language. Here you can correctly argue that Spin got it right where C is much more clumsy. That may be true but that is the way C works and there needs to be a provision for it. Otherwise, I'm in agreement with you that there needs to be a cross-platform IDE for Spin/PASM development.
The biggest concern I have with Spin is that it's a proprietary language. I hate it when manufacturers provide proprietary tools, especially when there is no need for it. Exactly the same functionality that is implemented in the Spin language could have been done in a subset of C++ or some other object oriented language.
Comments
-Phil
An OBEX FULL of Spin/PASM objects for making the P1 do some amazing things compared to a very limited set of C library routines implementing a very few of those OBEX objects.
An active hobbyist(and professional) community that is continuing to create amazing things with Spin/PASM.
An active HOBBYIST(and professional) community that doesn't really want to retool from something they are productive (personally and financially) with and lose fun, productivity, creativity and money in the process.
A LARGE number of Parallax products that provide Spin examples and demos when you go to their product pages looking for examples.
An excellent PEK document that is all about Spin and PASM.
An excellent P1 product manual that is all about Spin and PASM.
It's unfair(DUMB) to tell a new user that finds the Propeller and possibly a companion product or interesting OBEX object (or project someone else did) that is a Mac or Linux user either, "sorry, the PropTool is Windows only" or "well, here's SimpleIDE which can do Spin but look, it also does C!!!! No, we don't have theat OBEX object in C or a demo for that product in C....but look, SImpleIDE really makes it possible to do C on the Propeller!"
Other than those, I can't think of any reasons.
Oh and Chip really likes Spin and PASM!
Exactly. Right now, the P2 is going to be a sequel to a movie too few people have seen.
I'm not against C at all, in fact, I'm quite for it as I think it serves Parallax's long and short-term interests. That said, development of a C compiler for the Propeller should not push a nice, simple, cross-platform tool for Spin/PASM to the side. The key is give customs easy access to the Propeller -- on their favorite platform. At the Hackaday event last week I asked an Arduino user if he'd ever considered using the Propeller. His response? "What's a Propeller?"
Get people hooked on the coolness of the hardware, then give them choices -- which in the Propeller world are wildly varied (Spin, BASIC, C, Forth).
Steps I think would help:
-- create a nice, simple, x-platform tool for the Propeller (Spin/PASM) -- the xBasic IDE is nearly there.
-- port the [wonderful, and fully vetted by educators] Stamps In Class materials to the Propeller (Spin and C variants)
I'm not anti-C. Heaven knows the language I came from to learn Spin (Perl) is more convoluted than C, and I still like it. But it has its place, as does C. It's just that I don't think the Propeller is one of those places, especially given the far more hardware-appropriate language already tailored for it. It's okay for Parallax to use C as bait to lure new customers to the Propeller, but once that door is open, even more effort should be expended to steer those same customers to Spin. Once they've passed that roadblock they will no longer have to endure the Chinese water torture embodied by braces, semicolons, prototypes, and header files, and they can start just writing code and being productive.
So I guess I respectfully disagree with Jon that C is good for Parallax's long-term objectives -- at least not beyond the shorter term goal of chumming the sea of C programmers closer to the boat.
-Phil
The OP was asking about BST (which is a Spin Tool) and it not working on his Mac.
The obvious answer to someone wanting to program in Spin on a Mac is to try SimpleIDE, it does Spin ALSO.
The OP went on to state that it wasn't obvious that SimpleIDE did Spin also
I don't think a proper response to the OP's question should have been, "No, you don't want to use Spin to program your Propeller, you want to use C which is supported through SimpleIDE."
I don't recall any posts telling someone that wanted to use C to go use Spin or the other way around. I don't think there are any conspiracies either way. If someone wants to use a certain OBEX object or standard Spin library item but they don't have a Windows system, the correct answer isn't "learn C, convert the item from Spin to C and SimpleIDE is the best way to go".
For the most part, there is support but you can't expect hobbyist to retool due to a corporate decision. I'm not here because I HAVE to be, I'm here because I CHOOSE to be! I like the Propeller, I like the little bit of Spin and PASM I know, it's FUN! I don't like C, I've been in and out of C for my entire professional life - I don't like it, it's not enjoyable, it's not fun, it's not relaxing. I like the language that shall go nameless, it's fun!
If someone asks about C and I can help, I help, I don't steer them away.
Just as it's hard for someone that doesn't "do C" understand the views of a seasoned C professional on the language, it's just as hard for someone that's a seasoned C professional to understand someone that doesn't like C or want to learn C.
People can only give advice or recommendations where they have experience (or at least they should). I can't tell you how great C is, I can't tell you things it doesn't do. I can tell you things don't like, I can tell you things I do like, I can tell you of Propeller successes and neat projects I've seen done in Spin, I can't tell about as many in C.
Spin has a lot of momentum...C needs to catch up. Are forum members going to drop what they know and enjoy working on to pick up C and start an OBEX conversion? Probably not. Ar forum members going to take an active campaign against C on the Propeller, certainly not. Are folks going to say, "You really needs to try C on the Propeller!" if they themselves haven't and don't actively use it?
Which takes us back to Heater's original question: "Why isn't SimpleIDE promoted more as a viable solution to a number of potential new customer's Spin problems?"
I think we're in agreement, Phil; like you, I view a C compiler for the Propeller as bait to attract new users to the hardware. To use your analogy, the biggest roadblock for some new users is not having a simple tool to program the Propeller on their favorite OS. Forgive my broken record approach, but Steve's xBasic IDE is very close and, I think, could really be helpful (if modified for Spin). The panel that shows what's inside the project libraries is especially useful.
David,
What I have quoted above is exactly the point. I (and I believe many programmers) are tired of C being shoved down our throat.
So many schools and businesses are so drunk on the "C" cool-aid that they won't even consider any other language.
BASIC "Oh that is so quaint.",
Assembler "Don't you use dip switches to write your code ?"
Forth "Why is all the math backwards ?"
Spin "That's all we need...Another programming language."
Anything except C "Never heard of that language..."
C "Oh yes, you are a good conformist. Your program must be the best that could ever be written, let me offer you a job."
Sorry to be so sarcastic, but this is fairly close to my experience.
Bean
Allowing people to program the Prop in C or C++ will get more people to use the Prop. Along the way they might try out Spin or one of the other languages. I don't see how this can be bad for the Prop.
Anyway, good luck promoting Spin as a more modern language that is a step up from C/C++.
-Phil
Great news! Can you also port it to other processors so the code I write for it isn't locked to the Propeller. Parallax might like that but I don't think the industry as a whole will accept a language tied to a specific processor.
-Phil
-Phil
waitvid is more a dependency on the hardware display. Switching from one display to another would require writing a low-level driver for it.
Who's objecting? I think what concerns many of us is that there seems to be a hair-on-fire approach to promoting C while abandoning all the hard work that has been put into the creation of Spin/PASM objects. Remember, whether anyone likes it or not, Chip chose to develop Spin for the Propeller instead of using C. We all know that he's a thoughtful person and doesn't do these things lightly. His belief, I believe, is that Spin would allow new programers to take advantage of the unique aspects of the Propeller. Anyone who tortures themself with C (c'mon, I'm teasing), can easily adapt to Spin.
<broken record>Create a nice, great, easy-to-use, cross-platform IDE for Spin/PASM development. Then adapt the IDE to additional [non-native] languages (C, BASIC, Forth, etc.)</broken record>
The more I know about the internals of Spin, the more I'm impressed by it's elegance. However, Spin is lacking in a number of areas, which causes newbies and experience programmers to get caught in various traps. There are a few enhancements that could be done to Spin that would make it a much better language for newbies and experienced developers.