.... I don't like that the operators break from common practice either but I think it's probably better to leave them as they are for P2.
Then we are actually in agreement.
Notice I have never said to remove the old operators entirely, just add a mode switch/pragma that allows user choice between 'legacy' and 'sensible' syntax forms. Other tool chains already do this.
I really don't like mode switching. It means that, even if you know Spin, you might not be able to read someone's code who uses a different mode. We just have to live with the existing Spin operators.
Spin is likely to exist quite a while before P2 gets a C/C++ compiler, and quite a long while before that compiler gets to the maturity level that PropGcc is now. (I'd love to be wrong here, btw).
P1 has failed to get a foothold as a "serious" chip, at least in part because of Spin being a proprietary language, and until relatively late in its existence, the only decent/stable/supported choice. Their loss, sure, but also Parallax's.
Will I live with it? Sure. Will I recommend it to others? Of course. Will they use it? That's the important one. If the level of friction is too high, no. They won't. P2 already has numerous advantages over P1, like speed, hardware debugging, more RAM, more cores, and more everything else, so it seems a shame to saddle it with the same baggage.
Here is another option. Rather than putting all of the effort into Spin, Parallax could support an effort to get C running on P2. If having C on the P2 is going to be a big factor in its success, why do it after Spin? It makes no sense.
Another +++ from me. It's not that it prevents me from using or liking Spin (and I will continue to use Spin although I am proficient in C). But it's annoying, and creates errors, and makes reading code slower. In addition to those languages listed as examples of using 'standardized' operator syntax, Perl also falls into that group. Using different operators from what has been common practice the last couple of decades is like introducing different mathematics symbols. It doesn't prevent anyone from using it, but it sure doesn't make it easier.
Instead of changing the operators and/or putting compiler switches, the compiler could just generate warnings whenever the ">=", "<=", and some of the other confusing operators are used. There could be a compiler option that would turn off the warnings for people that actually want to use those operators.
Have to agree with Jason, Roy, and Tor. Better to use the "standardized" operators. It may be a nuisance for those of us who are comfortable with the current ones but it will make it easier for newcomers from other languages.
I'm not happy with the idea of any kind of "mode" switch that changes the language syntax and semantics. That is just another unnecessary twist in complexity for the user.
Warnings for use of old style operators might work.
Instead of changing the operators and/or putting compiler switches, the compiler could just generate warnings whenever the ">=", "<=", and some of the other confusing operators are used. There could be a compiler option that would turn off the warnings for people that actually want to use those operators.
Warnings sound like a good idea especially if you can turn them off for experienced Spin programmers. I notice Chip hasn't weighed in on this. I assume he had some reason for choosing the operators he did for P1.
I think that all the "mode switch" stuff could be done using plugins for the IDE. I like giving the freedom to the programmer but for the docs only one format will be chosen. For sure, we need to have the possibility to do it to satisfy the most people as possible.
Assuming the compilers have a #define function you could go for clarity by "#define GREQ =>" without resorting to compiler flags that alter the meaning of the source code. Once someone pointed out that the Spin1 operators ending with '=' meant assignment, it all made sense. Yes it's different from every other language I use, but it is self-consistent, which I value.
I'm not happy with the idea of any kind of "mode" switch that changes the language syntax and semantics. That is just another unnecessary twist in complexity for the user.
Warnings for use of old style operators might work.
A mode switch simply lets you do this properly.
Conversely, not having a mode switch, risks a half baked patch, because you cannot collide with existing conventions.
Warnings imply you have somehow added alternatives, but in order to support them, older code now has to generate warnings where it did not before.
Starting to see the benefits of a mode switch yet ?
Mode switch allow legacy and new support, without falling between two stools.
Have to agree with Jason, Roy, and Tor. Better to use the "standardized" operators. It may be a nuisance for those of us who are comfortable with the current ones but it will make it easier for newcomers from other languages.
Yup, & it also makes it easier to maintain code.
The majority of professional programmers, code in more than one language.
Warnings imply you have somehow added alternatives, but in order to support them, older code now has to generate warnings where it did not before.
That is good. Often times I meet warnings about deprecated features in software. Old code generates warnings where it did not before. Makes it dead easy to go in there and up date it. Job done.
Starting to see the benefits of a mode switch yet ?
No.
Not only that I see the suggestion above to handle this with some kind of IDE plugin. Yet another twist in complexity we don't need. Never mind the fact that it now becomes an IDE thing. What if I don't use an IDE?
I'm all for programmer freedom. But one of the great things about the Propeller is to be able to grab objects from OBEX or wherever, drop them into a project and know they will work. That requires that we all work on the same playing field. Mode switches and such will bugger that up.
A mode switch is like a pragma in the source, ( like Radix settings) you can mix then any way you like, and the code compiles just fine.
It really is no different than allowing a mix of number bases.
(eg 0xff, 0FFH, $ff, 2#1111_1111, 1111_1111b, 255 etc)
They may all look different, at first glance, but do exactly the same thing.
I'm all for programmer freedom. But one of the great things about the Propeller is to be able to grab objects from OBEX or wherever, drop them into a project and know they will work. That requires that we all work on the same playing field. Mode switches and such will bugger that up.
If supporting both, at least an in-code pragma would work with or without an IDE. That said, it's still Smile - having a language that changes on the fly is going to be more confusing, not less. At least if you pick one and stick to it it's consistent. I'll take consistently horrible over mighty-morphin' power code.
In all seriousness, the last company I worked for had its own in-house compiler, and many of the conveniences provided were fantastic, until they didn't work for some esoteric reason, and then they were complete hell. It was opaque, dependent on context, and so on. What if that pragma isn't currently in view? Do I need to check the top of every file to figure out what "x>-5" does? What if that pragma appears partway through the file? Do you use the default before the pragma, and that new behavior after? Please no.
...the reason this discussion is occurring at all, is the language clearly failed that "supposed to be simple" litmus test a long time ago.
In that case what is the point of Spin at all? We have all that complexity in C already.
Again, the sweeping statement misses the detail importance.
The problem in Spin is the Operators, not so much the language.
History has simply left them behind, hence the flood of comments on how they conflict with other standards, and the new thread on how to fix that. That's great, a fix is needed.
Languages that are designed to be easily maintained, have solved this already, I'm quite happy to piggyback on that experience. (see examples in other thread)
In that case what is the point of Spin at all? We have all that complexity in C already.
I wasn't aware of an existing P2 C compiler.
Spin is (and always has been) the "chosen" language of the Propeller. It's the language that is being developed first, and by Parallax itself. C/C++ will very probably take a good chunk of time to materialize. I suggested changing the operators to be more in-line with pre-existing standards to make it more likely that non-Prop people would use it. That was it. Wasn't trying to start a language war. Heaven knows we have enough of those around here already.
One example is FreePascal, which recently added these
SAR, SAL, ROL, ROR, BSF, BSR - yes, very assembler like, great for embedded controllers.
Another example is IEC 61131 PLC language,
which has SHR, SHL, ROL, ROR, MAX, MIN as functions.
They could have chosen obtuse, cryptic char pairings, but no, instead they selected clear function names.
When Assembler is easier to read than HLL, there is something fundamentally wrong with that HLL.
ergo, it needs "to evolve in a backward compatible manner"
Python has had a bit of a major hiccup trying to move from version 2 to version 3. But still the guts of it is the same.
IIRC Python moved some inbuilt functions, to a more correct function syntax.
The benefit of this approach, is it allows the tools to remove more easily unused functions, and thus save code size.
When Assembler is easier to read than HLL, there is something fundamentally wrong with that HLL.
Funny you should say that.
Back in the 1970's we learned BASIC and assembler in tech school. I soon realized that there were things I wanted to do that were very hard in BASIC and much easier to express in assembler.
A billion years later I find that PASM on the P1 is about the most brilliantly regular and simple assembly language I have ever seen.
Certainly some PASM I have written is at least as easy to understand as the Spin equivalent.
When Assembler is easier to read than HLL, there is something fundamentally wrong with that HLL.
Funny you should say that.
Back in the 1970's we learned BASIC and assembler in tech school. I soon realized that there were things I wanted to do that were very hard in BASIC and much easier to express in assembler.
A billion years later I find that PASM on the P1 is about the most brilliantly regular and simple assembly language I have ever seen.
Certainly some PASM I have written is at least as easy to understand as the Spin equivalent.
I'm not happy with the idea of any kind of "mode" switch that changes the language syntax and semantics. That is just another unnecessary twist in complexity for the user.
Warnings for use of old style operators might work.
A mode switch simply lets you do this properly.
Conversely, not having a mode switch, risks a half baked patch, because you cannot collide with existing conventions.
Warnings imply you have somehow added alternatives, but in order to support them, older code now has to generate warnings where it did not before.
Starting to see the benefits of a mode switch yet ?
Mode switch allow legacy and new support, without falling between two stools.
Have to agree with Jason, Roy, and Tor. Better to use the "standardized" operators. It may be a nuisance for those of us who are comfortable with the current ones but it will make it easier for newcomers from other languages.
Yup, & it also makes it easier to maintain code.
The majority of professional programmers, code in more than one language.
I really don't think a mode switch or aliases are a good idea. Both make it harder for someone to read someone else's code. Just pick a set of operators and stick with them. It may be a bit painful for some at the start but people will quickly get used to the new set and life will be better for everyone after that.
...the reason this discussion is occurring at all, is the language clearly failed that "supposed to be simple" litmus test a long time ago.
In that case what is the point of Spin at all? We have all that complexity in C already.
Again, the sweeping statement misses the detail importance.
The problem in Spin is the Operators, not so much the language.
History has simply left them behind, hence the flood of comments on how they conflict with other standards, and the new thread on how to fix that. That's great, a fix is needed.
Languages that are designed to be easily maintained, have solved this already, I'm quite happy to piggyback on that experience. (see examples in other thread)
The operators are not the only problem with Spin. I'd say they are a rather minor part. The main problem is that it is a totally unfamiliar language for nearly everyone who might consider the Propeller.
[C/C++ will very probably take a good chunk of time to materialize.
The main reason this might be true is that Parallax doesn't have the resources to do both Spin and C and they've chosen to do Spin first. Also, there is not an existing Spin2 compiler either. The resources could be put toward C instead and it would be available sooner.
I agree with leaving the operators the same as in Spin1. Just make the compiler a little smarter and add warnings when odd statements are encountered, such as " if a >= b". I always have to switch gears mentally when switching back and forth between Spin and C. Sometimes I type C-like syntax into my Spin source, and other times I will enter Spin-like syntax into my C code. The compilers let me know when I make those mistakes.
The operators are not the only problem with Spin. I'd say they are a rather minor part. The main problem is that it is a totally unfamiliar language for nearly everyone who might consider the Propeller.
Perhaps, but the operators are what serves to make it "a totally unfamiliar language".
eg Spin has keywords like
IF
IFNOT
CASE
REPEAT
NEXT
QUIT
RETURN
and anyone can reasonably guess what any of those are, and improve that guess if seeing them in context.
That is not true with the operators, which mandate a look-at-the-manual, ( whilst mumbling WTF?)
Comments
Well, maybe everyone will be somewhat happier.
This:
Seems a fine idea.
I'm not happy with the idea of any kind of "mode" switch that changes the language syntax and semantics. That is just another unnecessary twist in complexity for the user.
Warnings for use of old style operators might work.
Jonathan
A mode switch simply lets you do this properly.
Conversely, not having a mode switch, risks a half baked patch, because you cannot collide with existing conventions.
Warnings imply you have somehow added alternatives, but in order to support them, older code now has to generate warnings where it did not before.
Starting to see the benefits of a mode switch yet ?
Mode switch allow legacy and new support, without falling between two stools.
Yup, & it also makes it easier to maintain code.
The majority of professional programmers, code in more than one language.
Not only that I see the suggestion above to handle this with some kind of IDE plugin. Yet another twist in complexity we don't need. Never mind the fact that it now becomes an IDE thing. What if I don't use an IDE?
I'm all for programmer freedom. But one of the great things about the Propeller is to be able to grab objects from OBEX or wherever, drop them into a project and know they will work. That requires that we all work on the same playing field. Mode switches and such will bugger that up.
Simply wrong. There is no "will bugger that up."
A mode switch is like a pragma in the source, ( like Radix settings) you can mix then any way you like, and the code compiles just fine.
It really is no different than allowing a mix of number bases.
(eg 0xff, 0FFH, $ff, 2#1111_1111, 1111_1111b, 255 etc)
They may all look different, at first glance, but do exactly the same thing.
If supporting both, at least an in-code pragma would work with or without an IDE. That said, it's still Smile - having a language that changes on the fly is going to be more confusing, not less. At least if you pick one and stick to it it's consistent. I'll take consistently horrible over mighty-morphin' power code.
In all seriousness, the last company I worked for had its own in-house compiler, and many of the conveniences provided were fantastic, until they didn't work for some esoteric reason, and then they were complete hell. It was opaque, dependent on context, and so on. What if that pragma isn't currently in view? Do I need to check the top of every file to figure out what "x>-5" does? What if that pragma appears partway through the file? Do you use the default before the pragma, and that new behavior after? Please no.
Sorry. I know that IDE thing was not your suggestion. I was just riffing on my theme there.
OK, pragma in the source gets rid the mode switch problem by localizing the issue to a source file.
Of course I have my objections to that as well...
Introducing any kind of "pragma" adds syntactic and semantic complexity we don't need in a language that is supposed to be simple.
hehe, the reason this discussion is occurring at all, is the language clearly failed that "supposed to be simple" litmus test a long time ago.
Again, the sweeping statement misses the detail importance.
The problem in Spin is the Operators, not so much the language.
History has simply left them behind, hence the flood of comments on how they conflict with other standards, and the new thread on how to fix that. That's great, a fix is needed.
Languages that are designed to be easily maintained, have solved this already, I'm quite happy to piggyback on that experience. (see examples in other thread)
I wasn't aware of an existing P2 C compiler.
Spin is (and always has been) the "chosen" language of the Propeller. It's the language that is being developed first, and by Parallax itself. C/C++ will very probably take a good chunk of time to materialize. I suggested changing the operators to be more in-line with pre-existing standards to make it more likely that non-Prop people would use it. That was it. Wasn't trying to start a language war. Heaven knows we have enough of those around here already.
The languages with which I am familiar have not had their basic syntax or semantics changed since they started. Think, C, C++, Java, Javascript.
Python has had a bit of a major hiccup trying to move from version 2 to version 3. But still the guts of it is the same.
They tend to evolve in a backward compatible manner.
"to evolve in a backward compatible manner"
One example is FreePascal, which recently added these
SAR, SAL, ROL, ROR, BSF, BSR - yes, very assembler like, great for embedded controllers.
Another example is IEC 61131 PLC language,
which has SHR, SHL, ROL, ROR, MAX, MIN as functions.
They could have chosen obtuse, cryptic char pairings, but no, instead they selected clear function names.
When Assembler is easier to read than HLL, there is something fundamentally wrong with that HLL.
ergo, it needs "to evolve in a backward compatible manner"
IIRC Python moved some inbuilt functions, to a more correct function syntax.
The benefit of this approach, is it allows the tools to remove more easily unused functions, and thus save code size.
Of course that is a bit different as it is introducing new operations to Pascal rather than replacing old operators as we need to do for Spin.
I think the Python guys are right in moving inbuilt syntax like "print" into functions. It seems trivial but: is very different to That latter is just a function call. The former is welded into the language syntax.
The problems with Python 3 go far deeper than that of course.
Back in the 1970's we learned BASIC and assembler in tech school. I soon realized that there were things I wanted to do that were very hard in BASIC and much easier to express in assembler.
A billion years later I find that PASM on the P1 is about the most brilliantly regular and simple assembly language I have ever seen.
Certainly some PASM I have written is at least as easy to understand as the Spin equivalent.
Remember this though, they were created by one person, Chip. And that was over 10 years ago.
Languages have evolved since then too. Things that were not important to micros 10 years ago are common now. Standards have evolved too.
It is now just an opportune time to fix some gotchas, and conform more to other standards.
eg Spin has keywords like
IF
IFNOT
CASE
REPEAT
NEXT
QUIT
RETURN
and anyone can reasonably guess what any of those are, and improve that guess if seeing them in context.
That is not true with the operators, which mandate a look-at-the-manual, ( whilst mumbling WTF?)