 |
|
 |
| Parallax Forums > Public Forums > Propeller Chip > How would you describe Spin as a language? | Forum Quick Jump
|
|  ElectricAye Registered Member

       Date Joined Jul 2008 Total Posts : 972 | Posted 11/1/2009 6:03 PM (GMT -8) |   | | Why are you guys spitting hairs over whether SPIN is somehow elegant or clunky? What feeds into any kind of computer code is, first and foremost, our own mental processes. Are we to presume that our own human mental processes are somehow so elegant that a computer language could, at least in theory, result in program elegance of any kind??? Take a look at human language. It's full of idioms , artifacts, ambiguities galore, and it's been in development for hundreds of thousands of years. Nevermind all the unconscious neural processing that's been in the works for 3 or 4 billion years - and look how messy that can be. Alas, no computer language will ever be able to overcome our own internal disconnects. I don't have much experience with various computer languages but it seems to me that computer languages are somewhat like bureaucracies: they're full of jarring inadequacies and jolting contradictions but if you want to get something done, you've got to swallow your common sense and bite the bullet. | | Back to Top | | |
 |  Cluso99 We live onboard

       Date Joined Apr 2008 Total Posts : 2277 | Posted 11/1/2009 6:46 PM (GMT -8) |   | My turn LOL. Peter, wow, you opened a big hornets nest here.
I have been programming since 1970 for fun - I had access to a Univac 1004 at work and used to use a small program to print out punched cards for our club sailing results. I went commercial hardware in 1974 and added programming in 1975. I have professionally taught many engineers hardware maintenance and programmers programming courses on the Singer System Ten minicomputer. I have designed hardware and programmed using many micros since 1976.
As many of you will know, I studied Chip's Spin Interpreter and I had a working version running about 20% faster before I optimised a little more and introduced a bug and got sidetracked. Chip's Interpreter is simply brilliant, although, like a lot of micros, squeezes a lot of code into the 496 cog longs and therefore makes some of it a little hard to read. I didn't have the same requirements as chip, so I was able to simplify and speedup the code by placing the decode table in hub ram.
As for the comments about byte/word/long... A byte is 8 bits, word 16 bits, long 32 bits. Period - So get over it ! The jury is still out for 64 bits and this is not an issue here.
Now to SPIN as a language...
ADVANTAGES
- Forces indentation - forces readability of code
- Good set of instructions (if, repeat, etc)
- Works great with PASM
- Works great with multiple cogs
- Largish programs
DISADVANTAGES
- I don't like the operator shortcuts like ~ ~~ >| etc as they make the code less readable
- Sometimes I think endif, etc would have been nice - but more typing. I still want enforced indentation.
- Slow - use PASM if you require more speed
The disadvantages of 1 & 2 can be sorted with a compiler change. I can get 20% speed improvement from my version of the interpreter but I don't think this is as much an issue as it is made out to be. If you require real speed, then PASM is required.
Some of us are trying to make the prop do things it was not ever meant to do. This is natural. And it is doing this extremely well
The prop is after all, a microcontroller. It has a lot more ram than most microcontrollers. And 8 processors if fantastic.
In summary, SPIN & PASM make a great mix for the prop.
- It is easy to get running, even for the novice. No complex things to understand.
- Great intro for beginners - both hardware & programming
- Able to use existing Objects with ease
- A version of Basic to bring over the Stamp guys and gals is close
- Hanno's 12-Blocks can even teach 5 year olds.
- We have some great objects (FDX, keyboard, TV, VGA, SD, etc) which make using spin/prop simple.
Chip has done some amazing things here. If you don't like SPIN or PASM, use C (2 versions) or PBASIC when it's done. FemtoBasic is here, as are other languages. If you don't like any of them, go find another micro We can better spend our time developing, than arguing.
BTW - it was mentioned trolling through an object looking for PUBS. In the PropTool Editor, select the summary? option at the top (learn your tools) Links to other interesting threads:
| | Back to Top | | |
 |  turbosupra Registered Member
        Date Joined Sep 2009 Total Posts : 97 | Posted 11/1/2009 8:26 PM (GMT -8) |   | | I would describe it as a language that I really don't like, and wish I wasn't forced to learn and had been written differently, mainly with closing statements instead of indentation, and a little more intuitiveness | | Back to Top | | |
 |  Phil Pilgrim (PhiPi) Registered Member

       Date Joined Feb 2006 Total Posts : 6000 | Posted 11/1/2009 8:35 PM (GMT -8) |   | I have to agree that headers == bad; no headers == high productivity and rapid prototyping. If File->New included user-defined options for inserting the clock constants, I'd be happier still. (Jeff, are you reading this? )
