3 ms·

I'll just drop this here: [Evaluation of MicroPython as Application Layer Programming Language on CubeSats](http://ieeexplore.ieee.org/document/7948548/ http://

I'll just drop this here: [Evaluation of MicroPython as Application Layer Programming Language on CubeSats](http://ieeexplore.ieee.org/document/7948548/ http://ieeexplore.ieee.org/document/7948548/) I think Python has _everything_ a language needs to be the future of Embedded Systems - except a compiler. You start writing you program using MicroPython as interpreter. You add type hints because it's the right thing to do anyway. Once your prototype is done, you compile to get the speed (cutting execution time, increasing sleep time, increasing battery live). My background is Aerospace Engineering and maybe that's why I can't understand why nobody does a real, AOT, Python compiler. There is Nuitka, but it's a transpiler that extensively uses libpython and isn't fit for microcontrollers (still awesome project, tough). Cython also uses libpython and a different type-annotation system.

DonaldPShimoda 9y ago
For something as critical as aerospace, wouldn't a statically-typed language be a better choice anyway? I love Python, but I don't think it has a place where rigor and validation are concerned. Though I suppose if you were writing a compiler, you could require and enforce type hints... but then any calls into the standard library will just have to be trusted. I dunno. It seems tricky.
- turbinerneiter 9y ago
  That's why I'd enforce type-hints. The whole story with these critical systems is tricky. At the one hand, they want to have formal verification. Academia really loves stuff like Haskell for that. There is Ada which was designed with critical systems in mind. On the other hand, there is a lot of C and C++ everywhere. On microcontrollers, no matter how much you love Haskell, Ada or Rust, there might not even be a compiler and probably no HAL. And in the end, all of those languages focus on the machine and the math. A mathematical prove of the correctness of your software is nice, but readable code is too. And the formal verification doesn't save you from making wrong design choices. It doesn't check your logic. No language or tool can do that. But what I believe a language can do for you is help you express your thoughts in such an simple, structured and readable way that the cognitive load is reduced to a minimum, freeing up thought-power to check your logic. A lot of the failures in space that were caused by software weren't actually programming errors like the overflows that allow us to hack everything. There was a Mars Orbiter that crashed because the data was in the wrong format - still the types matched. A lander crashed because they forgot to put in logic to handle invalid sensor data: a broken sensor in the landing led triggered the 'touch-down' signal, the lander believed it landed and cut the chute. Except it really wasn't even close to ground. Using a bit of hyperbole, there is formal verification in Academia on the one side, and people forgetting to design robust logic while trying to figure out pointers on a microcontroller that can only be programmed in C on the other. Static Python. That's my proposal to save the next mission :)
  - na85 9y ago
    I'm failing to see how static Python addresses any of the concerns you listed. In fact you seem to defeat your own argument when you state: >A lot of the failures in space that were caused by software weren't actually programming errors... Indeed this is true. I work in aerospace (though not in a software development role) and I can tell you a lot of shops are using C/C++ for embedded applications with strict style guides to attempt to mitigate the flaws in those languages. I think the fact that many aerospace-related problems aren't due to programming errors says that current practices are working.
  - nikofeyn 9y ago
    but all that seems to be silly. why try to force feed patches to make python something it was in no way designed for? it seems like the completely wrong approach from a design point of view. and your dismissal of the power of type checking systems seems strange. seems weird to say that it doesn't really help when python has nothing of the sort. even a "static python" wouldn't reach the power of some existing systems. even for dynamic languages, python is behind the times for things like that. for example, look at racket versus python. and then there's languages like idris, which go well beyond what even haskell can do. something like idris would be wonderful for critical embedded systems. and if you really want flexibility and a dynamic language, python seems well below lisp/scheme. i would love to see racket and ML-based languages to move towards embedded development over something like python. finally, both lisps/schemes and ML-based languages are very readable. many would argue they are more readable than a language like python. so your implication that type systems incur a readability penalty isn't generally accurate. > But what I believe a language can do for you is help you express your thoughts in such an simple, structured and readable way that the cognitive load is reduced to a minimum, freeing up thought-power to check your logic. basically what i am getting at is that a language like racket or idris fulfill this requirement very strongly, even moreso than python. and additionally, they come with advanced language features that no version of python will ever likely touch on.
