Target audience for MicroPython?
Posted: Sun Mar 24, 2019 5:30 pm
What is considered to be the target audience for MicroPython?
I'm thinking about the following categories:
Category A) C developers who are also ideologic pythonistas and are interested in microcontrollers.
Category B) Cheap people, who only want to work with <10$ MCU, and change the world that way.
Category C) Senior/medior/junior python developers who want to get into the world of iot and microcontrollers, and dont mind spending 40 euros to 60 euros on a pybd board. They often also have a soldering iron too somewhere ...
My quess is that all of these categories can be found in the Micopython community. Category A and B are at the heart of most of of the technology, but they are probably largely outnumbered by the people in category C. I think the MicoPython community will thrive if everyone can feel at home.
This means that the MicroPython community should actively target all these people, without neglecting any of these categories.
Why is this important? Since in my view, the micropython community as it currently is, currently is a warm home for category A and B, but not so much for category C.
There are to many cases where 'simple' things actually requires you to build your own firmware. To be clear, building your own firmware for your own board is not for category C people.
This means:
- Everytime support is needed for some new hardware device, and someone has written a driver in C language, the category C people can not use it.
- Many small change requests, actually require C programming ... the C code part that needs the change might not be hard, but then comes with it the responsibility of building the firmware ... Again a no go for the C category.
- Code often can be written more efficiently in C than in Python. This means most drivers/modules/extensions/improvements contain C code, or should contain C code to be the most efficient solution. Argument being: That way we safe bytes, otherwise the smaller boards are left out?
- If you want to learn about the MicroPython codebase, you see that apart from the core and the ports, the biggest asset is the MicorPython-lib repo, that repo is not at home in the MicroPython account (it is forked from an external github location on an external account). That simply is not good for MicroPython. If that user wants to contribute to micropython then why not on micropython account? I simply cannot come up with a reasonable reasoning before that. This need to change!
Look, I love MicroPython. I bought the boards. Made the LEDs blink. Learned the difference between REPL and the raw REPL. Worked out my own development cycle on windows with some extra utils. But the way it is organised right now, I simply see some flaws. Flaws that are most likely easy to fix, if only it would be clear exactly what the target audience is.
Perhaps I'm the only one. Perhaps not .... please leave your feedback and have this debate, and if it is up to me, set the records straight!
I'm thinking about the following categories:
Category A) C developers who are also ideologic pythonistas and are interested in microcontrollers.
Category B) Cheap people, who only want to work with <10$ MCU, and change the world that way.
Category C) Senior/medior/junior python developers who want to get into the world of iot and microcontrollers, and dont mind spending 40 euros to 60 euros on a pybd board. They often also have a soldering iron too somewhere ...
My quess is that all of these categories can be found in the Micopython community. Category A and B are at the heart of most of of the technology, but they are probably largely outnumbered by the people in category C. I think the MicoPython community will thrive if everyone can feel at home.
This means that the MicroPython community should actively target all these people, without neglecting any of these categories.
Why is this important? Since in my view, the micropython community as it currently is, currently is a warm home for category A and B, but not so much for category C.
There are to many cases where 'simple' things actually requires you to build your own firmware. To be clear, building your own firmware for your own board is not for category C people.
This means:
- Everytime support is needed for some new hardware device, and someone has written a driver in C language, the category C people can not use it.
- Many small change requests, actually require C programming ... the C code part that needs the change might not be hard, but then comes with it the responsibility of building the firmware ... Again a no go for the C category.
- Code often can be written more efficiently in C than in Python. This means most drivers/modules/extensions/improvements contain C code, or should contain C code to be the most efficient solution. Argument being: That way we safe bytes, otherwise the smaller boards are left out?
- If you want to learn about the MicroPython codebase, you see that apart from the core and the ports, the biggest asset is the MicorPython-lib repo, that repo is not at home in the MicroPython account (it is forked from an external github location on an external account). That simply is not good for MicroPython. If that user wants to contribute to micropython then why not on micropython account? I simply cannot come up with a reasonable reasoning before that. This need to change!
Look, I love MicroPython. I bought the boards. Made the LEDs blink. Learned the difference between REPL and the raw REPL. Worked out my own development cycle on windows with some extra utils. But the way it is organised right now, I simply see some flaws. Flaws that are most likely easy to fix, if only it would be clear exactly what the target audience is.
Perhaps I'm the only one. Perhaps not .... please leave your feedback and have this debate, and if it is up to me, set the records straight!