-Phil | | Back to Top | | |
 |  potatohead 640 Pixels... :)

       Date Joined Sep 2006 Total Posts : 1340 | Posted 11/1/2009 8:43 PM (GMT -8) |   | | | |
 |  RossH Registered Member

       Date Joined Jun 2008 Total Posts : 411 | Posted 11/1/2009 9:45 PM (GMT -8) |   | Wow, I love these debates
Just to throw my 0000_0010 cents worth in - a byte was not always 8 bits. IIRC the original definition of a byte was the smallest addressible unit of storage - now almost universally 8 bits, but this standard only really developed since the advent of microprocessors. In the days of mainframes there were 6,7,8,9 and 10 & 12 bit bytes on various machines - for example, I worked on a CDC machine with 60 bit words, which consisted of 10 x 6 bit bytes. 8 bits is more correctly known as an "octet", but this term doesn't get used much outside the world of comms protocols these days.
As for SPIN as a language - like any language it does some things very well and other things badly. My biggest gripe at the moment is not with the language per se - it is that it has very few facilities to help you once your program gets beyond a couple of pages. That's the whole point about header files (in C) or package definitions vs package bodies (in Ada), or function prototypes (in various other languages). These are all mechanisms to help you cope once your code is not only too complex to fit on a screen, but perhaps also too complex to fit in any one person's head.
As for the "=>" vs ">=" debate, I always say "greater than or equal to" so that's how I expect to see it. The "=>" is standard mathematical notation for implication (a boolean operation).
Ross. Catalina - a FREE C compiler for the Propeller - see Catalina | | Back to Top | | |
 |  Mike Green Registered Member

       Date Joined Oct 2004 Total Posts : 13558 | Posted 11/1/2009 10:00 PM (GMT -8) |   | | At one time or another I've used most of the programming languages around from Fortran, Cobol, Algol, APL, and Pascal to C, C++, Python, Smalltalk, and lots of others. Spin is just another one with some things borrowed from other languages and some things unique to it. It matches the hardware well and, as RossH said, it does some things very well and other things badly. On balance, it's effective and easy to use. I would not want to use it for an example of object oriented languages. Smalltalk would be much better for that, but Spin makes mostly effective use of encapsulation which is one major feature of OOPL. | | Back to Top | | |
       |  Nick Mueller Registered Member
        Date Joined Apr 2007 Total Posts : 697 | Posted 11/2/2009 6:24 AM (GMT -8) |   | > Bah, header files, I hate header files. That's exactly the kind of cruft that a newbie programmer should not have to be confronted > with. They just want to be able write some simple lines of code that tackle the task at hand without being distracted by that > unnecessary baggage.
Well, then go along without them and you're happy. You can use (sorry) C without header files. But they are very handy for briefly describing what's going on in that library. Also, they do help in the design-process. Start thinking about what that lib should do and look like to the user. Write the header until you are happy. Ctrl-a & Ctrl-v to copy that to your implementation file and start filling in the code, and adding private functions and vars.
> Strictness is a crutch.
Strictness is a means for better design. Lack of strictness is an invitation for spaghetti-code and hacks. People should learn to start thinking in data-flow and stepwise refinement. I always like to make the parameters to a function as strict as possible (by defining types, enums etc.). How I hated the BASIC on my first computer (Apple ][) and how happy I was when I got the language-card together with Pascal. That was the best present from my parents (beside the Apple). And I'm still thankful after 30 years.
> A brilliant programmer made some mistakes which he would So it's just a mistake, but not bad design? Well, I really can't understand what you want to explain me here. If he didn't think well enough about the environment his code will run on and he only had his "brilliant" design in his head ... it was bad design!
Nick Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO | | Back to Top | | |
  |  potatohead 640 Pixels... :)

       Date Joined Sep 2006 Total Posts : 1340 | Posted 11/2/2009 8:31 AM (GMT -8) |   | This dilemma is what all those quick reference books are for!