jokoon 9y ago
I agree with you, although I think it makes more sense to have something like c, with the python indent and all the nice things it has, lists, dict, etc. A static python is complicated because types would make your code much longer and less readable...
khedoros1 9y ago
> My background is Aerospace Engineering and maybe that's why I can't understand why nobody does a real, AOT, Python compiler. Python's a very dynamic language; a lot of things are inherently determined at run-time. You could build a less-dynamic language (and enforce type annotations and all that), but then that's hard to call "Python", right? At least we'd be free of things like this: #Scans the module for methods starting with "do_", and puts their names in a list available_actions = [ method[3:].lower() for method in dir(this_module) if callable(getattr(this_module, method)) and method[:3] == 'do_' ]
bsder 9y ago
> I think Python has _everything_ a language needs to be the future of Embedded Systems - except a compiler. My biggest beefs in this space are (not limited to Python): 1) So, far, every scripting language I have used is far too resource hungry for deployment (2-4K RAM/16K Flash or less). 2) No scripting language gives me good concurrency primitives out of the box. 3) Very few embedded languages are familiar enough to coders that they won't scream if they have to code in it. Forth is right out. Lua is a loser because of 1-based indexing (sorry, your environment is C--it's unfair, but I'm not going to bend my brain to undo 0-based indexing habits for anybody nowadays). Lisp and Tcl are marginal but are probably acceptable nowadays since enough people have experience (and Tcl is still one of the standard EE tool embedded languages). 4) No embedded language I know lets me connect an RS-232 terminal on the embedded device, inspect registers and call some functions, write some code, and then compile it to bytecode in flash when I'm done. I would kill for this in order to inspect state and find Heinsenbugs in the field.
- etiene 9y ago
  3) Sounds like a very lazy excuse. Many languages used to be 1-indexed and many still are.
  - bsder 9y ago
    Many is technically correct, but is now a very low number. https://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29#Array_system_cross-reference_list https://en.wikipedia.org/wiki/Comparison_of_programming_lang... Julia(2012) appears to be the only language created in the last 20 years that is 1-based. The next one is Lua in 1993(!). For better or worse, at this point, the indexing debate is over and Lua is sadly on the wrong side.

DonaldPShimoda 9y ago

For something as critical as aerospace, wouldn't a statically-typed language be a better choice anyway? I love Python, but I don't think it has a place where rigor and validation are concerned. Though I suppose if you were writing a compiler, you could require and enforce type hints... but then any calls into the standard library will just have to be trusted. I dunno. It seems tricky.

turbinerneiter 9y ago
That's why I'd enforce type-hints. The whole story with these critical systems is tricky. At the one hand, they want to have formal verification. Academia really loves stuff like Haskell for that. There is Ada which was designed with critical systems in mind. On the other hand, there is a lot of C and C++ everywhere. On microcontrollers, no matter how much you love Haskell, Ada or Rust, there might not even be a compiler and probably no HAL. And in the end, all of those languages focus on the machine and the math. A mathematical prove of the correctness of your software is nice, but readable code is too. And the formal verification doesn't save you from making wrong design choices. It doesn't check your logic. No language or tool can do that. But what I believe a language can do for you is help you express your thoughts in such an simple, structured and readable way that the cognitive load is reduced to a minimum, freeing up thought-power to check your logic. A lot of the failures in space that were caused by software weren't actually programming errors like the overflows that allow us to hack everything. There was a Mars Orbiter that crashed because the data was in the wrong format - still the types matched. A lander crashed because they forgot to put in logic to handle invalid sensor data: a broken sensor in the landing led triggered the 'touch-down' signal, the lander believed it landed and cut the chute. Except it really wasn't even close to ground. Using a bit of hyperbole, there is formal verification in Academia on the one side, and people forgetting to design robust logic while trying to figure out pointers on a microcontroller that can only be programmed in C on the other. Static Python. That's my proposal to save the next mission :)
- na85 9y ago
  I'm failing to see how static Python addresses any of the concerns you listed. In fact you seem to defeat your own argument when you state: >A lot of the failures in space that were caused by software weren't actually programming errors... Indeed this is true. I work in aerospace (though not in a software development role) and I can tell you a lot of shops are using C/C++ for embedded applications with strict style guides to attempt to mitigate the flaws in those languages. I think the fact that many aerospace-related problems aren't due to programming errors says that current practices are working.
