Back to the original subject of this thread, it seems like SimpleIDE for Spin should be promoted more. I've always used the Spin tool, and never used SIDE for Spin. However, I just tried it out with Spin, and I like it. It does require creating a project file, but that's not a big deal. It would be nice if the default Spin file contained a little more stuff like default _clkmode and _clkfreq values, and maybe a simple "Hello World" program.
Nubie question. I've used SimpleIDE for C programs. I've used Proptool for spin programs. After reading this thread, I tried to use SimpleIDE for spin programming, but when I try to start a spin project, I get an error message: "Blank Simple Project was not found". I looked in the Simple IDE directories and see "Blank Simple C++.side" and "Blank Simple Project.side" (and its corresponding .c file), but nothing for spin. I tried looking in the user guide, but could not find anything.
How do you create a project file for a spin project?
I personally will not use SimpleIDE for Spin until, at a minimum, it auto-indents to the same level as the previous line. Minimum. Really.
I agree but didn't mention it because I thought that, surely, something so essential has been added to a later version that I haven't installed yet. So here's my SimpleIDE list of minimum requirements for Spin programs:
1. Get rid of the "project" requirement and make it easy to File->Load and compile any file you want to. Compile from a designated top object or the one currently showing.
2. Auto-indent, and allow different tab stops for different sections of the program. Tabs for the DAT section, for example, should conform to assembly tabbing.
3. Automatically scan for a Prop on the available serial ports for loading.
4. Make it possible to compile without automatically saving the source first. (It's no big deal to save to a temp file and compile from there, after all.)
5. Support zip archiving, as is done in the PropTool. (It would be nice if compilation and loading could be done directly from a zipped archive, too, via unpacked temp files.)
I guess this answers the question "Why isn't SimpleIDE promoted for Spin programming". Spin programmers are too picky. Give me vi and a command-line compiler and I'm happy. Anything more than that is superfluous.
I guess this answers the question "Why isn't SimpleIDE promoted for Spin programming". Spin programmers are too picky. Give me vi and a command-line compiler and I'm happy. Anything more than that is superfluous.
That's not helpful, Dave. You're a C programmer and have gotten used to such tools. But such a smug attitude (as noted by JonnyMac) does not address the legitimate needs and desires of the Spin programming community at large. Why make it more difficult than it has to be, just because some programmers, like yourself, can get by with primitive tools?
You are all placing too much emphasis on BST IS DEAD. It totally works.
PropTool works. But in fact it is unsupported apart from a couple of minor tweeks. I say this because although there have been many requests over the years, PropTool has not changed. So using the same basis, proptool is also dead.
Skimming thru this thread (with a lot of OT discussions) I didn't understand the ultimate statement - Does SimpleIDE support spin ???
Skimming thru this thread (with a lot of OT discussions) I didn't understand the ultimate statement - Does SimpleIDE support spin ???
Yes, you can create Spin programs in the editor and compile and load them to an attached Propeller. SimpleIDE allows you to do this with a consistent IDE across platforms and between Spin and C/C++. If you have a Mac or PC running a Linux distribution (ok, Heater? ) and BST does not work on your Mac (it does seem to have problems on some Macs), then SimpleIDE is the way to create Spin programs. If you are unable to run the PRopellerTool, then you will not be aware of the shortcomings pointed out Spin gurus because in this case, something that works IS better than nothing.
When I do that I get the 'blank simple project not found' error.
Tom
On my Mac, I just did this:
closed everything,
made sure "Spin" was selected as compiler type in Project Options in lower left window
clicked on "New Project" icon
named the project TestProj in the dialog box and hit save
It created a TestProj.side file with a TestSpin.spin file in it.
The .spin file contained this code:
pub main
repeat
Away you go with your new project. Not too difficult, especially if your alternative is not being able to use Spin!
Wowee!!!!! Good to see that so many people are so passionate regarding my beloved Propeller!
For what it's worth I am on Team Spin. I just like it. I have done a few of the Simple IDE tuts in C, and it just wasn't for me. Not saying that I won't do more with it when I have "for fun" time, but it's really not for me. Sure you can run a Diesel engine on recycled cooking oil, but.... (electomanj ducks)....
Actually, I was not even aware that you could program in Spin with Simple IDE until I read this thread. I will have to check that out. I am very grateful that Simple IDE is a choice. More options are great, and anything that makes it easier for someone to program a Propeller is AOK in my book. My thinking was that there are so many many many projects examples out there that are for the aurduino, If I had a little C experience it would be easier to understand them and port them over to the Prop.
I believe the point of the OP was that Mac users can use Simple IDE to program the Propeller in Spin and that fact should be more advertised. I concur.
Thanks for the help, but it still didn't work - I got the same error message.
I finally got something to work (sort of) by loading in the Blank Simple Project c-version, deleting everything from that tab, opening a new tab, putting your code in it and calling it "Blank Simple Project.spin" and saving it. I then opened the SDE file in notebook and deleted the c stuff.
I am able to open that manually and I copied (cut and paste) LED-Flash.spin from the prop education kit tutorials. I saved it and I'm abe to open, edit (in IDE), and compile and run the spin program on my QuickStart board.
But I can still not use the New Project icon to start a new Spin Project. (I get the 'Blank Simple Project" not found error, so there is something missing somewhere.)
But, I find the prop tool more useful (at least for someone learning spin) with its indenting, colors, and block indicators, identify hardware, and different file open methods.
I think PropGCC is a great product right now. The hard work got done and we've got a very functional C on Propeller thanks to the PropGCC team. It works, people are getting stuff done, and that is great compared to where it all was some time ago.
The "hard sell" breaks down along a few axis:
1. Size of P1 and it's specialized nature.
Doing most things on P1 is a tight fit. Doing great things is the tightest of fits generally. And we have a speed / size trade off in play too. Actually, C has advantages here because it can leverage multiple memory models. CMM, XMM, LMM, COG, etc... By contrast SPIN + PASM is what it is.
C looks good here because it's got support for memory models SPIN doesn't. Well, not without PASM.
The hardware counters, video generator, etc... in P1 are specialized.
I read things like "standard ways to do things" and yes, there are lots of standard ways to do things. Even the same things. Sometimes I find that difficult to reconcile with the small memory P1 has. Other times I find it hard to grapple with how verbose things like inline assembly are, or the amount of instructions one has to give to C in order to get the output as desired as opposed to simply writing what it needs to be and moving on.
Really pushing the chip can be done in either environment, but the real magic happens in PASM, and the general nature of C and it's assembler, etc... make for more verbose, sometimes less easy to read and understand and often more laborious combination of assembly language and the higher level language.
2. Our roles in life and goals
Reuse is mixed in there too. In this, the P1 excels due to how it was designed. As a multi-processor, we can package stuff up and reuse it really easy in SPIN. I think C needs a lot more of this kind of work done so that there is more to start with. That's part of the hard sell. Regardless of the language merits, the truth is we've got volumes of great SPIN + PASM code to work from and that is a huge resource.
No matter what people think of assembly language, the truth is assembly language shines on smaller systems, particularly when they are pushed to the limits or being employed in ways that were not assumed to be the norm. SPIN incorporates PASM in a clean, easy to understand way. SPIN 2 will continue this blend of assembly and higher level code even more.
And this is lean in SPIN. Really lean. In C, it's work. Work worth doing if one really does want to reuse, but if not? It's just work. That's part of the hard sell, but only for some people.
Hobby people like to work lean and get it done, whatever it is, however it gets done. Great. Students, and I mean people in school looking for a career, or just people learning with a similar intent, are not as interested in lean as they are learning skills they know they can use in a broader context. Finally, there are people who aren't hobby people, aren't students, who just want to get it done, however it gets done, and once it's done, they get paid.
C is a hard sell to the hobby people and the latter group I just mentioned. It's a hard sell because it's not lean. You do work in C that only pays off when you need to reuse, sometimes refactor, or port / re-target. Given those two groups may well be operating under time constraints of various kinds, this extra thickness involved is simply undesirable, wasted.
To the students who are wanting to advance in their potential career, those things are all part of the package, not a worry, and C is a much easier sell to them. Investments being made in time, code, and their skills / practices will be very highly likely to pay off.
The more tight, effective library code we have, the more attractive C will be to all of the groups. Over time, I see this getting done, but it's gonna take time just like it did for SPIN.
I have worked with some people on these things and when they know stuff from their past experiences, C can make a lot of sense. If they are new, to it all, SPIN + PASM is a great place to learn things. It's lean, and you really don't have to know much to make the magic happen. You really don't have to keep track of as much to make it happen either.
3. Ideologies / standards / politics
Ugh... I almost don't want to write this part. But I'm going to.
The idea of standardizing as much as possible, reusing as much as possible, etc... brings us advanced, higher level language features to accomplish those things, but it also brings complexity too.
I see this constantly as if it's the one true best practice! Truth is, it's not. Some of us care about this, some of us care a lot. Others could care less, or maybe care a little.
Just a while back, on the P2 discussions, I read, "A standard assembler would do..." and I think to myself, "sure, OK" while at the same time wanting SPIN to be SPIN + PASM for the lean, seriously productive environment it is, and it will be those things precisely because it's not standard! Never will be. Shouldn't be either.
So there is a conflict there I find very off putting.
On the P1, we've got a ton of code showing off excellent exploitation of the hardware, and really understanding it at a lower level is encouraged in SPIN + PASM land. Things like "code is documentation" also is often encouraged in SPIN land. Frankly, I love that.
Abstraction, formalization, compartmentalization, etc... are seen as strengths in C land, and the whole thing shifts into a place where suddenly one of us does something cool, and out it all comes! Is that reusable? Can it support A. B. C, D, E, etc... Can we make sure it can run on the not so cool hardware too? ...which is kind of nutty, if you ask me. The not so cool hardware is not so cool because it's really different from the Propeller, or perhaps the Propeller is really different from a lot of other stuff out there. You tell me.
Here's the truth guys. I've dropped a project or two here over those very issues. Did a few in private too, just choosing not to share. SImply didn't want to hear about it. Still don't want to. Now, if I'm on a paying gig, I'll see it much differently! Get paid to do that actually, and it's funny how a few dollars can power through what may otherwise be seen as a lot of work for no other return.
Pro vs Amateur vs Other
When I see C positioned as "the pro solution" and I see "those SPIN faithful" being framed in marginal terms, I sometimes wonder whether or not I shouldn't just pay a couple from each camp to complete a total pig of a problem and see just who kicks whose arses. Then pay again to make a bunch of changes. I would include paying a third time to retarget to new hardware, but I don't see the point there. If the task is generic enough, that can happen anyway. If it's a real challenge on a P1, then the solution isn't going to port easily in general because it will include PASM, etc...
I really don't want to hear about this either. I do want to enable people, not convince people.
Truth is, some of us are here because we want to be. Others are here to make money. Still others are here to learn and build a career. The implication that C is "the way" or "the best way" or even "necessary" often gets linked to the complex compartmentalization, abstraction, and other "ions" that simply consume time and energy at worst, and might yield some savings, if and when there is some reuse in the middle case, and are maybe awesome as library code everybody needs but nobody gets paid to write at best.
4. Summary
Throughout all of that, the P1 is just kind of tiny. It's not really a "pro" chip as we've been told how many times? Too many. And a quick look at P2, shows it's much bigger, faster, and intended to be "pro" in ways the P1 isn't.
Secondly, the easiest sell on C happens to be "pro" minded people, just the kind that aren't so well aligned with a P1, and I hope I've explained a little bit of why.
Has nothing to do with the merits of C or PropGCC. Both are fine efforts, and worth it when indicated too.
That's not helpful, Dave. You're a C programmer and have gotten used to such tools. But such a smug attitude (as noted by JonnyMac) does not address the legitimate needs and desires of the Spin programming community at large. Why make it more difficult than it has to be, just because some programmers, like yourself, can get by with primitive tools?
But I did use a smiley. Just trying to add a little levity to the discussion. Sorry if I came across as being a smug C programmer. On the Prop I consider myself to be a Spin/PASM/C/Forth programmer, in that order. I've written a lot more Spin code on the Prop than I have in any of the other languages.
So I'll try to add some constructive input. I think all of the suggestions should be organized in a list to determine what can be done, and what can't be. I like the auto-indent idea. It would be very useful for writing Spin and also C. Even C programmers write indented code.
This afternoon I spent some time running Spin programs through SimpleIDE on my Mac. I had a few setup issues with Open Spin compiler not being found, but I put it in the right place and it worked out fine. Next I learned how to define a project which seems similar to naming a top Spin file in the Propeller Windows Tool. And I noticed that the lack of indentation identification can be a problem, but once you're aware of it and you know when to indent for the loops and conditional statements everything works just fine.
Personally, I was really jazzed to be running Spin on a Mac with open source Simple IDE and Open Spin! I think we all know that this tool has been done by Steve (jazzed) on a volunteer basis, right?
Why haven't we advertised Simple IDE for Spin?
First, it's not an intentional disregard, just to be clear. We're pretty limited on resources - time, money and where to apply both of them. To explain that it can be used with Spin means we need to qualify the situation in it's present form (what's in, what's not). We can certainly do this, but we have to be careful not to create expectations that we can't meet about it's future development. You can imagine that in its present form Simple IDE for Spin would cause a new and demanding new developer to wonder if we're all that serious about our tools. But if they understand it's an in-progress effort then their expectations might be met, right? We just have to say what it can and can't do.
The other reason we haven't done much is we'd also like it to be brought up to standard. It's always been my assumption that we have to pay for improvements, and since this is Steve's project we would need to pay him for our improvements (unless somebody else picks up the effort as a volunteer - see below). But Steve's time (and our budget) is currently applied to Simple IDE for C. We met with him last week and we have a list of C improvements we need accomplished. As so much of our revenue from Propeller 1 comes from education, we need to prioritize our effort in that direction.
OK, can you at least show what can be done with Simple IDE and Spin?
Yes! We should show how to set up Simple IDE for use with Spin. It works fine once you get used to the setup and understand the project management part and absence of program flow without indentation indicators. Somebody quoted me above indicating that Simple IDE will provide better support for Spin, and that effort still stands (we're just a bit short on resources to get there). I need to figure out where to do this (on Learn.parallax.com, parallax.com, or somewhere else). For now, it would be an as-is offering without expectations on Steve to make improvements.
How about improvements to Simple IDE for Spin?
Like you, everybody would love to have the improvements identified above. This means somebody needs to first define the features and objectives.
Then, since Steve is pretty booked with Simple IDE for C, somebody else would need to pick up the effort. Steve would probably need to verify, but I don't think he wants to do this unless he's being paid. We don't have budget planned for the effort for the time being.
At least that's how I see it right now. Could it become another Open Propeller Project? We've only released one so far, but it's getting completed and we're ready for more efforts.
I seldom read all of your posts because ... well ... they're usually just way too freaking long. But I made an exception this evening, and I'm glad I did. I think you've elaborated ("summarized" would be the wrong word ) on some necessary themes, and I agree with most of your key points. Maybe Parallax should have held off on the C emphasis until the P2 was ready for showtime. The P1 is definitely not the optimal target for such a dev language under any circumstances, and I think that is responsible for so much of the sturm und drang in the forum -- between those of us who recognize that fact and those who wish it to be otherwise.
C is a hard sell to the hobby people and the latter group I just mentioned. It's a hard sell because it's not lean.
I find this surprising because I've often heard C described as a machine-independent assembly language. It is about as low-level as you can get. It doesn't even have objects unless you count C++. It just has a few basic concepts like pointers and structures and powerful ways to combine them. What do you mean when you say that C is not lean?
Maybe Parallax should have held off on the C emphasis until the P2 was ready for showtime. The P1 is definely not the optimal target for such a dev language under any circumstances, and I think that is responsible for so much of the sturm und drang in the forum -- between those of us who recognize that fact and those who wish it to be otherwise.
I really don't see a problem with having two main languages. I also don't understand why people are so passionate about what's best, what's awful, etc. C and Spin have their benefits and drawbacks with he Propeller and we all understand them by now, and we should be able to help a forum newbie identify the right place to get started. That'd be a great way to use our knowledge to help the new customer find satisfaction.
We aren't encouraging the use of our GCC compiler for professional applications, in case you were wondering. With few exceptions, all of the volume P1 applications were designed in Spin/ASM. We know that some memory limitations and documentation are a consideration with C and Propeller 1.
As for whether or not we should've held off on C for P1, it's possible that if we didn't create C for P1 there would be no P2 (or it would be far more difficult to fund the process, with funding being the delay instead of the design process). Do you know where the funding comes from to drive the R&D efforts that will bridge the gap towards P2? The educational customer type buys lots of robots from Parallax, so they're a big contributor. If we give them what they want, they buy our products. And this creates net income which we apply to P2. If we didn't make the C compiler, we wouldn't be selling them as much product.
I've also noticed that the educational customer wouldn't look at Spin until recently - now you even see Chinese visitors on the forums asking questions about Spin. They wanted C - and until we gave them C - Spin was irrelevant. Try throwing a programming language barrier on top of a language difference and you're stuck. Now we're getting Spin inquiries from educational customers. Somebody want to port the ActivityBot code to Spin?
Throughout all of that, the P1 is just kind of tiny.
Yes, P1 limited to only its hub memory is small. But adding a single SPI flash chip gives you quite a lot of program space and performs decently. As Ross has pointed out, adding a parallel RAM chip can sometimes exceed the performance of Spin. There are ways to make the P1 a better platform for larger C programs and small ones fit pretty well in the CMM or LMM memory models in both PropGCC and Catalina.
I think simply presenting all the choices is good. From there, people choose and they should proceed as they will. Some of them will do fine, some will ask for options / help, and some will have various sorts of trouble.
Deal with that as it comes.
Yes, P1 limited to only its hub memory is small. But adding a single SPI flash chip gives you quite a lot of program space and performs decently
Yes, and that is one of the good C things. For those so inclined, it's a great option. I cited it being a tough sell overall. For those running external memory, C should be more compelling, and I would advocate the same thing. Use it, because it makes a lot of sense.
I'm not in any way saying C is bad. It's not. The product is good!
Given what is possible with a P1 and SPIN + PASM, it's a hard sell, also given the rough roles I put out there.
The pro comments are relevant too. P1 isn't a pro chip. That's been established. Experienced C users and students who can benefit from the experience are going to like and use C and they will be productive and successful too. That's because it works.
But it's not the "sweet spot" use case SPIN + PASM is, generally.
Maybe I should put it this way. If somebody has a reason or connection to C, P1 C will make sense to them. Not a hard sell overall. If they don't? Then it's harder, because of how compelling SPIN+PASM is, and the generally small size of the P1 and how that matches up to projects.
P2 will be an entirely different thing.
Both will continue to depend on library code that puts the magic into easily accessable packages. Frankly, we may not see the obex development on P2 due to closed code being a realistic option now. C may well hold an advantage, depending on who does what and whether or not they want payment for it this time around.
I don;t get that statement.'Care to elaborate? The P1, in my mind, is every bit a pro chip in the many areas where it shines, including video, signal processing, and handling myriad communication protocols.
We aren't encouraging the use of our GCC compiler for professional applications, With few exceptions, all of the volume P1 applications were designed in Spin/ASM.
That's really good to know, Ken!
I've also noticed that the educational customer wouldn't look at Spin until recently - now you even see Chinese visitors on the forums asking questions about Spin. They wanted C - and until we gave them C - Spin was irrelevant.
Does this mean that some people think they prefer C until they actually see it and then change their minds in favor of Spin? If that's the case, then I think my "chumming" scenario has some validity. It's also a commentary on rational decision-making in general. If someone is offered only chateaubriand, they might pass it up because they've never heard of chateaubriand. But if they're offered a choice between chateaubriand and chopped liver, they'll pick chateaubriand because they discover that they don't like chopped liver.
That's a truly diabolical strategy, Ken! I fear that I've underestimated Parallax's marketing acumen!
Somebody want to port the ActivityBot code to Spin?
I've considered it! Is funding available for such an endeavor?
Does this mean that some people think they prefer C until they actually see it and then change their minds in favor of Spin? If that's the case, then I think my "chumming" scenario has some validity.
-Phil
Yes, this is the case. I've talked to several educators who finally looked at the Propeller and then became interested in Spin when they discovered loads of good objects in OBEX. But I'm also the guy who thinks we need to support iPad programming of the Propeller.
But I'm also the guy who thinks we need to support iPad programming of the Propeller.
I can't take issue with that objective. Portable computing appliances are rapidly taking the place of PCs and laptops. In the class that I teach once a week, I have to lend my laptop to one group, since the school couldn't afford enough laptops for everyone. But all the kids have iPads or smart phones of their own, which could be pressed into service if the right dev tools were available.
I seldom read all of your posts because ... well ... they're usually just way too freaking long.
That's OK. No worries. As I've said earlier, I often think long form and I write best long form. Is what it is. Once in a while, you get a treat in that I'll go short. Great when that happens, isn't it? I think so too.
About that "not a pro chip" thing. Frankly, I think the P1 is brilliant and it's capable of a lot. The non-standard nature of it, plus the community here, etc... just isn't standard or inaccessible enough to be pro, lol. Needs JTAG, kind of a thing. Maybe that's brief enough to get it done here.
I find this surprising because I've often heard C described as a machine-independent assembly language.
I agree with you David, and I also will easily say most people should learn C!
But it's not assembly language, is it? On the hardware of today, that statement makes a lot of sense. Ask somebody who has done 8 bit computing what they think of C as assembly language. I suspect that answer will be interesting and enlightening. Edit: and you know this as you've been around for some time. I didn't mean that to read badly, just trying to get at lean. <---safety smiley!
Compilers are good now. Better than they were back then. But C isn't assembly language, though it is a lower level, simple, close to the machine type language.
So there is that.
Really though, lean is about the whole process, not just language elements. If we are to talk about lean in the context of what the compiler is doing, yes C is low level. As intended. The next lower level really is a macro assembler kind of thing. Assembly language for real.
Now here is where the brilliance of SPIN, the Prop Tool and PASM come into play. Really, SPIN + PASM is a hybrid! That process is stripped down to the nubs. Even the language of SPIN is filled with little nubs, just enough to get it done, but nothing in excess. No brackets, etc...
The PropTool can just get it done too. One can type in a few things, ask for a compile and run and it simply does. It's often no more complex than that, though it can be. Truth is, I can hook up a Prop, write a few lines of SPIN, maybe some PASM too, and run it on my Prop setup, not even worried about path names. Lean. Sometimes I do this, not even saving. Usually, it's when I want to revisit remembering something I probably knew but need to brush up on.
And all those little operators? Excellent. Know what those do really? I can think of it just like I would in assembly and then just type 'em in, one by one, almost writing assembly. Beautiful. And it does it all, meaning I can treat comparisons as values, or values as comparisons (x := x + (y >5) *30, etc...) and I can shift this, that, add, multiply, mask, whatever and I can do it in whatever units I want! %001, %%0123, $ED, and so forth, use delimiters, and generally make a very readable thing out of what I often find to be that 0xh whatever kind of mess I see elsewhere. Types? My problem, not SPINS. It's gonna do what I ask, and if I ask for something stupid, it's going to give me that stupid thing and maybe I learn something. But if I ask for something brilliant? Does that too.
C shares a lot of these things, but it requires more typing and it requires brackets and such that need to go somewhere. Put 'em in line and somebody gets cranky. Put 'em elsewhere and somebody else gets cranky, put 'em in there inconsistently and I get cranky! And everybody wants longer monitors in any case. SPIN is remarkably free of that sort of thing.
The syntax is lean, but verbose. The formatting possible is verbose, meaning I get a lot of options as to how I can translate what is in my head to meaningful symbols for the processor.
And I can stuff it into one big file, if I want to, or break it into lots of little ones as well. This is lean too, because the most common options are there and they make sense. So I don't really have to conform to much beyond the basics. Structure my file how I want. Put my data where I want. Include what I want, or include absolutely nothing. No worries.
Some of that gets tough.
One of my internal benchmarks has actually been graphics_demo.spin That thing has generated more SPIN questions than I expected. And those operators and such were used perfectly in that one too, Chip just packed a lot in to a small space and many of us struggled with that. I don't know how many times I helped somebody out with the colors and the tiles, and the many operators just didn't do us justice.
That one could have been written longer form and it would have been much better. So there you go. Not everything is great. I liked that one actually. Looking at that one program taught me enough SPIN to get to work that day. Sweet! When I needed more, there was more, but a whole pile of what I needed was right there in that one fun program. Gotta love that.
The same was true for PASM. Parsing one video driver took a bit, but then I had enough PASM to go and do lots of stuff. To this day, I don't think I've tried all the instructions. But I got magic done fast and pretty easy and I didn't have to track much and in some cases know all that much. That's lean on a few axis.
I didn't need to read a manual to start writing PASM. In fact, I started writing PASM the same way I did years ago on the 6502. Looked at some code and took off! Since the assembler was right there, I didn't even have to open another book. Prop Manual contained the goods. One stop magic shopping!
With C I have to know my editor, and which one, my compiler and it's many options, my assembler, and so on. And those are big things intended to operate with damn near anything! Now that is awesome because the same GCC that helped me write OpenGL code on SGI can help me write P1 code, but I still have to know all that stuff or at the least track it. With SPIN+PASM, I don't. There is a program that takes my text and it generates an image that goes into my Propeller. Done, next. Lean.
Now don't get me wrong here. I really like Sublime, and that same tight package made it hard for us to do things we want to do, like use our own editor, or use a post processor, etc... We are fixing that. Good. It will be a little less lean, but then again, we could still package it all up, hide it, and keep the simple, lean nature intact for those so inclined to just jump in. Recommend we do. The ones who don't want that will take the pieces and build something they do want and run it on what they want to run it on.
Heck, I may just go buy an IRIX machine to develop on again. Kidding. Really, I'm likely to continue moving to Mac OS. Those IRIX machines are huge and they don't go where I do. So I'm going to deal with not so lean to make an investment that moves me to a Mac, because the Mac is a lot of fun, beautiful, etc... Besides, it's Apple. I started on Apple 2, and still have one. Typing this on a Mac Book Pro makes me realize just how far things have come. And that MBP gives me amazingly zero trouble. Who would have thought? But I digress... (sorry Phil)
With SPIN 2, we are going to get SPIN plus inline PASM and it's going to be one stream of code that we can make what we want out of. The syntax of both are written together and they work together and that's probably enough.
The only other thing I've seen do that are some of the old BASIC languages, like the BBC Micro, which allowed a very similar kind of thing to happen, sans a syntax as beautiful. (For the time, it rocked hard though)
And that right there is a great analogy. C compared to BBC Basic + Assembly. The same dynamics were in play back then, and the same definition of "lean" I'm trying to convey is present and accounted for.
Now many here will ask, "why?" do that. And out it will all come. Not portable, not standard, not encapsulated, not abstracted, not compartmentated, and so on. Who cares? I sure don't. I want to see the magic. Now. And back then it was interesting. The people who were on open machines that included core tools, including assembly language tools, monitors and such developed very differently from those who ended up on machines that were more closed up, or where multiple packages had to be used.
When this stuff really matters, or somebody is paying me and they don't want voodoo, fine. I'm happy to packagize, compartmentalize, abstractalize and sterilize the whole thing to whatever spec pays the bills. Do the work, in other words, that I can avoid doing in SPIN + PASM.
And I like C. But C is work. SPIN is fun. PASM is really fun. And now we are back to the roles and dynamics I mentioned earlier, so that's it. Maybe that helps some to understand.
One last thing. C might not be work. Put me on an SGI, and C is fun! Bigger machine, we get away from the bits and we get closer to higher level things. Had a great time doing that. Learned a lot. Put me on a PC today with some higher order tasks, and I might actually say C is too low level, not a bother, similar to assembly is for many people.
Heater has me thinking a lot about Javascript... for example. So "work" is really very relative to our roles, goals, and the hardware we operate on. Lean is impacted by this too.
A lot of the lean perception has to do with the overall capability / resources and such associated with the thing we are wanting to develop for. C can stretch from the little devices to the really big ones and with that stretch comes some necessary thickness in process, things to track, etc... that need to be there and work great. But they are there, and on a P1, we don't always need them to be there to get the magic out today.
C can actually be seen as tedious compared to other, higher level languages we've got, and on the bigger scale devices we've got the room to relax and have fun all over the place. On a P1, we don't have that room, and the lower level, smaller scale access makes a lot more sense, and SPIN + PASM was made to do exactly that, no more. Lean.
I think that is a bias, but it's a perfectly rational one. Depends on what you spend your time reading.
And you can write code while watching TV?!? What kind of voodoo is this? lol I can listen to stuff, but no way am I actually watching the tube while doing this stuff.
I think that is a bias, but it's a perfectly rational one. Depends on what you spend your time reading.
And you can write code while watching TV?!? What kind of voodoo is this? lol I can listen to stuff, but no way am I actually watching the tube while doing this stuff.
Doug, JonnyMac used to work for Parallax and I attest to the fact that he is a very efficient, accurate coder. His work inspired me to produce interesting projects because I knew the code set would be a solid or far better match for my feeble efforts. At the time we called him "the King of Stamps" - a title he still holds in case anybody thinks they can de-throne him.
Comments
Nubie question. I've used SimpleIDE for C programs. I've used Proptool for spin programs. After reading this thread, I tried to use SimpleIDE for spin programming, but when I try to start a spin project, I get an error message: "Blank Simple Project was not found". I looked in the Simple IDE directories and see "Blank Simple C++.side" and "Blank Simple Project.side" (and its corresponding .c file), but nothing for spin. I tried looking in the user guide, but could not find anything.
How do you create a project file for a spin project?
Thanks
Tom
2. Auto-indent, and allow different tab stops for different sections of the program. Tabs for the DAT section, for example, should conform to assembly tabbing.
3. Automatically scan for a Prop on the available serial ports for loading.
4. Make it possible to compile without automatically saving the source first. (It's no big deal to save to a temp file and compile from there, after all.)
5. Support zip archiving, as is done in the PropTool. (It would be nice if compilation and loading could be done directly from a zipped archive, too, via unpacked temp files.)
-Phil
@Dave: Almost done with a crappy day.
-Phil
PropTool works. But in fact it is unsupported apart from a couple of minor tweeks. I say this because although there have been many requests over the years, PropTool has not changed. So using the same basis, proptool is also dead.
Skimming thru this thread (with a lot of OT discussions) I didn't understand the ultimate statement - Does SimpleIDE support spin ???
Tom
Yes, you can create Spin programs in the editor and compile and load them to an attached Propeller. SimpleIDE allows you to do this with a consistent IDE across platforms and between Spin and C/C++. If you have a Mac or PC running a Linux distribution (ok, Heater?
On my Mac, I just did this:
closed everything,
made sure "Spin" was selected as compiler type in Project Options in lower left window
clicked on "New Project" icon
named the project TestProj in the dialog box and hit save
It created a TestProj.side file with a TestSpin.spin file in it.
The .spin file contained this code:
Away you go with your new project. Not too difficult, especially if your alternative is not being able to use Spin!
For what it's worth I am on Team Spin. I just like it. I have done a few of the Simple IDE tuts in C, and it just wasn't for me. Not saying that I won't do more with it when I have "for fun" time, but it's really not for me. Sure you can run a Diesel engine on recycled cooking oil, but.... (electomanj ducks)....
Actually, I was not even aware that you could program in Spin with Simple IDE until I read this thread. I will have to check that out. I am very grateful that Simple IDE is a choice. More options are great, and anything that makes it easier for someone to program a Propeller is AOK in my book. My thinking was that there are so many many many projects examples out there that are for the aurduino, If I had a little C experience it would be easier to understand them and port them over to the Prop.
I believe the point of the OP was that Mac users can use Simple IDE to program the Propeller in Spin and that fact should be more advertised. I concur.
traVis.
I finally got something to work (sort of) by loading in the Blank Simple Project c-version, deleting everything from that tab, opening a new tab, putting your code in it and calling it "Blank Simple Project.spin" and saving it. I then opened the SDE file in notebook and deleted the c stuff.
I am able to open that manually and I copied (cut and paste) LED-Flash.spin from the prop education kit tutorials. I saved it and I'm abe to open, edit (in IDE), and compile and run the spin program on my QuickStart board.
But I can still not use the New Project icon to start a new Spin Project. (I get the 'Blank Simple Project" not found error, so there is something missing somewhere.)
But, I find the prop tool more useful (at least for someone learning spin) with its indenting, colors, and block indicators, identify hardware, and different file open methods.
Tom
So, that "hard sell"...
I think PropGCC is a great product right now. The hard work got done and we've got a very functional C on Propeller thanks to the PropGCC team. It works, people are getting stuff done, and that is great compared to where it all was some time ago.
The "hard sell" breaks down along a few axis:
1. Size of P1 and it's specialized nature.
Doing most things on P1 is a tight fit. Doing great things is the tightest of fits generally. And we have a speed / size trade off in play too. Actually, C has advantages here because it can leverage multiple memory models. CMM, XMM, LMM, COG, etc... By contrast SPIN + PASM is what it is.
C looks good here because it's got support for memory models SPIN doesn't. Well, not without PASM.
The hardware counters, video generator, etc... in P1 are specialized.
I read things like "standard ways to do things" and yes, there are lots of standard ways to do things. Even the same things. Sometimes I find that difficult to reconcile with the small memory P1 has. Other times I find it hard to grapple with how verbose things like inline assembly are, or the amount of instructions one has to give to C in order to get the output as desired as opposed to simply writing what it needs to be and moving on.
Really pushing the chip can be done in either environment, but the real magic happens in PASM, and the general nature of C and it's assembler, etc... make for more verbose, sometimes less easy to read and understand and often more laborious combination of assembly language and the higher level language.
2. Our roles in life and goals
Reuse is mixed in there too. In this, the P1 excels due to how it was designed. As a multi-processor, we can package stuff up and reuse it really easy in SPIN. I think C needs a lot more of this kind of work done so that there is more to start with. That's part of the hard sell. Regardless of the language merits, the truth is we've got volumes of great SPIN + PASM code to work from and that is a huge resource.
No matter what people think of assembly language, the truth is assembly language shines on smaller systems, particularly when they are pushed to the limits or being employed in ways that were not assumed to be the norm. SPIN incorporates PASM in a clean, easy to understand way. SPIN 2 will continue this blend of assembly and higher level code even more.
And this is lean in SPIN. Really lean. In C, it's work. Work worth doing if one really does want to reuse, but if not? It's just work. That's part of the hard sell, but only for some people.
Hobby people like to work lean and get it done, whatever it is, however it gets done. Great. Students, and I mean people in school looking for a career, or just people learning with a similar intent, are not as interested in lean as they are learning skills they know they can use in a broader context. Finally, there are people who aren't hobby people, aren't students, who just want to get it done, however it gets done, and once it's done, they get paid.
C is a hard sell to the hobby people and the latter group I just mentioned. It's a hard sell because it's not lean. You do work in C that only pays off when you need to reuse, sometimes refactor, or port / re-target. Given those two groups may well be operating under time constraints of various kinds, this extra thickness involved is simply undesirable, wasted.
To the students who are wanting to advance in their potential career, those things are all part of the package, not a worry, and C is a much easier sell to them. Investments being made in time, code, and their skills / practices will be very highly likely to pay off.
The more tight, effective library code we have, the more attractive C will be to all of the groups. Over time, I see this getting done, but it's gonna take time just like it did for SPIN.
I have worked with some people on these things and when they know stuff from their past experiences, C can make a lot of sense. If they are new, to it all, SPIN + PASM is a great place to learn things. It's lean, and you really don't have to know much to make the magic happen. You really don't have to keep track of as much to make it happen either.
3. Ideologies / standards / politics
Ugh... I almost don't want to write this part. But I'm going to.
The idea of standardizing as much as possible, reusing as much as possible, etc... brings us advanced, higher level language features to accomplish those things, but it also brings complexity too.
I see this constantly as if it's the one true best practice! Truth is, it's not. Some of us care about this, some of us care a lot. Others could care less, or maybe care a little.
Just a while back, on the P2 discussions, I read, "A standard assembler would do..." and I think to myself, "sure, OK" while at the same time wanting SPIN to be SPIN + PASM for the lean, seriously productive environment it is, and it will be those things precisely because it's not standard! Never will be. Shouldn't be either.
So there is a conflict there I find very off putting.
On the P1, we've got a ton of code showing off excellent exploitation of the hardware, and really understanding it at a lower level is encouraged in SPIN + PASM land. Things like "code is documentation" also is often encouraged in SPIN land. Frankly, I love that.
Abstraction, formalization, compartmentalization, etc... are seen as strengths in C land, and the whole thing shifts into a place where suddenly one of us does something cool, and out it all comes! Is that reusable? Can it support A. B. C, D, E, etc... Can we make sure it can run on the not so cool hardware too? ...which is kind of nutty, if you ask me. The not so cool hardware is not so cool because it's really different from the Propeller, or perhaps the Propeller is really different from a lot of other stuff out there. You tell me.
Here's the truth guys. I've dropped a project or two here over those very issues. Did a few in private too, just choosing not to share. SImply didn't want to hear about it. Still don't want to. Now, if I'm on a paying gig, I'll see it much differently! Get paid to do that actually, and it's funny how a few dollars can power through what may otherwise be seen as a lot of work for no other return.
Pro vs Amateur vs Other
When I see C positioned as "the pro solution" and I see "those SPIN faithful" being framed in marginal terms, I sometimes wonder whether or not I shouldn't just pay a couple from each camp to complete a total pig of a problem and see just who kicks whose arses. Then pay again to make a bunch of changes. I would include paying a third time to retarget to new hardware, but I don't see the point there. If the task is generic enough, that can happen anyway. If it's a real challenge on a P1, then the solution isn't going to port easily in general because it will include PASM, etc...
I really don't want to hear about this either. I do want to enable people, not convince people.
Truth is, some of us are here because we want to be. Others are here to make money. Still others are here to learn and build a career. The implication that C is "the way" or "the best way" or even "necessary" often gets linked to the complex compartmentalization, abstraction, and other "ions" that simply consume time and energy at worst, and might yield some savings, if and when there is some reuse in the middle case, and are maybe awesome as library code everybody needs but nobody gets paid to write at best.
4. Summary
Throughout all of that, the P1 is just kind of tiny. It's not really a "pro" chip as we've been told how many times? Too many. And a quick look at P2, shows it's much bigger, faster, and intended to be "pro" in ways the P1 isn't.
Secondly, the easiest sell on C happens to be "pro" minded people, just the kind that aren't so well aligned with a P1, and I hope I've explained a little bit of why.
Has nothing to do with the merits of C or PropGCC. Both are fine efforts, and worth it when indicated too.
So I'll try to add some constructive input. I think all of the suggestions should be organized in a list to determine what can be done, and what can't be. I like the auto-indent idea. It would be very useful for writing Spin and also C. Even C programmers write indented code.
This afternoon I spent some time running Spin programs through SimpleIDE on my Mac. I had a few setup issues with Open Spin compiler not being found, but I put it in the right place and it worked out fine. Next I learned how to define a project which seems similar to naming a top Spin file in the Propeller Windows Tool. And I noticed that the lack of indentation identification can be a problem, but once you're aware of it and you know when to indent for the loops and conditional statements everything works just fine.
Personally, I was really jazzed to be running Spin on a Mac with open source Simple IDE and Open Spin! I think we all know that this tool has been done by Steve (jazzed) on a volunteer basis, right?
Why haven't we advertised Simple IDE for Spin?
First, it's not an intentional disregard, just to be clear. We're pretty limited on resources - time, money and where to apply both of them. To explain that it can be used with Spin means we need to qualify the situation in it's present form (what's in, what's not). We can certainly do this, but we have to be careful not to create expectations that we can't meet about it's future development. You can imagine that in its present form Simple IDE for Spin would cause a new and demanding new developer to wonder if we're all that serious about our tools. But if they understand it's an in-progress effort then their expectations might be met, right? We just have to say what it can and can't do.
The other reason we haven't done much is we'd also like it to be brought up to standard. It's always been my assumption that we have to pay for improvements, and since this is Steve's project we would need to pay him for our improvements (unless somebody else picks up the effort as a volunteer - see below). But Steve's time (and our budget) is currently applied to Simple IDE for C. We met with him last week and we have a list of C improvements we need accomplished. As so much of our revenue from Propeller 1 comes from education, we need to prioritize our effort in that direction.
OK, can you at least show what can be done with Simple IDE and Spin?
Yes! We should show how to set up Simple IDE for use with Spin. It works fine once you get used to the setup and understand the project management part and absence of program flow without indentation indicators. Somebody quoted me above indicating that Simple IDE will provide better support for Spin, and that effort still stands (we're just a bit short on resources to get there). I need to figure out where to do this (on Learn.parallax.com, parallax.com, or somewhere else). For now, it would be an as-is offering without expectations on Steve to make improvements.
How about improvements to Simple IDE for Spin?
Like you, everybody would love to have the improvements identified above. This means somebody needs to first define the features and objectives.
Then, since Steve is pretty booked with Simple IDE for C, somebody else would need to pick up the effort. Steve would probably need to verify, but I don't think he wants to do this unless he's being paid. We don't have budget planned for the effort for the time being.
At least that's how I see it right now. Could it become another Open Propeller Project? We've only released one so far, but it's getting completed and we're ready for more efforts.
Ken Gracey
I seldom read all of your posts because ... well ... they're usually just way too freaking long. But I made an exception this evening, and I'm glad I did. I think you've elaborated ("summarized" would be the wrong word
-Phil
I really don't see a problem with having two main languages. I also don't understand why people are so passionate about what's best, what's awful, etc. C and Spin have their benefits and drawbacks with he Propeller and we all understand them by now, and we should be able to help a forum newbie identify the right place to get started. That'd be a great way to use our knowledge to help the new customer find satisfaction.
We aren't encouraging the use of our GCC compiler for professional applications, in case you were wondering. With few exceptions, all of the volume P1 applications were designed in Spin/ASM. We know that some memory limitations and documentation are a consideration with C and Propeller 1.
As for whether or not we should've held off on C for P1, it's possible that if we didn't create C for P1 there would be no P2 (or it would be far more difficult to fund the process, with funding being the delay instead of the design process). Do you know where the funding comes from to drive the R&D efforts that will bridge the gap towards P2? The educational customer type buys lots of robots from Parallax, so they're a big contributor. If we give them what they want, they buy our products. And this creates net income which we apply to P2. If we didn't make the C compiler, we wouldn't be selling them as much product.
I've also noticed that the educational customer wouldn't look at Spin until recently - now you even see Chinese visitors on the forums asking questions about Spin. They wanted C - and until we gave them C - Spin was irrelevant. Try throwing a programming language barrier on top of a language difference and you're stuck. Now we're getting Spin inquiries from educational customers. Somebody want to port the ActivityBot code to Spin?
Ken Gracey
I think simply presenting all the choices is good. From there, people choose and they should proceed as they will. Some of them will do fine, some will ask for options / help, and some will have various sorts of trouble.
Deal with that as it comes.
Yes, and that is one of the good C things. For those so inclined, it's a great option. I cited it being a tough sell overall. For those running external memory, C should be more compelling, and I would advocate the same thing. Use it, because it makes a lot of sense.
I'm not in any way saying C is bad. It's not. The product is good!
Given what is possible with a P1 and SPIN + PASM, it's a hard sell, also given the rough roles I put out there.
The pro comments are relevant too. P1 isn't a pro chip. That's been established. Experienced C users and students who can benefit from the experience are going to like and use C and they will be productive and successful too. That's because it works.
But it's not the "sweet spot" use case SPIN + PASM is, generally.
Maybe I should put it this way. If somebody has a reason or connection to C, P1 C will make sense to them. Not a hard sell overall. If they don't? Then it's harder, because of how compelling SPIN+PASM is, and the generally small size of the P1 and how that matches up to projects.
P2 will be an entirely different thing.
Both will continue to depend on library code that puts the magic into easily accessable packages. Frankly, we may not see the obex development on P2 due to closed code being a realistic option now. C may well hold an advantage, depending on who does what and whether or not they want payment for it this time around.
-Phil
Does this mean that some people think they prefer C until they actually see it and then change their minds in favor of Spin? If that's the case, then I think my "chumming" scenario has some validity.
That's a truly diabolical strategy, Ken! I fear that I've underestimated Parallax's marketing acumen!
I've considered it! Is funding available for such an endeavor?
-Phil
Yes, this is the case. I've talked to several educators who finally looked at the Propeller and then became interested in Spin when they discovered loads of good objects in OBEX. But I'm also the guy who thinks we need to support iPad programming of the Propeller.
Ken Gracey
-Phil
That's OK. No worries. As I've said earlier, I often think long form and I write best long form. Is what it is. Once in a while, you get a treat in that I'll go short. Great when that happens, isn't it? I think so too.
About that "not a pro chip" thing. Frankly, I think the P1 is brilliant and it's capable of a lot. The non-standard nature of it, plus the community here, etc... just isn't standard or inaccessible enough to be pro, lol. Needs JTAG, kind of a thing. Maybe that's brief enough to get it done here.
I agree with you David, and I also will easily say most people should learn C!
But it's not assembly language, is it? On the hardware of today, that statement makes a lot of sense. Ask somebody who has done 8 bit computing what they think of C as assembly language. I suspect that answer will be interesting and enlightening. Edit: and you know this as you've been around for some time. I didn't mean that to read badly, just trying to get at lean.
Compilers are good now. Better than they were back then. But C isn't assembly language, though it is a lower level, simple, close to the machine type language.
So there is that.
Really though, lean is about the whole process, not just language elements. If we are to talk about lean in the context of what the compiler is doing, yes C is low level. As intended. The next lower level really is a macro assembler kind of thing. Assembly language for real.
Now here is where the brilliance of SPIN, the Prop Tool and PASM come into play. Really, SPIN + PASM is a hybrid! That process is stripped down to the nubs. Even the language of SPIN is filled with little nubs, just enough to get it done, but nothing in excess. No brackets, etc...
The PropTool can just get it done too. One can type in a few things, ask for a compile and run and it simply does. It's often no more complex than that, though it can be. Truth is, I can hook up a Prop, write a few lines of SPIN, maybe some PASM too, and run it on my Prop setup, not even worried about path names. Lean. Sometimes I do this, not even saving. Usually, it's when I want to revisit remembering something I probably knew but need to brush up on.
And all those little operators? Excellent. Know what those do really? I can think of it just like I would in assembly and then just type 'em in, one by one, almost writing assembly. Beautiful. And it does it all, meaning I can treat comparisons as values, or values as comparisons (x := x + (y >5) *30, etc...) and I can shift this, that, add, multiply, mask, whatever and I can do it in whatever units I want! %001, %%0123, $ED, and so forth, use delimiters, and generally make a very readable thing out of what I often find to be that 0xh whatever kind of mess I see elsewhere. Types? My problem, not SPINS. It's gonna do what I ask, and if I ask for something stupid, it's going to give me that stupid thing and maybe I learn something. But if I ask for something brilliant? Does that too.
C shares a lot of these things, but it requires more typing and it requires brackets and such that need to go somewhere. Put 'em in line and somebody gets cranky. Put 'em elsewhere and somebody else gets cranky, put 'em in there inconsistently and I get cranky! And everybody wants longer monitors in any case. SPIN is remarkably free of that sort of thing.
The syntax is lean, but verbose. The formatting possible is verbose, meaning I get a lot of options as to how I can translate what is in my head to meaningful symbols for the processor.
And I can stuff it into one big file, if I want to, or break it into lots of little ones as well. This is lean too, because the most common options are there and they make sense. So I don't really have to conform to much beyond the basics. Structure my file how I want. Put my data where I want. Include what I want, or include absolutely nothing. No worries.
Some of that gets tough.
One of my internal benchmarks has actually been graphics_demo.spin That thing has generated more SPIN questions than I expected. And those operators and such were used perfectly in that one too, Chip just packed a lot in to a small space and many of us struggled with that. I don't know how many times I helped somebody out with the colors and the tiles, and the many operators just didn't do us justice.
That one could have been written longer form and it would have been much better. So there you go. Not everything is great. I liked that one actually. Looking at that one program taught me enough SPIN to get to work that day. Sweet! When I needed more, there was more, but a whole pile of what I needed was right there in that one fun program. Gotta love that.
The same was true for PASM. Parsing one video driver took a bit, but then I had enough PASM to go and do lots of stuff. To this day, I don't think I've tried all the instructions. But I got magic done fast and pretty easy and I didn't have to track much and in some cases know all that much. That's lean on a few axis.
I didn't need to read a manual to start writing PASM. In fact, I started writing PASM the same way I did years ago on the 6502. Looked at some code and took off! Since the assembler was right there, I didn't even have to open another book. Prop Manual contained the goods. One stop magic shopping!
With C I have to know my editor, and which one, my compiler and it's many options, my assembler, and so on. And those are big things intended to operate with damn near anything! Now that is awesome because the same GCC that helped me write OpenGL code on SGI can help me write P1 code, but I still have to know all that stuff or at the least track it. With SPIN+PASM, I don't. There is a program that takes my text and it generates an image that goes into my Propeller. Done, next. Lean.
Now don't get me wrong here. I really like Sublime, and that same tight package made it hard for us to do things we want to do, like use our own editor, or use a post processor, etc... We are fixing that. Good. It will be a little less lean, but then again, we could still package it all up, hide it, and keep the simple, lean nature intact for those so inclined to just jump in. Recommend we do. The ones who don't want that will take the pieces and build something they do want and run it on what they want to run it on.
Heck, I may just go buy an IRIX machine to develop on again.
With SPIN 2, we are going to get SPIN plus inline PASM and it's going to be one stream of code that we can make what we want out of. The syntax of both are written together and they work together and that's probably enough.
The only other thing I've seen do that are some of the old BASIC languages, like the BBC Micro, which allowed a very similar kind of thing to happen, sans a syntax as beautiful. (For the time, it rocked hard though)
And that right there is a great analogy. C compared to BBC Basic + Assembly. The same dynamics were in play back then, and the same definition of "lean" I'm trying to convey is present and accounted for.
Now many here will ask, "why?" do that. And out it will all come. Not portable, not standard, not encapsulated, not abstracted, not compartmentated, and so on. Who cares? I sure don't. I want to see the magic. Now. And back then it was interesting. The people who were on open machines that included core tools, including assembly language tools, monitors and such developed very differently from those who ended up on machines that were more closed up, or where multiple packages had to be used.
When this stuff really matters, or somebody is paying me and they don't want voodoo, fine. I'm happy to packagize, compartmentalize, abstractalize and sterilize the whole thing to whatever spec pays the bills. Do the work, in other words, that I can avoid doing in SPIN + PASM.
And I like C. But C is work. SPIN is fun. PASM is really fun. And now we are back to the roles and dynamics I mentioned earlier, so that's it. Maybe that helps some to understand.
One last thing. C might not be work. Put me on an SGI, and C is fun! Bigger machine, we get away from the bits and we get closer to higher level things. Had a great time doing that. Learned a lot. Put me on a PC today with some higher order tasks, and I might actually say C is too low level, not a bother, similar to assembly is for many people.
Heater has me thinking a lot about Javascript... for example. So "work" is really very relative to our roles, goals, and the hardware we operate on. Lean is impacted by this too.
A lot of the lean perception has to do with the overall capability / resources and such associated with the thing we are wanting to develop for. C can stretch from the little devices to the really big ones and with that stretch comes some necessary thickness in process, things to track, etc... that need to be there and work great. But they are there, and on a P1, we don't always need them to be there to get the magic out today.
C can actually be seen as tedious compared to other, higher level languages we've got, and on the bigger scale devices we've got the room to relax and have fun all over the place. On a P1, we don't have that room, and the lower level, smaller scale access makes a lot more sense, and SPIN + PASM was made to do exactly that, no more. Lean.
Start a thread where we can post code -- I've picked off a couple easy ones while watching TV.
And at the risk of sounding biased, the Spin code is SO much easier to read than C.
And you can write code while watching TV?!? What kind of voodoo is this? lol I can listen to stuff, but no way am I actually watching the tube while doing this stuff.
Give us two days, JonnyMac and we shall do that (Open Propeller Project). You're a great asset to the Propeller.
Ken Gracey
Doug, JonnyMac used to work for Parallax and I attest to the fact that he is a very efficient, accurate coder. His work inspired me to produce interesting projects because I knew the code set would be a solid or far better match for my feeble efforts. At the time we called him "the King of Stamps" - a title he still holds in case anybody thinks they can de-throne him.
Funny, I actually found one of my "King of BASIC Stamps" business cards in an old computer case the other day.
Now I'm the happy "Proselytizer of the Propeller"! -- did my best to support that moniker at the Hackaday event last week.