And that says something kind of ugly about how it all ended up going.
I can strongly identify with purists where language is not dependent on tools. Agreed, and without this being true, open computing is at risk. The core of me is all about open and that's really for computing freedom kinds of things. We've all had a few bad experiences involving tool changes, DRM, trusted computing, etc...
So here's the twist on that regarding Propeller.
I simply trust Parallax, where I wouldn't trust many others. The holistic design of the propeller, it's tools, languages and such is really attractive. It's not like there are competing models or anything. Using the set as given then makes a whole lot of sense and is productive. Part of the fear I have surrounding this ends up being an artifact of so many companies using investments like that to "extract revenue from the customer / user". God that pisses me off, and is what originally started me down the road to understanding and using open code and open data.
At this particular time in my life, I know I've got the skills I need to make use of open computing tools. Most of us here, could dumpster dive, pull out some goodies, and have a proper environment up and running for the cost of internet access and some sweat. Damn cool stuff.
With the Propeller, it's known the longer term outlook is not to abuse peoples investments, and I simply believe that where I just wouldn't otherwise. So then, I'm quite happy to run the Prop, Prop tool on my XP laptop that I carry for professional reasons, and life is just good. If something bad happens, the necessary bits have been documented, and open alternatives are there and working, in some cases, in ways superior to the Parallax tool set. This is a good thing, but not a mandatory thing.
What it means to me is that my trust is warranted and insured. (thanks to those who went the distance to get this done, BTW)
Newbies are interested in doing stuff. The default, reference set of tools gets that done with a potency not seen elsewhere. I believe this is an artifact of the holistic design, and even though that does build in a dependency, the rewards in terms of just making the stuff go, are well worth that violation of principle, particularly given how Parallax appears to operate.
The end result is I'll easily make that investment, feeling secure in being able to use it in the longer term.
I like the Prop tool a lot. To me, it's extremely easy, and it adds a lot of value to SPIN in how it works to present the language to me. And the overhead is just low all across the board. To an experienced hand, it's different, which brings the hysterisis of skill transfer, but to most others, it's a net gain, not worth bending to satisfy those who feel the overhead in this way. The reason is there is no real barrier to alternative tools, and seeing those spawn, grow and see use, really validates all of that. 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! | | Back to Top | | |
  |  potatohead 640 Pixels... :)

       Date Joined Sep 2006 Total Posts : 1340 | Posted 11/2/2009 9:32 AM (GMT -8) |   | | | |
  |  SamMishal Registered Member

       Date Joined Jan 2006 Total Posts : 330 | Posted 11/2/2009 1:02 PM (GMT -8) |   |
Nick Mueller said... You can use (sorry) C without header files.
Not true............unless you have a program void of any function. To do ANYTHING in C you need header files.
Nick Mueller said... How I hated the BASIC on my first computer (Apple ][) and how happy I was when I got the language-card together with Pascal. That was the best present from my parents (beside the Apple). And I'm still thankful after 30 years.
I used the Apple II (with BASIC) to write simulation models for river flow to assist in the design and planning of a DAM. I used it to write programs that did soil stability analysis. I used it to write programs to do three dimensional frame bending moments, shear stresses and deflection analysis. I used the very same BASIC to write programs to solve the differential equations for finite element analysis. I wrote BASIC programs to log and carry out all the calculations for Surveying data of an entire town.
I used the very same BASIC to write Graphical Games (ok not great ones). I used the very same BASIC to write my own Word Processor and DataBase manager (they did not exist at the time as commercial programs).
The amount of PRODUCTIVITY and fun I had with the Apple II and its BASIC is beyond enumeration. The partners of the Consulting Company I was working for at the time were amazed at what this young engineer bringing along to his cubical his own personal computer (the IBM PC was not yet invented) to do what other engineers were waiting for days to do on the company's mainframe (due to job queuing). I later used the same Apple+BASIC to write numerous programs to assist me in doing the analysis and calculations for my Masters thesis (they were ALL in BASIC). I of course also used the University's mainframe with Fortran to do the final reports. But the freedom I had using the Apple II at home instead of having to be tied up always waiting for my turn to use the Mainframe was just so LIBERATING.
So while some people were debating the impurity of BASIC and how it does not help develop good programming practices, I was actually PRODUCING not just practicing USEFUL and RELEVANT programs that RESOLVED and MET a NEED. I did not care if it was better to use Cobol, or Fortran or PL/I.
I had a tool and I used it. It achieved the job and met the required parameters....I did not care what the puritans were saying. While they were DEBATING I was DOING.
Nick Mueller said... Strictness is a means for better design. Lack of strictness is an invitation for spaghetti-code and hacks. People should learn to start thinking in data-flow and stepwise refinement. I always like to make the parameters to a function as strict as possible (by defining types, enums etc.).
Psychiatrist: "Tell me why are you afraid to step out of your house"
Patient : "There are too many roads. Ones leading to the right, ones leading to the left and ones going straight on....I just cannot
decide which road to take....I am just too afraid if I take the one to the left it would take me in the wrong direction."
Psychiatrist: "But you know where you want to go. Just pick the road that goes in that direction. Ignore the others."
Patient : "I cannot doctor. There are just too many choices. I wish they would just come and block off all the roads but one. That way I can just
take that one and I would not have to decide."
Psychiatrist: "But what if they block off the road that you need and only leave you the road that goes in the wrong direction."
Patient : "I do not care. I want someone to decide for me. I cannot do it myself. It is safer if someone makes the decisions for me."
Psychiatrist: "Ok I will make a decision for you. How about we cart you off to the LOONY BIN and shut you up in a room for the rest of your life
you pitiful CRAZY FOOL".
Post Edited (SamMishal) : 11/2/2009 9:12:11 PM GMT | | Back to Top | | |
 |  RossH Registered Member

       Date Joined Jun 2008 Total Posts : 411 | Posted 11/2/2009 2:23 PM (GMT -8) |   | SamMishal said... ............unless you have a program void of any function. To do ANYTHING in C you need header files. Not true. You can have perfectly valid C functions (or in fact entire C programs) without any header files at all. I think you probably mean "library" functions - and this was one of the points I made in an earlier post in this thread. Whether you love them or hate them (and I agree they are very easily abused), C header files (and libraries as well) are the way C supports encapsulation and information hiding. SPIN has no equivalent. This means that there is a certain level of complexity that is more easily supported in C than in SPIN.