- nikofeyn 9y ago
  but all that seems to be silly. why try to force feed patches to make python something it was in no way designed for? it seems like the completely wrong approach from a design point of view. and your dismissal of the power of type checking systems seems strange. seems weird to say that it doesn't really help when python has nothing of the sort. even a "static python" wouldn't reach the power of some existing systems. even for dynamic languages, python is behind the times for things like that. for example, look at racket versus python. and then there's languages like idris, which go well beyond what even haskell can do. something like idris would be wonderful for critical embedded systems. and if you really want flexibility and a dynamic language, python seems well below lisp/scheme. i would love to see racket and ML-based languages to move towards embedded development over something like python. finally, both lisps/schemes and ML-based languages are very readable. many would argue they are more readable than a language like python. so your implication that type systems incur a readability penalty isn't generally accurate. > But what I believe a language can do for you is help you express your thoughts in such an simple, structured and readable way that the cognitive load is reduced to a minimum, freeing up thought-power to check your logic. basically what i am getting at is that a language like racket or idris fulfill this requirement very strongly, even moreso than python. and additionally, they come with advanced language features that no version of python will ever likely touch on.

jokoon 9y ago

I agree with you, although I think it makes more sense to have something like c, with the python indent and all the nice things it has, lists, dict, etc. A static python is complicated because types would make your code much longer and less readable...

khedoros1 9y ago

> My background is Aerospace Engineering and maybe that's why I can't understand why nobody does a real, AOT, Python compiler. Python's a very dynamic language; a lot of things are inherently determined at run-time. You could build a less-dynamic language (and enforce type annotations and all that), but then that's hard to call "Python", right? At least we'd be free of things like this: #Scans the module for methods starting with "do_", and puts their names in a list available_actions = [ method[3:].lower() for method in dir(this_module) if callable(getattr(this_module, method)) and method[:3] == 'do_' ]

bsder 9y ago

> I think Python has _everything_ a language needs to be the future of Embedded Systems - except a compiler. My biggest beefs in this space are (not limited to Python): 1) So, far, every scripting language I have used is far too resource hungry for deployment (2-4K RAM/16K Flash or less). 2) No scripting language gives me good concurrency primitives out of the box. 3) Very few embedded languages are familiar enough to coders that they won't scream if they have to code in it. Forth is right out. Lua is a loser because of 1-based indexing (sorry, your environment is C--it's unfair, but I'm not going to bend my brain to undo 0-based indexing habits for anybody nowadays). Lisp and Tcl are marginal but are probably acceptable nowadays since enough people have experience (and Tcl is still one of the standard EE tool embedded languages). 4) No embedded language I know lets me connect an RS-232 terminal on the embedded device, inspect registers and call some functions, write some code, and then compile it to bytecode in flash when I'm done. I would kill for this in order to inspect state and find Heinsenbugs in the field.

etiene 9y ago
3) Sounds like a very lazy excuse. Many languages used to be 1-indexed and many still are.
- bsder 9y ago
  Many is technically correct, but is now a very low number. https://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29#Array_system_cross-reference_list https://en.wikipedia.org/wiki/Comparison_of_programming_lang... Julia(2012) appears to be the only language created in the last 20 years that is 1-based. The next one is Lua in 1993(!). For better or worse, at this point, the indexing debate is over and Lua is sadly on the wrong side.