 |
|
 |
| Parallax Forums > Public Forums > Propeller Chip > How would you describe Spin as a language? | Forum Quick Jump
|
 | 
Phil Pilgrim (PhiPi)
Registered Member
      
Date Joined Feb 2006
Total Posts : 6000
| Posted 10/31/2009 11:49 AM (GMT -8) |   | It would be interesting to see a survey of Spin approval ratings vs. age of the respondents. If a person is hidebound by experience with traditional languages, would he be less apt to like Spin? Would those who are less experienced be more likely to embrace Spin for its terseness and utility, despite its iconoclasms?
I hope that Spin (perhaps with a few tweaks and extensions) persists with the Prop II. Despite being difficult to categorize, it's the right tool for the Propeller.
-Phil | | Back to Top | | |
|
Nick Mueller
Registered Member
Date Joined Apr 2007
Total Posts : 697
| Posted 10/31/2009 12:51 PM (GMT -8) | | > With a couple of exceptions (most notably the very efficient but hatedly obscure ~ and ~~ operators) everything in Spin is found > somewhere else. They aren't all found in one language,
That's exactly the point I meant with patchwork!
I'm not complaining of the ritch set of operators, but the fact that they are taken from languages that are quite orthogonal. A much clearer solution to add those extra ops would have been:
Take a route that is known (like Pascal, or C) for the common operators and add the extra ones by function-lookalikes. That wouldn't have added more code.
> This is as stupid as the Comp Sci teacher I had back in 1981 who insited "byte" meant "any subdivision of a word" instead
> of "8 bits."
Fortunately, I didn't say that!  And even didn't want to say it.
> On embedded platforms in particular a word is 16 bits just as a byte is 8.
On 16 bit processors? So, I'm right.
> As for using the word length of the machine in any meaningful way, that's been dead since IBM advertised the 8088-based IBM
> PC as a "16-bit" processor back in 1982.
So they were the first one to make that nonsense? Websters dictionary: Word ... and which functions as the smallest meaningful unit of a language.
> Only because it doesn't do YOUR VERSION of OO. In 1970 it would have been considered quite radically OO.
What date do we have now? "Object" has a quite well defined meaning in any programming-language taht is OO. And Parallax's use is an abuse of it.
> But if you mean "educating people how the damn computer works and therefore how to write better code in their modern
> high-level environments" then you fail it.
So there is no need at all for a high(er) level language. Bite the PASM thing or die!
> Unless you mistyped "safe"
I did that. It's hard for Germans to distinguish safe and save.
... the first tool in writing safe code is learning the hard way to write safe code in an unsafe environment.
Well PASM. See above. No need for SPIN.
> And by the same criterion I insist to this day Grandma Moses can't possibly be an artist,
> because nobody ever taught her how to paint right.
OK, so it is naive art! LOL!
My point is not, that SPIN is different. My point is, that it is different in needless places.
There are derivates of languages like Tiny Pascal, or Tiny C or whatever you want. They do work, they do have shortcuts and additions are welcome to.
Nick
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO | | Back to Top | | |
|
SamMishal
Registered Member
Date Joined Jan 2006
Total Posts : 330
| Posted 11/1/2009 12:43 AM (GMT -8) | |
Heater
As for Spin adoption vs age/experience. What's the problem? I've programmed in a lot of languages over the years, all the way back to Algol. Spin is just another one, with it's own quirks. Seems to fit the task at hand very well.
Brad C
Spin is incredibly elegant, compact and quite efficient. It's a very easy environment to be productive with, and it's little quirks are very easily learned.
As my Grandfather is always fond of emphasizing : "A poor workman always blames his tools."
Phil
I hope that Spin (perhaps with a few tweaks and extensions) persists with the Prop II. Despite being difficult to categorize, it's the right tool for the Propeller.
Potatohead
I would describe SPIN as lean, useful, easy to learn, and well matched to the processor hardware attributes. There is nothing else like SPIN + PASM.
Stefan
In my eyes Chip did a really great job. The architecture, SPIN-syntax, the propeller-IDE everything well developed to work effectivly
Localroger
An original language, designed to teach concepts and to be learned easily no matter what previous languages you know.[..]. It truly is a synthesis of the strengths (in a very particular manner of evaluation) of many different approaches.
WELL SAID............... 
João
I'm with Nick on this. SPIN is a very strange language.
Nick
Spin is a basic patchwork of different languages. The result is:
SPIN is crap, but it works and its a compact language. And only worth learning because it comes along with the processor.
waltc
Got to agree with Nick on a few points
Spin is totally unsuited to teaching beginners programming or learning about micro-controllers for that matter.
To you guys all I can say is what BradC's grandfather used to say.......... "A poor workman always blames his tools." 
Samuel
Post Edited (SamMishal) : 11/1/2009 8:48:30 AM GMT | | Back to Top | | |
|
Nick Mueller
Registered Member
Date Joined Apr 2007
Total Posts : 697
| Posted 11/1/2009 1:10 AM (GMT -8) | | > Obviously the major problem of Spin is its very limited speed ...
That's not the problem. The design-goal was to get compact code (HUB-RAM limitation) and that was perfectly achieved. You can't have something fast and compact. Overall SPIN and PASM is a nice fit. I'm only complaining about the syntax.
In fact, most of the issues could be fixed with a pre-processor.
And re the byte, word, long:
Languages that didn't care about the processor behind it don't have a rich enough set of sizes that works good with µC. C made it wrong quite from the start and only fixed it with C99. For a language that is µC-centric, types like int8, int16, int32 and uint8 (+ char as a synonym), uint16, uint32 would be the most clear and obvious naming.
Nick
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO | | Back to Top | | |
|
waltc
Registered Member
Date Joined Jul 2008
Total Posts : 145
| Posted 11/1/2009 9:25 AM (GMT -8) | | Well Jazzed I'll take Oberon(Wirth's successor to Pascal) or even TP7 as a intro to learning computer programming any day over Spin. Spin just doesn't have the HLL features to be useful and because its typeless which allows newbie coders to produce head scratching unreadable code.
I'm sure though some of the resident compiler writer gurus here could rewrite Spin and turn it into a language that generates machine code and also be useful for CompSci by including some features of C and Pascal, like type checking, bytes, 16 bit and 32 bit integers, chars etc.
As for Spin teaching about micro's, C or the micro's own assembly language would be a better fit. | | Back to Top | | |
|
Ken Gracey (Parallax)
Forum Moderator
Date Joined Jul 2004
Total Posts : 1972
| Posted 11/1/2009 9:38 AM (GMT -8) | | Obivously I'm a proponent of Spin - wouldn't like it any other way! I think this is a result of my limited programming background. The only devices I've ever programmed are Apple II computers in BASIC, BASIC Stamps, SX chips (in SX/B) and the Propeller. No C or C++ experience and only enough Java with the Javelin Stamp to know I didn't want much to do with that particular language. Perhaps my limited experience is best in this case - I can do everything I've wanted to do with the Propeller and I don't know what friendly aspects are missing from Spin that are present in other languages.
The learning curve isn't steep for me, but a steady climb. The biggest challenge has been rethinking how to make use of multiple processors and tie them together in a useful fashion.
Going back to PBASIC, when we first started Stamps in Class we heard much criticism about BASIC not being appropriate in education. Around this time there was even a push (in California) to use Java for embedded programming (because it was being accepted for PC/web programming). PBASIC certainly made its way into schools and industry even though it is quite limited. Therefore I'm not surprised to read this kind of thread - it's a common consideration of Parallax customers going way back when. We won't tell you what to think about our languages, ever, but there's a strong belief in our office that these languages fit our processors quite nicely.
We're sticking with Imagecraft to see that we've got the C support so many people from industry seem to want.
For me, Spin simply works!
Ken Gracey
Parallax Inc. | | Back to Top | | |
|
localroger
Registered Member
Date Joined Mar 2009
Total Posts : 417
| Posted 11/1/2009 10:09 AM (GMT -8) | | | Ken, I've been programming since 1977 -- my first big project as a teenager was my own BASIC interpreter, written in 8080A assembly language with only an assembling debugger (no compiler). I've written several similar languages for embedded controllers for my own use in the years since.
I found out that the Propeller existed when Hackaday featured the Ybox2. Within about half an hour of diving into the online docs I felt I had found home. Spin is a perfect language for the level of development it's aimed at; probably the only thing I'd have done differently if I wrote it myself is using indentation for block framing, but I have an idea why Spin does it that way. And I'd have put in GOTO because I'm lazy.
Spin forces you to be aware of important concepts that will bite you in the posterior if you aren't aware of them, and which aren't generally taught any more in formal curricula. How many people really know the limitations of floating point math? Just recently Slashdot linked an article about a bug in the Patriot missile system caused by the fact that 0.1 cannot be represented exactly in binary, and they were adding 0.1 second clock ticks together until the errors amounted to more than a third of a second. Now I knew better than to do that when I was 16 years old, how the hell did a mistake like that end up in a production defense system that ended up costing over a dozen people their lives when it failed?
Learning to use things like polymorphism and multiple inheritance can make you a very productive coder, but before you even learn such things exist I believe you should know things like how to do binary math. If you believe one should never optimize code, I don't want you working on my project and I want the person who taught you that fired. If you think anyone at all should ever program a computer without knowing how the high level commands they write are converted into action by a CPU, I encourage you to find a rewarding career in car sales.
And this doesn't mean there isn't a need for more powerful languages with more advanced features. It just means that (1) those languages aren't appropriate for a platform with 32K or even just 256K of core, and (2) you should never go near those languages until you have a firm grasp of the concepts that are necessary to write working code in simpler ones. | | Back to Top | | |
|
SamMishal
Registered Member
Date Joined Jan 2006
Total Posts : 330
| Posted 11/1/2009 10:09 AM (GMT -8) | |
waltc said...
Well Jazzed I'll take Oberon(Wirth's successor to Pascal) or even TP7 as a intro to learning computer programming any day over Spin. Spin just doesn't have the HLL features to be useful and because its typeless which allows newbie coders to produce head scratching unreadable code.
I'm sure though some of the resident compiler writer gurus here could rewrite Spin and turn it into a language that generates machine code and also be useful for CompSci by including some features of C and Pascal, like type checking, bytes, 16 bit and 32 bit integers, chars etc.
Officer: "Sir, do you realize you have been driving at 100 MPH in a 35 MPH zone?"
Driver : "Yes officer....it is not my fault though...my Ferrari does not have built into it any speed
checking or limiting devices and it is just...."
Officer:"But sir what is that dial called speedometer in the middle of your dashboard for? Also
I am sure your car does not have infinite speed does it?"
Driver :"Yes I could see the dial showing I was at 100 but shouldn't a good car limit my speed by itself?
It should know when I am being a fool and stop me from doing it...no? It should also stop me from
having accidents and not go off the road when I sleep on the wheel and...... "
Officer:"Sir...perhaps you should not be driving a Ferrari...perhaps you should be driving a horse and buggy...
then perhaps you would have developed some horse sense.....here is your ticket!!!"
Post Edited (SamMishal) : 11/1/2009 7:13:01 PM GMT | | Back to Top | | |
|
localroger
Registered Member
Date Joined Mar 2009
Total Posts : 417
| Posted 11/1/2009 10:52 AM (GMT -8) | | | @Nick: That's exactly the point I meant with patchwork! I'm not complaining of the ritch set of operators, but the fact that they are taken from languages that are quite orthogonal. A much clearer solution to add those extra ops would have been: Take a route that is known (like Pascal, or C) for the common operators and add the extra ones by function-lookalikes.
There is a word for this practice of taking new and different paths that promise to let you do more with less, in this case less typing. I think it's called "innovation." You are saying this is a bad thing...?
> On embedded platforms in particular a word is 16 bits just as a byte is 8.
On 16 bit processors? So, I'm right.
You're just arguing to hear your own voice here; you know exactly what I meant and why I made the prior comment about bytes vs. subdivisions of a word. Today a word generically means 16 bits, and it means that on processors of any bit width. Most platforms use "doubleword" and "quadword" for 32 and 64 bits respectively, but I happen to think "Long" is clearer. It does take a little getting used to, and even I still sometimes type "word" when I mean "long," but the end result is much more readable particularly considering how we often mix types to save RAM.
"Object" has a quite well defined meaning in any programming-language taht is OO. And Parallax's use is an abuse of it.
Spin objects have public and private methods, the public of which are accessed by the industry sentence object.dosomething() syntax, they hide their data, and they can have multiple instances. These characterstics alone separate Spin from all non-OO languages (particularly as the first two are features that limit the programmer and force him to think in a more modular way). The fact that Spin objects don't also have classes and inheritance does not mean they're not objects, and I think Spin is a good foundation for moving to a language with a more powerful OO model. I think starting with Spin is much better than what is commonly done nowadays, which is to teach the OO model as if it's a foundation supported by magical elves so that we have no effing idea what went wrong when it doesn't do what we expect.
So there is no need at all for a high(er) level language. Bite the PASM thing or die!
No, it's not to say more powerful tools aren't useful. It's to say you should not use them until you know how they work so that you won't misuse them and you can fix them when they break.
Look Nick, this isn't theoretical. I use a device every day which was programmed by a guy who is actually quite brilliant who graduated CS in the early 90's. Now this box does amazing things; the codebase is still in use on its successor instrument and it revolutionized my industry. But until a couple of years ago it was miserably dog slow executing end-user code -- so slow I ended up hacking it and writing my own language for it, which ran 50 times faster than the one implemented by the factory. (Originally after hacking it I wrote some apps in ASM, but that does get tired quick. Fortunately, knowing the ASM made it possible to write my own higher level tools.) Eventually I showed the factory what I did and they sheepishly went back and did some of that optimization you should never do. Turns out the original author took a course in compiler design, so he wrote a parser into the interpreter that worked like a compiler parser. Nobody had ever told him that byecode might be useful or that even interpreting plain text there are much better approaches. For want of his school ever showing this guy a copy of the Tiny BASIC source code, we end users had to put up with this sluggish performance for over a decade.
Another fun fact is that, when we got the beta instrument for evaluation in 1995, one of the first things we did was to hook it up to a small scale and program it to count by 0.2 lb, a common application. Imagine our surprise to see it occasionally toss out an odd digit in the least significant place. Turns out the brilliant guy who wrote an industry changing user interface had decided to get plenty of precision for any purpose by throwing double precision math at everything (and on a 20 MHz 16-bit box with no coprocessor this didn't help the speed any, but they thought it was a good compromise). Too bad nobody ever got around to telling him that the double precision routines don't do their own rounding -- CPU cycles having been somewhat expensive when those libraries were written, the authors figured you'd want to wait and round at appropriate times during complex operations. They finally got all the FP rounding issues resolved but it took almost a year.
Oh, and the firmware for this box was written in C++ with OO methods all the way -- I've seen the source. You'd have loved it, except for the times it didn't work. | | Back to Top | | |
|
jazzed
_oOo_(^^)_oOo_
Date Joined Jan 2008
Total Posts : 2114
| Posted 11/1/2009 11:45 AM (GMT -8) | | @Ken,
Javelin is substandard Java. PBASIC is better than the crap I had to learn as a teenager on the C64.
Spin/PASM on Propeller is mostly a very nice achievement.
It took a while, but I finally concluded C is not practical on the current Propeller because of code size and performance in any form (ImageCraft, Catalina, or otherwise). Even with a byte-code like emitter/interpreter which would allow bigger programs, performance would suffer and space would still be tight. It seems promoting C more than a check-off item (or possibly at all) is a mistake except maybe to die-hard fanatics. In retrospect, I'm honestly sorry to have ever been a fan of the combination. There are many other more satisfying platforms for C in the micro-controller class. Maybe Propeller II will be a better fit, but that is just an attention keeping fantasy until it goes on sale.
Spin/PASM is your niche' ... enjoy that for what it is and promote widely it for what you think it should be.
@Waltc, I agree some HLL stuff is missing, but I'm spoiled by abundant memory and advances in the art provided by machines well beyond the micro-controller class. I would also appreciate some method signature type-checking (and other errors/warnings) for the times when I forget. When it comes down to it though, it is the student's responsibility to seek knowledge and ability beyond that afforded by "academic leveling." | | Back to Top | | |
|
Nick Mueller
Registered Member
Date Joined Apr 2007
Total Posts : 697
| Posted 11/1/2009 12:42 PM (GMT -8) | | > There is a word for this practice of taking new and different paths that promise to let you do more with less, in this case less
> typing. I think it's called "innovation." You are saying this is a bad thing...?
Oh, you call that innovation!? Think about whom these weird operators that are flipped compared to other languages help:
A newbie to programming? No, because there is no background
A experienced programmer? No, because there is some background.
Look at how Obj-C made things. It requires more typing, but keeps the syntax simple an readable. Admittedly, things looks quite strange at the beginning.
> and even I still sometimes type "word" when I mean "long,"
How can this happen. When a word is always 16 bits? The problem here is, that two worlds are mixed. Byte is hardware-related, word is hardware-related, long is abstract. Stay within one context and things are clear. For µC-centric programming, types that show clearly what size they have is the way to go.
> Spin objects have public and private methods, ...
It doesn't support data-hiding. Private/public.
Also the lack of "header-files" doesn't make clear the encapsulation-principle. You have to wade through the complete source to find out what might be public or might be private.
That's an important element of objects. You *can* do OOP in any language.
What SPIN does are just codeblock, or reusable code. But then, it still lacks the headeer-thing.
> It's to say you should not use them until you know how they work so that you won't misuse them and you can fix them when
> they break.
An educational language should be very strict in all aspects. Admittedly, that's an impossible goal for µC. I do not think that C is good for teaching programming concepts. I still think, that Pascal (or Modula) is one of the best languages for starters. But again, not very well suited for µCs. So µCs arent the thing to start programming.
> I use a device every day which was programmed by a guy who is actually quite brilliant who graduated CS in the early 90's.
Well, I don't understand what this has to do with SPIN. Bad designs can be done in every language
Again, what can be done in SPIN on the Prop fits the platform quite well regarding size and speed.
> Oh, and the firmware for this box was written in C++ with OO methods all the way -- I've seen the source.
> You'd have loved it, except for the times it didn't work.
I'm not an OOP-advocate! I even think that real OOP is the wrong tool for µCs. C++ for the Prop would be completely useless (maybe the Prop II changes things). He's to small for that. But how about Occam?
Nick
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO | | Back to Top | | |
|
localroger
Registered Member
Date Joined Mar 2009
Total Posts : 417
| Posted 11/1/2009 2:18 PM (GMT -8) | | Oh, you call that innovation!? Think about whom these weird operators that are flipped compared to other languages help:
Actually, the process by which Spin gets its operators is pretty straightforward:
- The ones that exist in BASIC are adopted straight, except for >= and <=. The BASIC logical operators are the ones that coerce to -1, since it makes more sense to use the spelled out words like AND and NOT in IF statements.
- The separate bitwise logical operators, are taken from C-like languages, since SOMETHING has to be used and this is a place they are consistently found. This set also includes equality and inequality.
- Operators not normally found in HLL's but available to the CPU are represented with various shorthand often used in CPU documentation, like >>, or those modified to provide an alternate version such as -> when necessary.
- The assignment form, which does not exist in any BASIC I've ever used, is created by appending = to the operator, which creates the problem with => and =<. I suppose he could have done that the other way e.g. =+ instead lf +=, but if it was me I would have probably put the equal after too, since I read that as "plus (with assignment)" instead of "assignment (with plus)."
- The assignment character is made := to make it consistent with other assignment operators, boolean equality, and constant assignment.
If you keep this in mind, then moving to one of the languages that support a subset of Spin is pretty straightforward; I'm much more likely to trip up by leaving THEN or END IF out of a VB program after working in Spin than I am to try using +=.
> and even I still sometimes type "word" when I mean "long,"
How can this happen.
It happens because I've gone from the "default data size" being 16 bits in most of my work to 32 bits in Spin. I have also typed "word" instead of "dword" for FASM. Outside the specific context of a 32-bit processor where "word" is being used in its obsolete sense as "processor fetch size" I have never seen plain "word" used to denote 32 bits. That's "dword" or "word32." Put your x86 assembler in 386 mode -- which is a 32 bit processor by any meaningful definition -- and try assuming 4 bytes is a word and see how well it works.
An educational language should be very strict in all aspects
NO! NO, NO, NO, NO, NO! 232 times I say it, THIS IS COMPLETELY WRONG. Strictness is a crutch. If you learn to walk on crutches you will never be able to walk without them. This is exactly why I think Spin is a GOOD language to learn with. It is much easier than .asm but forces you to learn many of the same concepts in order to succeed. It does this while exposing you to concepts which will be useful in more powerful HLL's such as those parts of object orientation that encourage code modularity and reuse. It is a quicker path to being ready for the higher levels, where you can let the machine take care of things without becoming helpless when the machine surprises you.
Well, I don't understand what this has to do with SPIN. Bad designs can be done in every language
Please re-read what I wrote, because I did not say it was a bad design. A brilliant programmer made some mistakes which he would not have made if his programming environment and his education had not abstracted away some relatively simple things he could have easily learned and should have known. He was brilliant and remade an industry but he embarrassed his company because the people who taught him showed him classes and polymorphism when they should have been teaching him how floating point math works.
You are trying to make more people who will screw up in the same ways. Please stop.
I'm not an OOP-advocate!
So, you're just a contrarian? You're certainly passionate in your insistence that Spin is a piece of crap. | | Back to Top | | |
|
potatohead
640 Pixels... :)
Date Joined Sep 2006
Total Posts : 1340
| Posted 11/1/2009 5:50 PM (GMT -8) | | Re: Headers files and other cruft.
I am pleased these things are not on Propeller. Others here have noted the low overhead nature of SPIN, but I thought I would comment a bit further on it.
It seems to me SPIN contains just enough for people to build complex things --if they are careful. The balance of necessary overhead and practical code elements that do things is well realized in that a few lines of spin is productive to a degree not found often. As somewhat of a newbie, in that I've done programming on and off my whole life. Nick highlights something I think cannot be stated often enough about Propeller in general:
"Spin forces you to be aware of important concepts that will bite you in the posterior if you aren't aware of them, and which aren't generally taught any more in formal curricula. How many people really know the limitations of floating point math? "
I'm regularly experiencing stuff like this, and it only happens in those kind of raw environments where a programmer is free enough to do stuff --and free enough to really $%*&#(*$W^ it up! This is a good thing. The lack of hardware FP and even multiply puts the focus back on computing math. This also is a really good thing. (and challenging for me personally, in that way I remember as a kid figuring out the implications of binary, with friends on a chalk board because we had no-one to guide us otherwise --each thing realized was like gold, and doors opened wide each time)
On this note, before I make my last point, there are builders and selectors. The selectors are not always happy with a Propeller + SPIN + PASM. The usual checklist of goodies is not well fleshed out, meaning some creative work is required, or glue chips are required to realize a solution. On the other hand, I've noted the builder types love the thing, and how it's designed is part of why. The silicon isn't all that rigid, and it's well engineered, meaning the more grey matter applied over time, the smaller, cheaper, and more robust the solution is. I see this as the very best of properties, and it's why I'm here enjoying with the rest of you. Our skill does not matter, but the journey does. It's is both practical and possible to just take an hour and try something on a Propeller, then walk away, with little other investment required. SPIN is a big part of that.
Has anyone noted the ease with which code can be combined into a greater whole on SPIN? If it had more overhead, this task would be onerous, like it is on just about every other "re-use oriented" environment I've experienced. What I find most intriguing here is that I might not like how some other code is built, but I find I can deal with it more rapidly in SPIN, and part of dealing is understanding mind you, than I've experienced before. So, there is your balanced point regarding structure -vs- free form / language best practice, etc...
On speed:
Unlike most, I see spin as quick! Hell, it runs like assembly language on my old computers! Where I come from, that's fast. Damn fast for such a simple, readable language. When used on multiple COGs, or coupled with PASM, it's then really fast. I guess these things are relative.
Perhaps many of the speed expectations are a function of not building out PASM where it would be most useful. On that note, has anyone noted the near 1:1 relationships between SPIN and PASM? This is so sweet, in that it's possible to use SPIN to proto something up, applying techniques to be used in PASM on a second pass. Again, the overhead would spoil this, if it were more inclusive.
So there's my contribution. Maybe I'll add this:
I was away from this hobby for a long time. I left right at the dawn of the PC, moving to higher level software and networked systems, up to and including big NUMA boxes with 30GB RAM, 16CPUs, multi this disk, network and one OS image (if it was an SGI that is), etc.... Over the years, I watched micros grow, saw cool projects, and thought about returning more than once. One of the things that stopped me was libraries, header files, and other cruft that took away from just doing stuff.
One look at the Prop, SPIN, PASM, and I was back in the game, able to do things and enjoy the medium with very little overall investment up front. On Propeller, that investment can occur on the back end, if somebody wants to, and that plus the very friendly design where a few parts on a bread board does interesting things with few hassles, means the barrier to entry is the lowest I've ever seen. I am here because of that, and actually thinking of branching out someday to a few other chips to build things. Having to go the other way may well result in just not doing it, because of that barrier to entry.
So I lied! One final point:
There is nothing on Propeller, and in SPIN in particular, that prevents one from writing advanced code. The overhead elements must be built by the author of course, but they can be built, and once they are, what is the difference then? The only thing I see is a bit of management required, but there is management at that level anyway, so why not then just manage and use the thing as it is meant to be used?
(I never really grokked language battles because of this)
So then, rather than shoe-horn propeller users in to some paradigm (hate that word, but it's appropriate here), the core elements exposed to us are about as complete as they can be in SPIN, without having to go down that road. Having met Chip and having discussed this "go your own way" approach to computing, does anyone really expect anything less? Here's the noodler: Would the mind that doesn't grok this be capable of the Propeller in the first place? I personally don't think so, and that's part of the attraction, IMHO. (and a nice compliment to Chip, who is probably grinning at this thread)
Edit: To sum up, from a step back, I see the Propeller as kind of an older school, hard core statement to the effect, "See guys? It just does not have to be ugly to kick some ass!". I've laughed more than once seeing somebody declare the thing a toy, then seeing their jaw drop at that "toy" doing some of the things we do here for entertainment.
Cheers all!
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!Post Edited (potatohead) : 11/2/2009 2:05:42 AM GMT | | Back to Top | | |
| 110 posts in this thread.
Viewing Page : 1 2 3 4 5 |
| Forum Information | Currently it is Saturday, November 21, 2009 11:30 AM (GMT -8)
There are a total of 393,855 posts in 55,536 threads.
In the last 3 days there were 84 new threads and 706 reply posts. View Active Threads
| | Who's Online | This forum has 17692 registered members. Please welcome our newest member, old guy.
65 Guest(s), 13 Registered Member(s) are currently online. Details
heater, Siri, Kenny Gardner, keith_kw, Jay Kickliter, mctrivia, Alsowolfman, Shawn Lowe, dMajo, Harprit, Beau Schwabe (Parallax), Leon, MicroDirk |
Forum powered by dotNetBB v2.42EC SP2.02
dotNetBB © 2000-2009 |
|
|