java and spin

Manuel · 2006-08-16 00:05

hello, could any one that has programmed java and is now trying spin tell me how similar they are?
THX

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Best Regards

Manuel C. Reinhard

Rich M · 2006-08-16 01:59

Java and Spin? They're about as far apart as possible.

Java is a thoroughly object-oriented language. Spin has "objects", but they really don't much in common with the term "object" as used in conventional OO languages.

Spin program flow depends on ( Eeeeeeeeeek! ) indentation. I.E., it will make FORTRAN programmers feel right at home.

I'm still trying to figure out, why, in this day and age, anyone would design a language based on indentation.... but let's not go there. My mind is still reeling. The editor helps in this regard - it has a mode that will draw connecting bars between the appropriate loops, etc - but it's still utterly bizarre that this is a feature that's even needed.

Spin is relatively terse, compared to Java. It uses some operators that will really, really trip you up if you have any experience with other high-level languages. For example, if you're accustomed to C/C++/Java, etc - heck, any major language used in the last 40 years, some of the operators will NOT do what you expect. Take Spin's interpretation of >= for example. Look VERY closely at the manual. Because, I guarantee that it does not do what you think it does. And you will probably spend lots of time figuring out why your very simple little programs that use very common programming idioms... don't work like you expect.

I think that the designers of Spin tried to find some balance point between having a somewhat C-like, terse language, so you can work closer to the metal, and a higher level one that allows a certain amount of abstraction. That balance point, I think, has more or less been met, but they've made some really odd choices, especially for people who fluent in other programming languages. They often totally miss the boat when it comes to using the "principle of least surprise." It's almost like whoever designed the language didn't think about what works and doesn't work, in other languages - they just pretty much went off and did their own thing - working from the point of view that it was more important to write an easy compiler, than to design a language where the compiler did more work, and took the burden off of the programmer.

Graham Stabler · 2006-08-16 09:35

I like the indentation, I do it anyway when writing C code for readability and is saves me a { and a }

Not sure about := [noparse]:)[/noparse]

To cut a long story short, it will take you about 5 minutes to pick up the basics and a while to read chapter 4 so you know the command set.

Graham

Rich M · 2006-08-16 12:00

There's a difference between using indentation for readability - as you should do in any block-oriented language - and using it as an actual syntactic element. Using it as syntax has historically been deprecated, because of the subtle bugs that it introduces.

Saving the use of { and } characters is a non-argument. Typically, you will spend far more time designing and debugging the program than you will actually typing out a few extra bits of punctuation.

Don't get me wrong - I really like the prop chip, and Spin beats most assembly languages by a long shot. But there are elements of it that honestly look like someone's Freshman-level "Intro To Compiler Design" project.

Introduction of too many "clever", syntactically terse constructs as standard idioms usually indicates that the compiler does not have a terribly good optimizer. For example, it would be interesting to compare if constructions like "var~~" produces equivalent bytecodes to "var := 1", etc, or if it compiles if/then/else blocks down to the equivalent of a "#>=" term.

simonl · 2006-08-16 12:23

To answer the original post; there's very little similarity - period.