Put simply, C supports "programming in the large" (albeit not very well) whereas SPIN is intended for "programming in the small" (see here ). This is not intended as a criticism of SPIN - it is a reflection of the fact that SPIN was originally intended as a language for microcontrollers, but is now being considered in a much wider context (just as the Propeller itself is being used in ways the original designers didn't anticipate). What is entirely appropriate for a language whose programs can never exceed a few dozen pages, which are usually written by one programmer over a few days or weeks is not appropriate for a language whose programs routinely consist of tens of thousands of pages, are usually written over many years, and usually by many programmers.
Of course, many languages are better at this stuff than C - but very few would be worse at it than SPIN. Funnily enough, BASIC is one of the ones most people would probably list (I mean the original BASIC, not the various "tarted up" versions). Like you, I have fond memories of BASIC and the freedom and power it brought to microcomputers. But I don't use it to write large or complex applications - BASIC suffers from many of the same limitations as SPIN (and for much the same reasons).
Ross. Catalina - a FREE C compiler for the Propeller - see CatalinaPost Edited (RossH) : 11/2/2009 11:41:52 PM GMT | | Back to Top | | |
 |  photomankc Registered Member
        Date Joined Jul 2009 Total Posts : 216 | Posted 11/2/2009 3:40 PM (GMT -8) |   | Well, I won't get too wrapped in to this discussion except to say that my prior experience in programming has been with Java, C++, and various flavors of basic on PCs. When I tried my first project with an MCU (68HC11) probably 11 years ago, I was lost in the amount of working hardware to get going before you could even know if one #$%$# byte of code was executing. I made various attempts at it but my OOP/IDE background just didn't jibe with the rather primitive tools that I had access to for it. ASM was and still is something that I have great difficulty even starting off with so I gave it up without ever seeing so much as a blinking light. Never again looked at MCUs until a few months ago.
I stepped into the Propeller with almost no difficulty. I find the SPIN language easy as sin to use and with enough 'object' to it to be useful and no more. It has definite limits in that perspective but it allows me to keep a modular approach to code which I just can't get into BASIC for lack of. The Propeller is simple to get started with in both hardware and software and there is a lot to be said for that. I am simply amazed at what the combination has allowed me to get done in a few weeks when 11 years back I was ready to stomp puppies trying to get an LED to blink. I really think the chip and language work very well together. I do want to explore what, if any, extra performance can be seen with C on it but for now I get a lot done with SPIN. PASM is on my list of things to get to know as well.
I can't really relate it to other languages I have used. I mean there are some reminders of C/C++ in there but enough is different to make calling it similar a stretch. I never used forth, python, or smalltalk or pascal so I have no way to compare it. | | Back to Top | | |
   |  RossH Registered Member

       Date Joined Jun 2008 Total Posts : 411 | Posted 11/2/2009 5:01 PM (GMT -8) |   | | | |
 | 110 posts in this thread. Viewing Page : 1 2 3 4 5 | | Forum Information | Currently it is Saturday, November 21, 2009 11:24 AM (GMT -8) There are a total of 393,852 posts in 55,536 threads. In the last 3 days there were 84 new threads and 703 reply posts. View Active Threads
| | Who's Online | This forum has 17692 registered members. Please welcome our newest member, old guy. 49 Guest(s), 18 Registered Member(s) are currently online. Details heater, MichelB, Peter Jakacki, keith_kw, Jay Kickliter, Mike Green, Alsowolfman, Shawn Lowe, Luis Digital, dMajo, Harley, Harprit, Rick Brooks, Beau Schwabe (Parallax), SRLM, Tubular, ERM, Toby Seckshund |
Forum powered by dotNetBB v2.42EC SP2.02 dotNetBB © 2000-2009 |
|
|