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.
That's interesting to consider that C/C++ might go the way of assembly language and not be used very much. I think hardcore programming will probably use it indefinitely, but the upper-level stuff done by the newer generation would naturally be in something easier to converse in, like Pyhon. I have this fear that things will eventually get dumbed down to the point where the typical programmer has about as much say over what's going to happen as the guy standing in line at the Department of Motor Vehicles. The operating system might filter down what his program is attempting to do, to a narrow band of allowable outcomes. Well, I think the web's been working like that, already, for good reason. Hopefully, microcontrollers will remain an outpost of freedom.
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.
That'd be Rogloh and his 'C eyes' doing the deep dive and checking out the source size
Tom, googling 'micropython advantages' gives a rough outline, but at a top level I'd describe it as "friendly and useful". It seems to have the momentum with respect to gluing various things together, and is easy to approach, so it makes a lot of sense for education.
What are the key advantages of Python (and for what applications)? ...
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
Why Python?
Easy to read
Easy to write
Supports object oriented designs
Acceptable performance (faster than bash, slower than C)
Can interface with C-libraries for performance-critical code
Standard libraries support a lot of what you need to do.
Mature enough that a wide array of libraries exist for anything not in the standard libraries. (see https://pypi.org/)
Dig a little deeper...
Let's focus on two (or three) of those points: easy to read/write and supports OOD. Python is one of few languages that satisfies all of the following:
* Easy to read syntax
* Easy to read standard library package/class/function/variable names
* Dynamic types (makes it easier to write)
* Interpreted with included REPL (interactive prompt - this is a key distinction because otherwise Java 1-8 almost qualify as well)
* Support for OOD
Because of these points, Python is able to satisfy the needs of grade-school kids that want to print "Hello world" AND enterprise developers that need maintainable and scalable code for the next decade.
Lots of people complain about performance... but 95% of the time, it doesn't matter. If I'm writing a web service to administer a user's roles for my application, I don't care if it takes 1ms or 10us to respond... both are plenty fast enough for me. I don't care if it can handle 1,000 requests per second, or 100,000 requests per second... I'll only be throwing 5-20 per second at it. What DOES matter to me is whether it takes me 2 hours or a week to write it and whether it takes my replacement a few hours or a week to fix a bug.
When should it be avoided?
If you have strict performance requirements (as in, numbers that you can measure and you have proved that Python isn't fast enough), or you don't have enough space for the interpreter (your code will be nice and small, but the interpreter and all of its standard libraries are quite large), you may not have a choice. I think this point has been made enough, I won't speak further to it.
(Personal preference follows...)
If you have a single, large, Python codebase (I'm talking 1,000+ lines, which is a ton of logic in Python), you may find yourself getting lost in the pool of dynamically typed variables. This is exactly what happened to me. I was writing a Python application that, at 1,700 lines, I decided to convert to Java. If I'd had access to Python 3 with type hints (ability to write "def foo(x: int, y: int, name: str) -> bool") then it MIGHT have been different. But I didn't. And the project was getting so large that, even with PyCharm to help me out as much as possible, I couldn't keep it all straight in my head. I was constantly having to look at function implementations to remind myself what types I should be passing into what functions. and what values I was getting back. I badly needed a statically typed language.
Wrapping it all up...
So, with MicroPython, we have the space for a Python interpreter. We can run high-level business logic in one or two of the P2's cogs, and trigger native code (maybe written in C/C++, maybe Forth, whatever you want) in other cogs. I think MicroPython is a PERFECT fit for the Propeller 2.
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.
Take a look at the Python loader for P2.
Advantages: very compact source, easily portable, and easy to make changes to
Disadvantages: real work is slower, but the Python P2 loader speed improved significantly using the Encode64 library (likely coded in C )
Using the library, and a single Encode block download, the Python does very little looping, and the overhead reduces to 'not significant'.
Another angle: Using compiled FreeBASIC, I've been usefully inserting delays of 100us~1ms into comms testing.
That wobbles a little in Windows+USB, but it worked surprisingly well on averages. That sub-millisecond space is unlikely to be a Windows Python target.
On P2 an advantage is there are 7? other cogs that can do that faster work.
My thoughts on these are reserved because while I like python on a PC, I'm not sure how MicroPython will play out on the P2. It's a pity that the interpreter main loop doesn't fit in a cog, but then again so what? We have 7 other cogs. But even if uPy does fit and 7 other cogs and the smart pins can do all the real-time ops, how much memory is left for user application and storage and display buffers?
I superloaded TAQOZ yesterday with every utility I had so that beyond the normal FAT32 and formatter and audio/image/video routines I also included the decompiler, the clockgen, the breakout game, Mandelbrot, Silabs C2 programmer, EasyNet servers etc and all the code and dictionary came to around 32kB. So it seems to me that TAQOZ extreme edition could hide away in a tiny corner along with Python somehow
BTW, Hello World in TAQOZ "REPL" is terribly complex:
In Python, it is easy to launch an instance of your favorite browser and control it (webbrowser), decode it (beautifulsoup), read and write files (os), extract/merge database files (pandas). Then there is a scientific maths module (numpy) which I haven't used yet although I expect to shortly.
Python also comes in another package form that is being heavily used in Unis and the Scientific community - it's called Annaconda and comes with Jupyter Notebook which is a bit hard to explain - its a sort of interactive interpreter interface.
As for that difficult "Hello World" program
print("hello world")
BTW Do any of you remember how slow Basic was?
It was an interpreted language until it became mainstream with Visual Basic. Then MS gave it the same compiler backend as Visual C. Nothing to stop Python graduating either.
BTW Do any of you remember how slow Basic was?
It was an interpreted language until it became mainstream with Visual Basic. Then MS gave it the same compiler backend as Visual C. Nothing to stop Python graduating either.
Well, actually, compiling Python efficiently is very difficult, much more so than BASIC, because everything is dynamic in the language. An expression like "x+y" could be adding integers, adding floating point numbers, concatenating strings, or even doing some user defined thing on user classes, and the kicker is that it depends entirely on what is in "x" and "y" at run time. So in general it's not possible to compile down "x+y" to a simple function call, it has to dispatch on the run time type of "x".
For a few of my own projects I have written the program logic in Python and then used a Propeller as a peripheral. The P1 simply responds to commands issued by the PC (e.g. a Raspberry Pi). If I ever use a P2 I'll probably do the same thing.
I've written a library that I use as a foundation for such projects: PeekPoke. (Apologies for self-promotion.) Like the name implies, this library allows reading and writing hub memory from Python. This allows the PC to use hub memory structures to control cogs, just like with ordinary inter-cog communications.
The hardware side of things can be tricky for me (I'm just a hobbyist), so offloading that logic onto firmware that can be built and tested separately makes sense. Meanwhile, as others have stated in this thread, Python is an easy language for writing high-level code. Having the REPL command-line is nice for testing and playing around.
This kind of separation also seems like it would be ideal for getting Propeller-based hardware in the classroom. Right out-of-the-box the robot (or whatever) can respond to high-level commands from Python -- with no need to ever use SPIN, PASM, or program an EEPROM. But that option would still be there -- as it should.
My thoughts on these are reserved because while I like python on a PC, I'm not sure how MicroPython will play out on the P2. It's a pity that the interpreter main loop doesn't fit in a cog, but then again so what? We have 7 other cogs. But even if uPy does fit and 7 other cogs and the smart pins can do all the real-time ops, how much memory is left for user application and storage and display buffers?
I superloaded TAQOZ yesterday with every utility I had so that beyond the normal FAT32 and formatter and audio/image/video routines I also included the decompiler, the clockgen, the breakout game, Mandelbrot, Silabs C2 programmer, EasyNet servers etc and all the code and dictionary came to around 32kB. So it seems to me that TAQOZ extreme edition could hide away in a tiny corner along with Python somehow
BTW, Hello World in TAQOZ "REPL" is terribly complex:
Hah, finally you have the thought by yourself. That is exacly what I am begging for, for a while now. Some 32k Blob I can include into my program compiled with fastspin, running its own cog and I can talk FORTH-SNIPPETS to it via some mailboxes to avoid using pins for communication.
A simulated serial port to a TAQOZ console, usable from fastspin. I do the fastspin part, I just need a BLOB to load and a simple mailbox-protocol for read and write the TAQOZ console.
And the BLOB to load at even 0-32k, but better with adaptable start address.
Then TAQOZ extreme edition could hide away in a tiny corner along with any program
Comments
That's interesting to consider that C/C++ might go the way of assembly language and not be used very much. I think hardcore programming will probably use it indefinitely, but the upper-level stuff done by the newer generation would naturally be in something easier to converse in, like Pyhon. I have this fear that things will eventually get dumbed down to the point where the typical programmer has about as much say over what's going to happen as the guy standing in line at the Department of Motor Vehicles. The operating system might filter down what his program is attempting to do, to a narrow band of allowable outcomes. Well, I think the web's been working like that, already, for good reason. Hopefully, microcontrollers will remain an outpost of freedom.
That'd be Rogloh and his 'C eyes' doing the deep dive and checking out the source size
Tom, googling 'micropython advantages' gives a rough outline, but at a top level I'd describe it as "friendly and useful". It seems to have the momentum with respect to gluing various things together, and is easy to approach, so it makes a lot of sense for education.
Why Python?
Easy to read
Easy to write
Supports object oriented designs
Acceptable performance (faster than bash, slower than C)
Can interface with C-libraries for performance-critical code
Standard libraries support a lot of what you need to do.
Mature enough that a wide array of libraries exist for anything not in the standard libraries. (see https://pypi.org/)
Dig a little deeper...
Let's focus on two (or three) of those points: easy to read/write and supports OOD. Python is one of few languages that satisfies all of the following:
* Easy to read syntax
* Easy to read standard library package/class/function/variable names
* Dynamic types (makes it easier to write)
* Interpreted with included REPL (interactive prompt - this is a key distinction because otherwise Java 1-8 almost qualify as well)
* Support for OOD
Because of these points, Python is able to satisfy the needs of grade-school kids that want to print "Hello world" AND enterprise developers that need maintainable and scalable code for the next decade.
Lots of people complain about performance... but 95% of the time, it doesn't matter. If I'm writing a web service to administer a user's roles for my application, I don't care if it takes 1ms or 10us to respond... both are plenty fast enough for me. I don't care if it can handle 1,000 requests per second, or 100,000 requests per second... I'll only be throwing 5-20 per second at it. What DOES matter to me is whether it takes me 2 hours or a week to write it and whether it takes my replacement a few hours or a week to fix a bug.
When should it be avoided?
If you have strict performance requirements (as in, numbers that you can measure and you have proved that Python isn't fast enough), or you don't have enough space for the interpreter (your code will be nice and small, but the interpreter and all of its standard libraries are quite large), you may not have a choice. I think this point has been made enough, I won't speak further to it.
(Personal preference follows...)
If you have a single, large, Python codebase (I'm talking 1,000+ lines, which is a ton of logic in Python), you may find yourself getting lost in the pool of dynamically typed variables. This is exactly what happened to me. I was writing a Python application that, at 1,700 lines, I decided to convert to Java. If I'd had access to Python 3 with type hints (ability to write "def foo(x: int, y: int, name: str) -> bool") then it MIGHT have been different. But I didn't. And the project was getting so large that, even with PyCharm to help me out as much as possible, I couldn't keep it all straight in my head. I was constantly having to look at function implementations to remind myself what types I should be passing into what functions. and what values I was getting back. I badly needed a statically typed language.
Wrapping it all up...
So, with MicroPython, we have the space for a Python interpreter. We can run high-level business logic in one or two of the P2's cogs, and trigger native code (maybe written in C/C++, maybe Forth, whatever you want) in other cogs. I think MicroPython is a PERFECT fit for the Propeller 2.
Advantages: very compact source, easily portable, and easy to make changes to
Disadvantages: real work is slower, but the Python P2 loader speed improved significantly using the Encode64 library (likely coded in C
Using the library, and a single Encode block download, the Python does very little looping, and the overhead reduces to 'not significant'.
Another angle: Using compiled FreeBASIC, I've been usefully inserting delays of 100us~1ms into comms testing.
That wobbles a little in Windows+USB, but it worked surprisingly well on averages. That sub-millisecond space is unlikely to be a Windows Python target.
On P2 an advantage is there are 7? other cogs that can do that faster work.
I superloaded TAQOZ yesterday with every utility I had so that beyond the normal FAT32 and formatter and audio/image/video routines I also included the decompiler, the clockgen, the breakout game, Mandelbrot, Silabs C2 programmer, EasyNet servers etc and all the code and dictionary came to around 32kB. So it seems to me that TAQOZ extreme edition could hide away in a tiny corner along with Python somehow
BTW, Hello World in TAQOZ "REPL" is terribly complex:
For 10 times it's:
Python also comes in another package form that is being heavily used in Unis and the Scientific community - it's called Annaconda and comes with Jupyter Notebook which is a bit hard to explain - its a sort of interactive interpreter interface.
As for that difficult "Hello World" program
print("hello world")BTW Do any of you remember how slow Basic was?
It was an interpreted language until it became mainstream with Visual Basic. Then MS gave it the same compiler backend as Visual C. Nothing to stop Python graduating either.
I took a look at your website. Congratulations - Very nice indeed!!!
Well, actually, compiling Python efficiently is very difficult, much more so than BASIC, because everything is dynamic in the language. An expression like "x+y" could be adding integers, adding floating point numbers, concatenating strings, or even doing some user defined thing on user classes, and the kicker is that it depends entirely on what is in "x" and "y" at run time. So in general it's not possible to compile down "x+y" to a simple function call, it has to dispatch on the run time type of "x".
I've written a library that I use as a foundation for such projects: PeekPoke. (Apologies for self-promotion.) Like the name implies, this library allows reading and writing hub memory from Python. This allows the PC to use hub memory structures to control cogs, just like with ordinary inter-cog communications.
The hardware side of things can be tricky for me (I'm just a hobbyist), so offloading that logic onto firmware that can be built and tested separately makes sense. Meanwhile, as others have stated in this thread, Python is an easy language for writing high-level code. Having the REPL command-line is nice for testing and playing around.
This kind of separation also seems like it would be ideal for getting Propeller-based hardware in the classroom. Right out-of-the-box the robot (or whatever) can respond to high-level commands from Python -- with no need to ever use SPIN, PASM, or program an EEPROM. But that option would still be there -- as it should.
Hah, finally you have the thought by yourself. That is exacly what I am begging for, for a while now. Some 32k Blob I can include into my program compiled with fastspin, running its own cog and I can talk FORTH-SNIPPETS to it via some mailboxes to avoid using pins for communication.
A simulated serial port to a TAQOZ console, usable from fastspin. I do the fastspin part, I just need a BLOB to load and a simple mailbox-protocol for read and write the TAQOZ console.
And the BLOB to load at even 0-32k, but better with adaptable start address.
Then TAQOZ extreme edition could hide away in a tiny corner along with any program
just saying...
SORRY OT will move to TACYON thread...
Mike
Thank you. A lot more exciting stuff in the works.
If you saw the Construction Robots, those were done in C and SPIN.
But yeah like 80% of our Coding/Robotics students are in Python.