SPIN2 doesn't need a seed for random(), as the P2 does not provide a means to seed the PRNG. Recently (I can't remember where), Chip mentioned that each cog gets a random seed on startup and therefore the PRNG for each cog is unique.
Should Spin2 support separate compilation, libraries, and linking?
The only change I would recommend is a way, in the OBJ section, to specify directories for objects. But separating out the compile, linking, and loading phases? Ugh, no. Single compile and compile-and-load buttons (F9, F10, F11) keep things simple.
-Phil
Yes. You should never be more than 1 second away from seeing your code run with a keystroke or click.
This message passing scheme could be built into the very syntax of the language. As it was in Occam and is today with XC from XMOS and the Go language. For example something like:
Receive data from a channel:
x ? somechannel
Send data to a channel:
someChannel ! y
One would pass references to someChannel rather than passing object references around.
This not only allows object reuse in a "tree" of code running in a COG but takes care of the mutual exclusion required when talking between COGS.
This would not suffice for a myriad of uses. For example, in the Elev8 project, I have an object which manages user settings, needed by many different code modules, but it doesn't run a cog - it's just a place to park functions and data that relate to each other. (you know, like what objects are actually for). A message passing system would be useful for things that are actually running independently, but that's not my principal use of objects.
Also, that syntax makes my head hurt, from the person who rails against ternary operators no less. Slightly more verbose, but dramatically more readable:
This doesn't work, because the programmer has to provide a seed that gets modified with each call. And it may be desirable to work with multiple seeds. So how do you specify that with a simple function call?
a := rand(range, @seed)
is a bit wordy but might work. Spin's ? operator is considerably more terse.
-Phil
There's a free-running 32-bit LFSR that each cog gets a differently-scrambled-and-inverted copy of, accessible through the GETRND D instruction. No need for seeds.
Should Spin2 support separate compilation, libraries, and linking?
Yeah, then we can get the slow compilation and link speed of C++ and all the added complication for the user.
That is to say, no.
Well, 512k isn't that big either compared to the giant programs people write for PCs. It could be that we don't need separate compilation. On the other hand, I don't think GCC is particularly slow at building Propeller programs. It *is* slow at building itself though.
JasonDorie,
...the inability to share objects is maddening.
True. But I was wondering...
Rather than pass object references around so that things like FDS can be used from many other objects in a program, what about a message passing system? As long as there is a instance of FDS, for example, running somewhere on can send and receive data trough some message channel/mailbox/queue whatever.
This message passing scheme could be built into the very syntax of the language. As it was in Occam and is today with XC from XMOS and the Go language. For example something like:
Receive data from a channel:
x ? somechannel
Send data to a channel:
someChannel ! y
One would pass references to someChannel rather than passing object references around.
This not only allows object reuse in a "tree" of code running in a COG but takes care of the mutual exclusion required when talking between COGS.
The syntax is totally up for grabs. It would have to fit well with the existing Spin syntax anyway. It's the basic message passing idea I'm putting up for consideration.
? and ! made sense in the context of Occam. Which was a pretty lean and mean language. They were just simple binary operators like + and -. They have some logic in that you are asking, "?", for some data from a channel. You may have to wait for the reply there. Or shouting "!" some data into a channel.
David Betz,
512k isn't that big either compared to the giant programs people write for PCs.
True. But your compiled binary for a PC does not have to be very big before C++ compilation times become annoying.
Chip,
You should never be more than 1 second away from seeing your code run with a keystroke or click.
Should Spin2 support separate compilation, libraries, and linking?
The only change I would recommend is a way, in the OBJ section, to specify directories for objects. But separating out the compile, linking, and loading phases? Ugh, no. Single compile and compile-and-load buttons (F9, F10, F11) keep things simple.
-Phil
Yes. You should never be more than 1 second away from seeing your code run with a keystroke or click.
This would not suffice for a myriad of uses. For example, in the Elev8 project, I have an object which manages user settings, needed by many different code modules, but it doesn't run a cog - it's just a place to park functions and data that relate to each other. (you know, like what objects are actually for). A message passing system would be useful for things that are actually running independently, but that's not my principal use of objects.
Are you saying Elev8 is not using drivers for whatever sensors and actuators?
As far as I can tell it is a common pattern for Prop applications to be built from many concurrently running processes each of which is an objects. What with the 8 cores and all that.
Admittedly distributing configuration data around should not require a COG running to serve it up. Not sure how to handle that.
Are you saying Elev8 is not using drivers for whatever sensors and actuators?
Admittedly distributing configuration data around should not require a COG running to serve it up. Not sure how to handle that.
The Elev8 uses plenty of drivers, and for those I find HUB variables sufficient for most things. The F32 object is a special case that would use messages, ditto for serial I/O. In those cases the message system you suggest would be quite useful.
Independent of that, there are plenty of cases, particularly in larger projects, where a bunch of related data and functions need to be accessed in a variety of places. Try implementing a simple Vector object in Spin - it's not pretty.
In C++ I can easily create an object that is used in many other objects in my code (like my preferences). I can have a global one that's used for anything accessing the data normally, and also easily create a temporary one for when new prefs are being read. If the read is aborted, I just throw it away. This kind of thing in Spin is quite hard, and is ultimately one of the big reasons I moved away from Spin for this project (and a number of others). It doesn't scale very well.
Yes. In that case the HUB variables are your communication channel.
The idea of "channels" in a high level language is to formalize such things. In the same way that "functions" or "procedures" formalize the use of CALL, RET, and whatever parameter passing and return mechanism on might come up with in assembler.
Try implementing a simple Vector object in Spin - it's not pretty.
Hmm... If you are talking a vector/matrix object in Spin that does addition, subtraction, products etc, then I though one could include that code anywhere in an application and only one instance of the code, but perhaps multiple instances of the VARiables was built in to the program.
Ah, but if your matrix object uses DAT and PASM you are screwed.
Presumably inline PASM in Spin 2 fixes that.
Admittedly, Spin has little support for "programming in the large".
So I already have multiple instances of my vector object, and each has independent variables. So far that's not terrible. The dot() function can't work though, because a Spin object can't do anything with another of itself. Now try using a single vector object in multiple other objects in Spin.
This is a pretty straightforward concept that exists in pretty much any modern coding language. In Spin, you're stuck with objects, and they're not easy to pass around or re-use in different parts of your code. You can't implement more than one object in the same Spin file. You can't pass an object to a function. There are ways to fake some of this, but it's hacky and awkward.
Spin works well as a learner language, and I appreciate its simplicity, but that simplicity comes at a cost of functionality, performance, and usability for larger projects.
Probably the best feature of Spin is it's simplicity. That makes it easy for novices to learn the complete language in a very short period of time. If Chip added most of the features that are being proposed it will make Spin a much more complicated language, and it will lose the attribute of being easy to learn. I think if people really want the features they are proposing they should just program in C or C++.
I think if people really want the features they are proposing they should just program in C or C++.
Oh, please! Even with the proposed new features, Spin will remain simple and useful for the novice user. And programmers can pick up the additional aspects on an as-needed basis. After all, how many new users of Spin/PASM use PASM out of the gate? The key to the new features is "make-it-possible," not "make-it-mandatory."
Probably the best feature of Spin is it's simplicity. That makes it easy for novices to learn the complete language in a very short period of time. If Chip added most of the features that are being proposed it will make Spin a much more complicated language, and it will lose the attribute of being easy to learn. I think if people really want the features they are proposing they should just program in C or C++.
I agree that Spin should be simple to learn. If we could give the sensation of being 10x more immediately productive than other systems afford, we're doing things well. I'd like for the beginner to think things like, "Wow, that was really straightforward and it does exactly what I tell it to, without any downer compromises or caveats. How come nothing else is this simple?" That engenders confidence and enthusiasm. I'd like for people to get those kinds of feelings. From my experience of late, that kind of thing has all but disappeared from the world and things are a lot more stressful and tenuous than they are fun and productive. It's like hell has settled in. It's been a struggle to get the Prop2 completed in this environment.
Dave,
Spin can still be easy to learn and use for beginners, and have features for advanced users. I love C/C++, use it all the time, but I would not force anyone to use it to get beyond beginner level coding.
Besides, Ken is demanding Blockly (rightly so) for the P2, that will be the easy for beginners programming.
Nothing, except that it's horribly verbose and complicated.
What one actually wants to say is:
v3 := v1 dot v2
Where "dot" is whatever symbology for dot product the language might support.
It would be easier in C style:
v3 = dot(v1, v2)
I don't know. These programming language things have been under debate for 50 years or so now. Still nobody has created the "right" language. As evidenced by the endless creation of new languages.
Dave,
Spin can still be easy to learn and use for beginners, and have features for advanced users. I love C/C++, use it all the time, but I would not force anyone to use it to get beyond beginner level coding.
Besides, Ken is demanding Blockly (rightly so) for the P2, that will be the easy for beginners programming.
Are there any examples of using Blockly for non-trivial programs? Does it scale well?
In any case, we should be able to have Blockly running on P2 as soon as we have either C or Spin running since BlocklyProp generates one of those.
The love, is yeah, "that's super cool." The hate is it gets them away from learning command line, text input.
But, hey! Ken is right about having it. For education, it's going to rock.
I hear kids nowadays think textual programming is "old school". The teachers are sometimes reticent to allow them something like Blockly, since there's concern that they won't really learn programming. The kids think everything should be graphical, since all their other tech is - and intuitive. They've never even read manuals. Different mindset from ours. You could do big apps in Blockly, but it seems like a heck of a push. Nothing beats good old 7-bit ASCII. What Blockly does is make SYNTAX disappear. No need to remember anythng.
Comments
"Perfect" is of course impossible for a PRNG.
That just leaves the question as to if such a thing should be baked into the language syntax or provided as a method in some library object.
I feel the later is more appropriate.
Sometimes it's nice to have the same random stream every time you run a program. For testing for example.
Perhaps there is not much call for that.
Yes. You should never be more than 1 second away from seeing your code run with a keystroke or click.
This would not suffice for a myriad of uses. For example, in the Elev8 project, I have an object which manages user settings, needed by many different code modules, but it doesn't run a cog - it's just a place to park functions and data that relate to each other. (you know, like what objects are actually for). A message passing system would be useful for things that are actually running independently, but that's not my principal use of objects.
Also, that syntax makes my head hurt, from the person who rails against ternary operators no less. Slightly more verbose, but dramatically more readable:
Send(x, channel)
Receive(x, channel)
There's a free-running 32-bit LFSR that each cog gets a differently-scrambled-and-inverted copy of, accessible through the GETRND D instruction. No need for seeds.
? and ! made sense in the context of Occam. Which was a pretty lean and mean language. They were just simple binary operators like + and -. They have some logic in that you are asking, "?", for some data from a channel. You may have to wait for the reply there. Or shouting "!" some data into a channel.
David Betz, True. But your compiled binary for a PC does not have to be very big before C++ compilation times become annoying.
Chip, We are going to replace Spin with Javascript then
JasonDorie, Are you saying Elev8 is not using drivers for whatever sensors and actuators?
As far as I can tell it is a common pattern for Prop applications to be built from many concurrently running processes each of which is an objects. What with the 8 cores and all that.
Admittedly distributing configuration data around should not require a COG running to serve it up. Not sure how to handle that.
The Elev8 uses plenty of drivers, and for those I find HUB variables sufficient for most things. The F32 object is a special case that would use messages, ditto for serial I/O. In those cases the message system you suggest would be quite useful.
Independent of that, there are plenty of cases, particularly in larger projects, where a bunch of related data and functions need to be accessed in a variety of places. Try implementing a simple Vector object in Spin - it's not pretty.
In C++ I can easily create an object that is used in many other objects in my code (like my preferences). I can have a global one that's used for anything accessing the data normally, and also easily create a temporary one for when new prefs are being read. If the read is aborted, I just throw it away. This kind of thing in Spin is quite hard, and is ultimately one of the big reasons I moved away from Spin for this project (and a number of others). It doesn't scale very well.
The idea of "channels" in a high level language is to formalize such things. In the same way that "functions" or "procedures" formalize the use of CALL, RET, and whatever parameter passing and return mechanism on might come up with in assembler. Hmm... If you are talking a vector/matrix object in Spin that does addition, subtraction, products etc, then I though one could include that code anywhere in an application and only one instance of the code, but perhaps multiple instances of the VARiables was built in to the program.
Ah, but if your matrix object uses DAT and PASM you are screwed.
Presumably inline PASM in Spin 2 fixes that.
Admittedly, Spin has little support for "programming in the large".
Like:
v1.set( 0, 0, 1 )
v2.set( 1, 0, 0 )
v3 = v1.dot( v2 )
So I already have multiple instances of my vector object, and each has independent variables. So far that's not terrible. The dot() function can't work though, because a Spin object can't do anything with another of itself. Now try using a single vector object in multiple other objects in Spin.
This is a pretty straightforward concept that exists in pretty much any modern coding language. In Spin, you're stuck with objects, and they're not easy to pass around or re-use in different parts of your code. You can't implement more than one object in the same Spin file. You can't pass an object to a function. There are ways to fake some of this, but it's hacky and awkward.
Spin works well as a learner language, and I appreciate its simplicity, but that simplicity comes at a cost of functionality, performance, and usability for larger projects.
Didn't see the prior message - 62 msgs behind. I pulled the trigger a little too soon on that. Ah, well, I do agree!
Mike R...
-Phil
That leaves us with making objects like we would in C. Every function call gets a pointer parameter to the data it should work on. The instance data.
Except Spin has no structures so that is not pretty either.
-Phil
I agree that Spin should be simple to learn. If we could give the sensation of being 10x more immediately productive than other systems afford, we're doing things well. I'd like for the beginner to think things like, "Wow, that was really straightforward and it does exactly what I tell it to, without any downer compromises or caveats. How come nothing else is this simple?" That engenders confidence and enthusiasm. I'd like for people to get those kinds of feelings. From my experience of late, that kind of thing has all but disappeared from the world and things are a lot more stressful and tenuous than they are fun and productive. It's like hell has settled in. It's been a struggle to get the Prop2 completed in this environment.
Spin can still be easy to learn and use for beginners, and have features for advanced users. I love C/C++, use it all the time, but I would not force anyone to use it to get beyond beginner level coding.
Besides, Ken is demanding Blockly (rightly so) for the P2, that will be the easy for beginners programming.
What one actually wants to say is:
v3 := v1 dot v2
Where "dot" is whatever symbology for dot product the language might support.
It would be easier in C style:
v3 = dot(v1, v2)
I don't know. These programming language things have been under debate for 50 years or so now. Still nobody has created the "right" language. As evidenced by the endless creation of new languages.
In any case, we should be able to have Blockly running on P2 as soon as we have either C or Spin running since BlocklyProp generates one of those.
The love, is yeah, "that's super cool." The hate is it gets them away from learning command line, text input.
But, hey! Ken is right about having it. For education, it's going to rock.
I just just wanted to get from reset to PASM a.s.a.p.
The great thing is that the way PASM is integrated into Spin makes it really easy to get PASM running and ignore Spin
I know, I may not be a typical case.
I hear kids nowadays think textual programming is "old school". The teachers are sometimes reticent to allow them something like Blockly, since there's concern that they won't really learn programming. The kids think everything should be graphical, since all their other tech is - and intuitive. They've never even read manuals. Different mindset from ours. You could do big apps in Blockly, but it seems like a heck of a push. Nothing beats good old 7-bit ASCII. What Blockly does is make SYNTAX disappear. No need to remember anythng.
This is a fun read. I've given copies of the little paperback out quite a few times now. I keep a couple handy.
The P2 has 16 processors.
There are those that want to program in Spin, others PASM, others C/C++, even others with Blockly (Whatever that is) or Forth or BASIC....
These things should all be able to live together.
Not by making it possible to call C++ methods from Spin or whatever contorted linkage.
But by passing messages from COG to COG. Whatever language is running on either.
This inability has been a hindrance in reusing PASM drivers, wrapped in Spin objects, with C/C++.