Python has these extremely powerful standard libraries (objects)
......
All these fantastic libraries will be available to us on P2 if we can support python. I am not sure how much micropython limits us.
Maybe we are going to need those HyperRAM boards after all Only days ago I thought they were useless.
What you really want is a Pi 4, isn't it? It has GBs of RAM and full python support etc.
If you are talking about the P2 perhaps you are forgetting its target application and specialty, in real-time machine control, not in badly emulating a PC.
Maybe Parallax would be better off adopting a SoC that can run Linux and Python if they are interested in the schools market. Leave the P2 for us engineers and hobbyists etc.
What you really want is a Pi 4, isn't it? It has GBs of RAM and full python support etc.
Been using FreeBasic on Pi for years. It had oop but does not force you to use it.
Been using full 32bit colour, hi res, fonts, and so on - but not for control purposes.
(Pi4 arrived this afternoon.)
And now we have a stripped down version of Freebasic for the prop.
What you really want is a Pi 4, isn't it? It has GBs of RAM and full python support etc.
Been using FreeBasic on Pi for years. It had oop but does not force you to use it.
Been using full 32bit colour, hi res, fonts, and so on - but not for control purposes.
(Pi4 arrived this afternoon.)
And now we have a stripped down version of Freebasic for the prop.
so- happy bunny
Dave
There is also Pi-cromite should you need MM Basic interpreter on the Pi.
We’ve combined the power of two unique, open source systems, (the Parallax Propeller, created by Chip Gracey, and the Micromite MkII, created by Geoff Graham) and created a platform capable of both retro time travel and modern day microconroller fun in the same package.
That's exactly my intention...Prop for real time, Micromite for management and Android device for user interface. User interface receives the physical abuse and accounts for a lot of dead production equipment....why make it proprietary?
For many of my clients, 2am Sunday is the same as 2pm Tuesday. MTTR (mean time to repair) is a big deal. I will never use the Prop's video capabilities when everyone is already carrying a user interface in their pockets.
I doubt the popularity of Python, like Linux it is used by a certain group but who am I to decide this, programming COBOL and C# lately.
Mike
Peter and Mike, I understand and can commiserate with most if not all of what you've mentioned.
However, this has been hashed over on every real tech site in existence for the past decade and more.
No one wants to learn some oddball, one-off language.
And this is doubly so for the folks tasked with teaching.
At a minimum, they want something 'they' can get quick help on, and something that will actually be useable in the future for their students.
I don't think Python is really suited in any way, shape, or form for a uC, however the .edu folks very likely will give it a second look compared to some spin-thing. As well possibly will those folks familiar with Python.
The more Props Parallax sells, the better the change there is for a possible P3.
Chip can make Spin run like greased lightening all the while, and those interested in it will use it.
Parallax doesn't need to sell any P2s, they just need to make money. So if the education market which I take to be all those schools that are pre-college, would continue to buy Basic Stamps then there is a possibility of a P3, simply because this is what Chip wants. My mention of adopting an SoC was half serious because if Python is that important then you want to do it properly. So Parallax could sell an ARM based SoC mounted onto a a small socketable module preloaded with Python. They could call this their "Python Stamp". I'm sure even P2 customers would use them too.
Maybe as an old fart I do not want to learn some oddball, one-off language like Python.
Sorry for that, but honestly I have seen languages come and go, what stays with us is Basic, C, Cobol, maybe Fortran and Lisp. And the FORTH does not die either.
Everything else is just - hmm - hogwash. Good for some years, good for a one off, but long time usable?
The only thing we can be sure off is that TAQOZ will be in the ROM even on a 20 year old P2, something to consider when developing for the P2.
Python seems to be the language of choice for AI. That's probably because of the vast libraries for data handling.
So the schools seem to be jumping on the bandwagon by teaching Python. There is lots of help out there which helps the teachers. So a micro version of Python makes sense to the teachers.
And no, we are likley never going to run anything commercial on micropython. But if it helps sell P2' for Parallax, then I am all for it, because I want a 50nm P3
I've taught both Spin and C on the P1 at the high-school level. While C is accepted as a useful language to learn by school admin types -- Spin is not -- it's comparative complexity makes it less desirable to teach, and progress was slow. (Half my time teaching C was spent running down missing or extra braces in the kids' code.) By comparison, Spin was a breeze, and the Propeller Tool helped make it so.
Enter Python. That just might be Parallax's dream language for their P2 educational efforts. It's both accepted by admin types and, like Spin, has an elegant syntax. What's needed, in addition to a good compiler, is an IDE that's as drop-dead easy to learn and use as the Prop Tool.
Most college grads are leaving school knowing Python these days.
Re: which?
BOTH
Deploy the center of gravity principle. Ken will. As these things get into the wild, some will appear resonant, and will become attractive. They all will to a degree, but the key in all this is to run with whatever is growing into a strong attractor.
(Half my time teaching C was spent running down missing or extra braces in the kids' code.)
This was also my issue when teaching with C.
Currently we focus on Python. With Anki closing, one way or another, my plan is to be teaching with a Python robot. While I haven't been a fan of any Sphero before, we are watching RVR. Even better would be a P2 option. Or maybe a mashup with P1 and Raspberry Pi. Significantly more development time on that though.
Rather than trying to count curly braces etc, I can look at indentation and troubleshoot student code in seconds in Python. Plus students need 10% the help they did with C in the first place.
Even if the P2 robot isn't as powerful in Python, we'd use it to introduce them.
Sure we might get the high schoolers with some experience in SPIN to take full advantage of the robot. But 80% or more of the students will be in Python.
You can't scale a business trying to train teachers to teach C or SPIN, pay the teachers enough, and keep the price of the course low enough at the same time. At least that's my experience.
As much as I want to teach in SPIN since I think it would get the most out of the hardware, I have to teach with something that is practical for both students and teachers etc.
Most other companies teach Scratch Lego and Minecraft. There is a reason for this unfortunately.
Also I'm fully aware the situation for public schools may be very different from companies like me that focus on after school and Summer camps etc.
Do you guys know of a company doing after school classes, at scale, with multiple teachers and locations, in C?
While I use C/C++ for a living and have few issues with it (after something like 35 years using it), I agree that it's not a good place to start teaching new programmers.
BASIC, Python, and things like Blockly or Scratch are much better starting places. Python currently being one of the most practical to learn because of real world usage and support.
Spin would be easier to teach, sure, but almost none of the students learning it would end up using it later on, since most of the world doesn't even know it exists, let alone use if for anything.
I think an interesting idea would be to get a Python core running on P2 that is written using the P2 features like xbyte, etc. to make it more compact and perform better. The Python runtime is just a byte code virtual machine after all, so it should benefit quite nicely from Chip's enhancements in the P2 that were done for Spin2.
I think an interesting idea would be to get a Python core running on P2 that is written using the P2 features like xbyte, etc. to make it more compact and perform better. The Python runtime is just a byte code virtual machine after all, so it should benefit quite nicely from Chip's enhancements in the P2 that were done for Spin2.
Lots of people have said this, but now that I've looked into Python internals I don't think it's so easy. The Python virtual machine is a very different beast from the Spin2 one -- they both use bytecodes, but that's about where the similarity ends. For example, the Python bytecodes typically work on any type (float, integer, string, or even user classes) and those types are not known until run time. So the interpreter has to check the types of the operands and then dispatch to object specific routines to implement plus, minus, etc.
This has several consequences:
(1) The actual bytecode decode overhead is a much smaller fraction of the execution time than it is for Spin. XBYTE will still give you a saving, but it's relatively less of a speedup for Python (where most of the time is spent actually executing the bytecodes) than for Spin2 (where the bytecode implementation is often just a few instructions).
(2) The interpreter code probably won't fit in COG memory. This makes use of XBYTE tricky, because XBYTE and hubexec aren't compatible (well, not without some very careful book-keeping regarding the rdfast state) and XBYTE needs to use the LUT for its tables.
(3) The Python bytecode interpreter is pretty complicated. Porting it to PASM is going to be a big job; certainly do-able, but I think it's more work than implementing an interpreter for, say, a CPU instruction set.
I'm not saying that it's impossible (never say "impossible" in the Propeller world ), just that it's going to be hard, and an XBYTE implementation of Python may only give a 5%-10% speedup, rather than the 100% speedup one might see with a simpler kind of bytecode interpreter.
(2) The interpreter code probably won't fit in COG memory.
In the Zilog 8671 BASIC chip, the BASIC interpreter, itself, was interpreted. This saved an enormous amount of the chip's limited ROM space. It wasn't fast, but it was compact. Perhaps something like this could work in the P2 with Python. Put the interpreter interpreter in one COG, the interpreter and app bytecodes in HUB RAM.
(2) The interpreter code probably won't fit in COG memory.
In the Zilog 8671 BASIC chip, the BASIC interpreter, itself, was interpreted. This saved an enormous amount of the chip's limited ROM space. It wasn't fast, but it was compact. Perhaps something like this could work in the P2 with Python. Put the interpreter interpreter in one COG, the interpreter and app bytecodes in HUB RAM.
-Phil
Eric's version of MicroPython is essentially already doing this. It is compiled to run on RISC-V which is emulated by a COG.
Parallax doesn't need to sell any P2s, they just need to make money.
I'm waiting for Ken to chime in, in agreement ....
One of the downsides of Parallax having such an open design process is the majority of input is based upon individuals's desires, needs, and biases.
I've done just enough Python to be basicly proficient, yet the white space issue persists for me enough that I'm still looking. However it is and has been a primary language in the .edu space for several+ years now.
Python isn't the the performant leader, however it is something that people are familiar with, and just might catch many .edu folks eye when perusing .edu offerings.
Not taking that natural marketing synergy option which is free for the taking is simply a bad business decision.
Folks interested in performance will naturally skip down to see it supports C, ASM, a Spin language, and be happy.
I'm wondering if C/C++ is going the way assembly did a while ago. I work for a medical devices company and they are using Python on at least one of their products for all of the high-level communications/network code. They, of course, still use C/C++ for stuff that needs high performance but that becomes less and less as time goes on. Sort of like the way we used to write little bits of assembly language under a mostly C main program.
(2) The interpreter code probably won't fit in COG memory.
In the Zilog 8671 BASIC chip, the BASIC interpreter, itself, was interpreted. This saved an enormous amount of the chip's limited ROM space. It wasn't fast, but it was compact. Perhaps something like this could work in the P2 with Python. Put the interpreter interpreter in one COG, the interpreter and app bytecodes in HUB RAM.
-Phil
Eric's version of MicroPython is essentially already doing this. It is compiled to run on RISC-V which is emulated by a COG.
I'm going to be a little bit picky here: my version is actually a JIT compiler, so ultimately the C code is getting compiled to native instructions. It's just happening in 2 steps -- at build time we convert from C to RISC-V instructions, then at run time we convert from RISC-V code to P2 code. The only drawback is that we can't convert the whole program, so we have to keep a cache of the converted P2 code (which runs out of HUB using hubexec).
The P2 is certainly big enough for MicroPython (as we can see, since it's running already). But the main loop of the python bytecode interpreter won't fit in COG memory, so trying to accelerate it with XBYTE is probably not feasible. I mean yeah, you could have an XBYTE interpreter that then interprets the Python interpreter, but that I think that would result in a net slowdown over the current hubexec implementation.
(2) The interpreter code probably won't fit in COG memory.
In the Zilog 8671 BASIC chip, the BASIC interpreter, itself, was interpreted. This saved an enormous amount of the chip's limited ROM space. It wasn't fast, but it was compact. Perhaps something like this could work in the P2 with Python. Put the interpreter interpreter in one COG, the interpreter and app bytecodes in HUB RAM.
-Phil
Eric's version of MicroPython is essentially already doing this. It is compiled to run on RISC-V which is emulated by a COG.
I'm going to be a little bit picky here: my version is actually a JIT compiler, so ultimately the C code is getting compiled to native instructions. It's just happening in 2 steps -- at build time we convert from C to RISC-V instructions, then at run time we convert from RISC-V code to P2 code. The only drawback is that we can't convert the whole program, so we have to keep a cache of the converted P2 code (which runs out of HUB using hubexec).
The P2 is certainly big enough for MicroPython (as we can see, since it's running already). But the main loop of the python bytecode interpreter won't fit in COG memory, so trying to accelerate it with XBYTE is probably not feasible. I mean yeah, you could have an XBYTE interpreter that then interprets the Python interpreter, but that I think that would result in a net slowdown over the current hubexec implementation.
Ah yes, the RISC-V emulator is itself a JIT compiler. Very nice!
I asked Lachlan and Brian (ozpropdev) about MicroPython's source code size and they said it's about 2MB spread over 120+ files, not all of which would be necessarily needed. I think there's a lot of complexity within 2MB of source code.
I am not an expert in the ins-n-outs and advantages of different computer languages. But is seems that every few years there is a new 'must know' language. So I decided that I would try to learn the basics of Python along with my current efforts with C, Blockly, P2 Basic, Spin1 and 2, P2ASM and Tachyon forth (each of which has advantages I can understand for certain purposes.) However, I never got through the "hello world" example.
What are the key advantages of Python (and for what applications)? I know that it is popular for education, but so were Basic and C along with open classrooms, new math, STEM (although in some districts it is STEM + A, R, W, PE and more alphabet soup as those excluded disciplines make their voices heard.)
Not trying to start a language war; just trying to figure out why I would want to spend the effort to learn it.
Comments
What you really want is a Pi 4, isn't it? It has GBs of RAM and full python support etc.
If you are talking about the P2 perhaps you are forgetting its target application and specialty, in real-time machine control, not in badly emulating a PC.
Maybe Parallax would be better off adopting a SoC that can run Linux and Python if they are interested in the schools market. Leave the P2 for us engineers and hobbyists etc.
I don't get the impression you have tried Eric's Micropython image. Why not fire it up?
I will do that as soon as i get time
+1
Hi
Been using FreeBasic on Pi for years. It had oop but does not force you to use it.
Been using full 32bit colour, hi res, fonts, and so on - but not for control purposes.
(Pi4 arrived this afternoon.)
And now we have a stripped down version of Freebasic for the prop.
so- happy bunny
Dave
There is also Pi-cromite should you need MM Basic interpreter on the Pi.
And Armmite on the Nucleo board.
Oh yes and combine a micromite with mmbasic and the prop gives-
http://propellerpowered.com/the-micromite-companion/
all provided by-Jeff Ledger Aka Oldbitcollector
Dave
For many of my clients, 2am Sunday is the same as 2pm Tuesday. MTTR (mean time to repair) is a big deal. I will never use the Prop's video capabilities when everyone is already carrying a user interface in their pockets.
Peter and Mike, I understand and can commiserate with most if not all of what you've mentioned.
However, this has been hashed over on every real tech site in existence for the past decade and more.
No one wants to learn some oddball, one-off language.
And this is doubly so for the folks tasked with teaching.
At a minimum, they want something 'they' can get quick help on, and something that will actually be useable in the future for their students.
I don't think Python is really suited in any way, shape, or form for a uC, however the .edu folks very likely will give it a second look compared to some spin-thing. As well possibly will those folks familiar with Python.
The more Props Parallax sells, the better the change there is for a possible P3.
Chip can make Spin run like greased lightening all the while, and those interested in it will use it.
Sorry for that, but honestly I have seen languages come and go, what stays with us is Basic, C, Cobol, maybe Fortran and Lisp. And the FORTH does not die either.
Everything else is just - hmm - hogwash. Good for some years, good for a one off, but long time usable?
The only thing we can be sure off is that TAQOZ will be in the ROM even on a 20 year old P2, something to consider when developing for the P2.
Enjoy!
Mike
So the schools seem to be jumping on the bandwagon by teaching Python. There is lots of help out there which helps the teachers. So a micro version of Python makes sense to the teachers.
And no, we are likley never going to run anything commercial on micropython. But if it helps sell P2' for Parallax, then I am all for it, because I want a 50nm P3
Enter Python. That just might be Parallax's dream language for their P2 educational efforts. It's both accepted by admin types and, like Spin, has an elegant syntax. What's needed, in addition to a good compiler, is an IDE that's as drop-dead easy to learn and use as the Prop Tool.
-Phil
Most college grads are leaving school knowing Python these days.
Re: which?
BOTH
Deploy the center of gravity principle. Ken will. As these things get into the wild, some will appear resonant, and will become attractive. They all will to a degree, but the key in all this is to run with whatever is growing into a strong attractor.
This was also my issue when teaching with C.
Currently we focus on Python. With Anki closing, one way or another, my plan is to be teaching with a Python robot. While I haven't been a fan of any Sphero before, we are watching RVR. Even better would be a P2 option. Or maybe a mashup with P1 and Raspberry Pi. Significantly more development time on that though.
Rather than trying to count curly braces etc, I can look at indentation and troubleshoot student code in seconds in Python. Plus students need 10% the help they did with C in the first place.
Even if the P2 robot isn't as powerful in Python, we'd use it to introduce them.
Sure we might get the high schoolers with some experience in SPIN to take full advantage of the robot. But 80% or more of the students will be in Python.
You can't scale a business trying to train teachers to teach C or SPIN, pay the teachers enough, and keep the price of the course low enough at the same time. At least that's my experience.
As much as I want to teach in SPIN since I think it would get the most out of the hardware, I have to teach with something that is practical for both students and teachers etc.
Most other companies teach Scratch Lego and Minecraft. There is a reason for this unfortunately.
Also I'm fully aware the situation for public schools may be very different from companies like me that focus on after school and Summer camps etc.
Do you guys know of a company doing after school classes, at scale, with multiple teachers and locations, in C?
BASIC, Python, and things like Blockly or Scratch are much better starting places. Python currently being one of the most practical to learn because of real world usage and support.
Spin would be easier to teach, sure, but almost none of the students learning it would end up using it later on, since most of the world doesn't even know it exists, let alone use if for anything.
I think an interesting idea would be to get a Python core running on P2 that is written using the P2 features like xbyte, etc. to make it more compact and perform better. The Python runtime is just a byte code virtual machine after all, so it should benefit quite nicely from Chip's enhancements in the P2 that were done for Spin2.
Lots of people have said this, but now that I've looked into Python internals I don't think it's so easy. The Python virtual machine is a very different beast from the Spin2 one -- they both use bytecodes, but that's about where the similarity ends. For example, the Python bytecodes typically work on any type (float, integer, string, or even user classes) and those types are not known until run time. So the interpreter has to check the types of the operands and then dispatch to object specific routines to implement plus, minus, etc.
This has several consequences:
(1) The actual bytecode decode overhead is a much smaller fraction of the execution time than it is for Spin. XBYTE will still give you a saving, but it's relatively less of a speedup for Python (where most of the time is spent actually executing the bytecodes) than for Spin2 (where the bytecode implementation is often just a few instructions).
(2) The interpreter code probably won't fit in COG memory. This makes use of XBYTE tricky, because XBYTE and hubexec aren't compatible (well, not without some very careful book-keeping regarding the rdfast state) and XBYTE needs to use the LUT for its tables.
(3) The Python bytecode interpreter is pretty complicated. Porting it to PASM is going to be a big job; certainly do-able, but I think it's more work than implementing an interpreter for, say, a CPU instruction set.
I'm not saying that it's impossible (never say "impossible" in the Propeller world
https://github.com/totalspectrum/micropython. The P2 port is on the "totalspectrum" branch in the directory ports/riscvp2.
-Phil
I'm waiting for Ken to chime in, in agreement ....
One of the downsides of Parallax having such an open design process is the majority of input is based upon individuals's desires, needs, and biases.
I've done just enough Python to be basicly proficient, yet the white space issue persists for me enough that I'm still looking. However it is and has been a primary language in the .edu space for several+ years now.
Python isn't the the performant leader, however it is something that people are familiar with, and just might catch many .edu folks eye when perusing .edu offerings.
Not taking that natural marketing synergy option which is free for the taking is simply a bad business decision.
Folks interested in performance will naturally skip down to see it supports C, ASM, a Spin language, and be happy.
I'm going to be a little bit picky here: my version is actually a JIT compiler, so ultimately the C code is getting compiled to native instructions. It's just happening in 2 steps -- at build time we convert from C to RISC-V instructions, then at run time we convert from RISC-V code to P2 code. The only drawback is that we can't convert the whole program, so we have to keep a cache of the converted P2 code (which runs out of HUB using hubexec).
The P2 is certainly big enough for MicroPython (as we can see, since it's running already). But the main loop of the python bytecode interpreter won't fit in COG memory, so trying to accelerate it with XBYTE is probably not feasible. I mean yeah, you could have an XBYTE interpreter that then interprets the Python interpreter, but that I think that would result in a net slowdown over the current hubexec implementation.
What are the key advantages of Python (and for what applications)? I know that it is popular for education, but so were Basic and C along with open classrooms, new math, STEM (although in some districts it is STEM + A, R, W, PE and more alphabet soup as those excluded disciplines make their voices heard.)
Not trying to start a language war; just trying to figure out why I would want to spend the effort to learn it.
Thanks
Tom
I'm sure there are other things it has as advantages but probably there are others here with more knowledge than me.