As for the syntax; well, as a person who's only ever programmed in BASIC (various incarnations, including Proton+ for PIC) I'm being tripped-up all over the place. Some of that is down to laziness - rarely having had to declare variables and constants - and others are down to the horrible >= difference. Even the := gets me :-(

That said, I don't mind the indentation. Like Graham, I always indent for clarity; but I'd rather it weren't a requirement - I rather like the clarity of 'while...wend', 'for...next', and 'if...endif'!

But i do LOVE the Propeller - oh yes

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon

Graham Stabler · 2006-08-16 12:48

My no { and } was really a touch of sarcasm.

Wend, next and endif as well as curly brackets are great for the compiler but not so good for SEEING the structure of the program. Indentation allows that even when used solely for formatting. The problem with using it to mark blocks of code is the possibility of things not being in the block of code you think they are because you have pressed space or tab a few more times. BUT the IDE has a lovely way of marking the indentation and hence the structure and I think it should be turned on always. You end up with clear structure that is non ambigous.

So far I have not had any errors concerning indentation, the compiler has told me off or using = instead of := and I haven't had call to use <=

I agree about some of the short hand, I'm not against it as such but it made understanding the demos a pain when I first started.

Graham

Kaos Kidd · 2006-08-16 13:42

JMO...
The indentation and extra white space give a 'view' to the program that makes things easier to see. While I'm somewhat inclined to agree that it's a syntatical (is that a word?) requirement is more of a throw back, it still beats line numbers and lables. The advancements of the language, by far, out weigh the syntax requirements. What has beaten me is the longhand vs shorthand and 'complimented operators' (ie <= , =< and #< , ># ). Maybe, after the IDE is caught up with the chip and manual, they could work on 'hot tips' that would point out such mistakes.
All in all, I love the language: Short & Sweet, percise (if somewhat hard to read at times).
^5's to the IDE programming team!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd

·

Phil Pilgrim (PhiPi) · 2006-08-16 15:23

I came to Spin programming from a Perl background, replete with braces {} and other syntactic clutter. When I saw that Spin, with its required indentation, looked like Python, I was taken aback: whitespace as syntax?!! But I've grown to like it a lot. It's terse, it's clean, and it requires less vertical space on the screen. That last item is important for debugging, too, since your eye can encompass more of the program without scrolling. Now, whenever I have to program in Perl, I find its syntax painful.

-Phil

acantostega · 2006-08-18 00:50

Heh, I've been wondering about the origins of the Spin language for a while now. The := reminds me of Pascal, the operators are like C bit-twiddling operators on steroids ("===" is just great ... Ruby has this one, although it means something totally different).

Now with regards to the significance of whitespace / indentation, I really like it. I've programmed in Python for a while now, and there it felt natural since the beginning. I mean, I always indent anyway (or rather, have Vim do it for me), and I find it's important in visually grasping the code. Take Lisp, for example -- even though the parentheses are all that matter there are so many of them I lose track. Proper indenting really help in making the code more intelligible. And finally, those curly brackets are pretty hard to get to in these $%& spanish keyboards (I'm from Chile), so I welcome having to type less of them.

hammerhead74000 · 2006-08-18 07:06

Well, from the perspective of somebody who's actually written a compiler - wend, next and endif are, IMO, evil ugly nasty syntactic elements -- three non-equivalent elements to end a block. Blech! Much cleaner to have a single element for block designation - such as the aforementioned braces, or even the begin/end pair from Pascal; as then you can seperate the branch handling code from the block handling code.

I'm also not so hot on indentation-as-syntax... for one thing, it's gonna' require some ugly hackery to handle properly in lex/yacc; for another, it really restricts what you can do with a simple preprocessor; and it also makes building some types of codegens more involved (requiring that you track the current indentation level thru the codegen's recursion stack).

For example... try doing something like this in spin:

#define rewind(p,c) while(p->prev) { p=p->prev; c++; }

... you can't, the indentation gets messed up by the preprocessor.

And as for taking up less space on screen - sometimes yes, sometimes no... from a bit of code that I was just working on:

while(d->prev) { d=d->prev; dataCount++; };

(as it's the only place where this idiom appears in this project, I didn't bother to macro-ize it).

Phil Pilgrim (PhiPi) · 2006-08-18 07:38

hammerhead,

You're right about the single-line stuff. That's where semicolons and braces can come in handy for saving space. They're also handy if you need to extend a statement over more than one line. But, frankly, in all the Spin coding I've done, I've never felt a need to do either. I've found it most useful to empty my head of any preconceived notions drug in from prior coding and compiler-writing experience and just think in Spin. It is what it is, and it fulfills its mission admirably. Sure, there are some things that would be nice to add to the language: infix dereferencing and runtime list/array constructors are two things that come to mind. But I haven't had any wishes that weren't consistent with the overall structure and syntax of the language itself or its interpreter. And I'm content to wait for the next version of Spin which, hopefully, will incorporate some of my wished-for features.

-Phil

Paul Baker · 2006-08-18 16:09

This is a subjective opinion, but the use of indentation is a good thing because is does·not permit complex formating, where someone can adopt thier own personal style of indenting. In just C there are countless indentatation styles and nothing requiring a coder to adhere to any of them. The original coder may like this just fine, but this is a nightmare to another person trying to read and use the code, most especially when they are a novice.

Spin is intended to be the high level language of the propeller, Parallax has always tried to make embedded programming as easy for the beginner as possible. By enforcing an indentation style on everyone, this helps the novice programmer read and learn from other people's code. Syntactical elements which convey no direct action are not required in a language and Parallax has chosen to not include them.

For those of you who have been coding so long that syntactical elements are second nature, take a look at this block of lisp code, and you can see how syntactical elements does not always mean improved readability when the coder doesn't also use proper whitespacing.

(defun swap (list) (if (or (null list) (null (cdr list))) list (cons (second list) (cons (first list) (swap (cddr list))))))

The way this code looks to you is how alot of novices see·C code when profusive white space is not included.

My only complaint is that the dotNetBB engine doesn't preserve whitespace except when a code box is used, and this has nothing to with the Propeller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
...

Post Edited (Paul Baker) : 8/18/2006 4:25:03 PM GMT

Phil Pilgrim (PhiPi) · 2006-08-18 16:40

Paul,

DotNetBB does honor HTML character entities. So you can always insert where you want a forced space to occur, viz:

repeat
··indent := 2

Granted, this gets a little cumbersone for long blocks of text, but for those you'd likely use a [noparse][[/noparse]code] block anyway.

-Phil

Jeff Martin · 2006-08-18 18:39

Hi all,

Spin was designed VERY carefully, over a period of two years or so. Every feature was carefully scruitinized by us and some features were simply left out because the potential pitfalls users could create using them far outweighed their usefullness. We've programmed is most of the popular languages today and created Spin as a mix of some of the best features of C, Java, Python as well as our own ideas of how we wish other languages were.

As far as indention goes: it is an absolute must to indent properly for code readability by other programmers. When we decided that one of our frustrations with other languages was how many lines of code it took to achieve something grand, using indention to indicate blocks of code (rather than BEGIN/END, {, }, etc, etc) was the best solution, it saves LOTS of vertical space allowing you to see more on the screen at once.

The compiler actually does optimize things pretty well, but it's not just the compiler, the Propeller Chip has many features in hardware for this very reason. When we made a syntactical element in Spin that we realized could be used often and really could use an efficient encoding, we went back to the hardware and chagned it to match. Yes, the hardware was revised many, many times after we started programming in Spin ourselves. It was an amazing opportunity to design things from the ground up and to be able to go back and redesign hardware to make the software more powerful or efficient. There are improvements slated for the compiler and software and you will see those arrive over time, but we're very happy with the result of all the effort we've put into it already. It sounds like many of you feel the same way. It will only get better.

As a C, Java and Delphi programmer, I think Spin is very easy to learn.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.

Rich M · 2006-08-18 20:23

I see a couple of issues with your responses.

Most notably, you try to stress that your choice of using indentation as a syntactical element was crucial for readability. I agree wholeheartedly that consistent indentation is one of the most important mechanisms to enhance the visual presentation of the code. The problem is that you've the boxed yourself into quite a corner. The IDE - in particular, your interpretation of how an IDE should operate - starts needing crutches like the graphical elements that match up flow control blocks. Instead of freeing the developer to choose their own best tool, you start limiting them to use your idea of what defines a good tool.

Seeing more on the screen at once is usually a good thing - but syntactical indentation is not the best solution for accomodating that. Folding editors have been with us for at least a decade, and for good reason. Heck, the Spin IDE is essentially a folding editor.

But along with that, if you want to encourage readability, then you encourage decomposition of functions, so you don't need all of that vertical screen real-estate in the first place. In any event, in real-world code, you're going to lose at most, a couple of lines if you use traditional block start and end termination elements in any given screen's worth of code - not really enough to use it as a reason to justify syntactical indentation. And finally, just to give the whole indentation issue a rest - one of the nicest things about traditional start/end termination elements is that it's really, really easy to build a pretty-printer to format the source code in any way you like it, from enforcement of a corporate-standard source format, to the person who likes everything on one line, like some Perl developers I know.

You don't get that same flexibility with a positional language.

But the readability issue comes into play even more so with the language itself. In one paragraph, you tell us how important readability is. But then we look at how you've defined many of the operators. For example, what is more readable?

var~ or var := 0
var~~ or var := 1

The examples in the first column may be something you want to be a common idiom in Spin, and that's fine. But, I can *guarantee* that someone who doesn't develop in Spin a lot, who looks at a piece of source code, will understand what the examples in the second column will do without cracking a manual open. Heck, even an experienced Spin programmer, after a long all-nighter, is far more likely to interpret the := variation correctly.

Now, I believe I know why you have all of those terse ( and consequently, less readable ) idioms, as I've written more than a few little-language compilers myself; They're really, really easy to optimize. And that's a perfectly legitimate reason for employing them. But when the manual, which is obviously targeted at beginners, uses those constructs as the standard idiom, then I think you're missing your intention of espousing readability as one of your prime, driving goals. Heck, look at pp. 118 of the manual, and the "while Count := --Count #> -1" example. Readable on first glance? Absolutely, positively, no way. And that's what, the second or third example in the manual?

But honestly, I think that the thing that Parallax needs to answer the most is: >= Seriously, WHAT were you guys drinking when you came up with your definition of how that operator functions?

I've always, always said to my developers, "Use the principle of least surprise."

Again, as I said before, I do like the prop chip. For a hobbyist, it's amazing. For someone who builds stuff in quantity - can you get the price down to about $3/thousand?

And I even mostly like Spin, as a microcontroller development language. It still beats the heck out of PIC assembly.

But I think you ignored a few too many of the best practices for language development that have evolved over the years, than have demonstrable benefits when it comes to empowering the programmer, rather than the compiler-writer.

- Rich

Mike Green · 2006-08-18 20:47

Rich (and others),
I think both Rich and Jeff have made some good points. SPIN was not developed casually. It has evolved through a lot of iterations based on experience with the hardware over an extended period of time. On the other hand, it does do things in very non-standard ways. The indenting and the operator syntax is very very different from pretty much any programming language in wide use currently. This does make it harder to teach (and use) in a mixed environment where people are working with other systems. I personally find the indenting very workable, but not compact for a lot of uses. As hammerhead suggests, you really can't make a macro pre-processor for SPIN that allows general macro functions. You could do statement substitutions or substitutions of expressions for macro functions only. It's useful, but not as useful or rich as it could be. Given the market and the particular application (the Propeller chip), it will work fine. For teaching purposes, it would be useful to have a desktop/laptop SPIN interpreter without necessarily having a Propeller emulator. Having keyboard, mouse, and vga display objects that talk to the "native" keyboard, mouse, and display would be a good start (although also having some persistent memory is important too).

CJ · 2006-08-18 20:49

var := -1

I like spin! I have found it very easy to use, but I do kinda loose everything I have learned until it is needed, anyway, := no preconceptions whatsoever!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

Post Edited (CJ) : 8/18/2006 8:54:48 PM GMT

cgracey · 2006-08-18 23:44

Rich,
You make some great points, but we can no more stomach doing things your way (or the industry way) than you could stomach doing things our way. Spin is ideal to Jeff and I. It's the language we want to program in, exactly. And it wasn't born of sophomoric inability or negligence. 'Lex' and 'yacc' would have been the easy road to nowhere better. Spin's exactly what we want it to be, eyes wide open. I know that it's sure to offend a few experienced people because it's different. To us, it's pure simplicity and freedom.
I guess at some point we just accepted that we were not going to get to where we wanted to go by clinging to convention. It's been a real charge to find out that this has struck a chord with many others. I believe there is a pent-up frustration out there with 'convention'. It has ceased to inspire people and made many not want to program anymore. Read the threads on this forum. People are charged up, some for the first time in twenty years, to PROGRAM!!!
By the way, the key to understanding the math operators is recognizing that those operators which end in '=' are all assignments. Counter-intuitive at first, but very simple.

Rich M said...
I see a couple of issues with your responses.

Most notably, you try to stress that your choice of using indentation as a syntactical element was crucial for readability. I agree wholeheartedly that consistent indentation is one of the most important mechanisms to enhance the visual presentation of the code. The problem is that you've the boxed yourself into quite a corner. The IDE - in particular, your interpretation of how an IDE should operate - starts needing crutches like the graphical elements that match up flow control blocks. Instead of freeing the developer to choose their own best tool, you start limiting them to use your idea of what defines a good tool.

Seeing more on the screen at once is usually a good thing - but syntactical indentation is not the best solution for accomodating that. Folding editors have been with us for at least a decade, and for good reason. Heck, the Spin IDE is essentially a folding editor. But along with that, if you want to encourage readability, then you encourage decomposition of functions, so you don't need all of that vertical screen real-estate in the first place. In any event, in real-world code, you're going to lose at most, a couple of lines if you use traditional block start and end termination elements in any given screen's worth of code - not really enough to use it as a reason to justify syntactical indentation. And finally, just to give the whole indentation issue a rest - one of the nicest things about traditional start/end termination elements is that it's really, really easy to build a pretty-printer to format the source code in any way you like it, from enforcement of a corporate-standard source format, to the person who likes everything on one line, like some Perl developers I know. You don't get that same flexibility with a positional language.

But the readability issue comes into play even more so with the language itself. In one paragraph, you tell us how important readability is. But then we look at how you've defined many of the operators. For example, what is more readable?

var~ or var := 0
var~~ or var := 1

The examples in the first column may be something you want to be a common idiom in Spin, and that's fine. But, I can *guarantee* that someone who doesn't develop in Spin a lot, who looks at a piece of source code, will understand what the examples in the second column will do without cracking a manual open. Heck, even an experienced Spin programmer, after a long all-nighter, is far more likely to interpret the := variation correctly.

Now, I believe I know why you have all of those terse ( and consequently, less readable ) idioms, as I've written more than a few little-language compilers myself; They're really, really easy to optimize. And that's a perfectly legitimate reason for employing them. But when the manual, which is obviously targeted at beginners, uses those constructs as the standard idiom, then I think you're missing your intention of espousing readability as one of your prime, driving goals. Heck, look at pp. 118 of the manual, and the "while Count := --Count #> -1" example. Readable on first glance? Absolutely, positively, no way. And that's what, the second or third example in the manual?

But honestly, I think that the thing that Parallax needs to answer the most is: >= Seriously, WHAT were you guys drinking when you came up with your definition of how that operator functions? I've always, always said to my developers, "Use the principle of least surprise."

Again, as I said before, I do like the prop chip. For a hobbyist, it's amazing. For someone who builds stuff in quantity - can you get the price down to about $3/thousand? And I even mostly like Spin, as a microcontroller development language. It still beats the heck out of PIC assembly. But I think you ignored a few too many of the best practices for language development that have evolved over the years, than have demonstrable benefits when it comes to empowering the programmer, rather than the compiler-writer.

- Rich

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey (Parallax)) : 8/19/2006 12:25:55 AM GMT

James Long · 2006-08-19 03:31

Rich,
You make some great points, but we can no more stomach doing things your way (or the industry way) than you could stomach doing things our way. Spin is ideal to Jeff and I. It's the language we want to program in, exactly. And it wasn't born of sophomoric inability or negligence. 'Lex' and 'yacc' would have been the easy road to nowhere better. Spin's exactly what we want it to be, eyes wide open. I know that it's sure to offend a few experienced people because it's different. To us, it's pure simplicity and freedom.
I guess at some point we just accepted that we were not going to get to where we wanted to go by clinging to convention. It's been a real charge to find out that this has struck a chord with many others. I believe there is a pent-up frustration out there with 'convention'. It has ceased to inspire people and made many not want to program anymore. Read the threads on this forum. People are charged up, some for the first time in twenty years, to PROGRAM!!!
By the way, the key to understanding the math operators is recognizing that those operators which end in '=' are all assignments. Counter-intuitive at first, but very simple.

Chip,

Every microprocessor maker has their own way of doing things. You just choose to do things differently. I don't think that is bad .....just different. I like people who do things their own way. (If it works.)
·I choose things that provide a positive end result by using. I don't care if the language is "conventional" or not.
If it·is a system that I can purchase for a reasonable price...and I can learn relatively fast...I will use it. If I have to spend two years learning the programming language....it will be looked over for a simpler system.
I don't want to engineer my own microprocessor...so I will use what·I like. I don't own a Propeller...but my project (current one) has been designed around it.
You keep making chips I can program easy....I'll keep buying them.

Just my 2 bits,
James

acantostega · 2006-08-19 05:50

Rich M said...
I see a couple of issues with your responses.
The problem is that you've the boxed yourself into quite a corner. The IDE - in particular, your interpretation of how an IDE should operate - starts needing crutches like the graphical elements that match up flow control blocks. Instead of freeing the developer to choose their own best tool, you start limiting them to use your idea of what defines a good tool.

While I agree with most of your points, I have to say I disagree with this. Up to now I've done most of my Spin coding in Vim, where I also code in Python, and I don't think the elements matching flow control blocks are really necessary. (And no, I don't use the folding). There's tons of people developing in Python and up to now no Python IDE has become very popular, I suspect in part because it just gets in the way. Any text editor works fine.

On the other hand, unless I indent carefully I easily lose track of traditional block ending syntactic elements, specially those damn parentheses in Lisp.

I do miss #define's (or something similar) though, but I hadn't realized it might have anything to do with this (could some C++ish inline be used instead?). Maybe it's just as well though. You could do some obfuscated stuff with the preprocessor.

parsko · 2006-08-19 06:44

Hi guys,

Spin and spinassy are the the 2nd (3rdish)·programming language I have learned in my life.· Started out with Basic in HS about 13 years ago, never used basic again until I started using MBasic on the AtomPro.· I have been learning Spin the past 3-4 months.· I have had NO regrets making the switch to Spin.· I don't even know PBasic (the Stamp software, right?).·

Thus far, my experience has been VERY positive.· I'm not a guy that can sit down and just write code, and if 15minutes have a working object.· I need to think about stuff, make sure I put the right operators in the spot,·etc...· As a result, I have noticed spin to be quite logical and straightforward.· The indenting thing makes NO difference to me, though I would rather have it then not have it.

So, without sounding like a brown-noser, and being a novice to writing code and ucontrollers, I would have to say that Spin has been very easy and logical to learn.· Perhaps my only complaint is the lack of "spoon-fed" examples.· But, as I see it, considering the Prop came out only a few months ago, I can't ask for much more than has been provided.· For a standalone, relatively small company to create something this easy and straightforward, as this is the only business they do, I'm quite impressed.· I personally think you guys are arguing apples and oranges,·since everyone wipes his tush a different way, this simply happens to be the way Chip wants to wipe, and I personally like his technique.· But, I CAN see the frustration in having to learn new languages so frequently, as I've had to learn about 4 different CAD softwares in my life...

-Parsko

postcount =+

java and spin

Comments