embedded programming and real-time often overlap, but they are not the same. You can make a program for real time audio processing for example, and that can be on a laptop. On the other hand, you can program with upython on an ESP32, but I wouldn't trust it to manage the automatic breaks on my car. You can do real time with a GC.
But it's true most real time happens on embedded devices.
Around 2000-2001, I have been writing Perl code for a year or two. That's when I discovered and started using Python. I never went back to Perl after that ;)
Nice overview, and yeah, the future is impossible to accurately predict.
FWIW, I got into Python after I retired in 2013 and used it for hobby projects. Version 2.7, as I recall. Currently on 3.10. I loved it because it was so close to the pseudocode I'd used for decades to rough out ideas on paper. No BEGIN/END, no curly braces. Loved the idea of indentation for block scope. The xkcd cartoon about it is right on the money. And the alt joke on it, yeah, Perl was instantly history once I got into Python.
As an aside, I used to recommend JavaScript as a first language because of its complete object orientation and that all a newbie needed was a browser and a text editor to start. These days I'd be inclined to recommend Python.
I've recently dipped back into JS after many years, and it looks more and more like "the assembler of the browser", in the sense that I feel we're less and less supposed to directly write JS code. Instead, we code in TS, vue.js and so on... that then are compiled into pure JS.
Exactly ! But that's the thing: ASM was never meant to be "pretty" to look at (afaik!), it's meant to represent code for the chip. Same thing for compiled JS: it's not meant to be read by humans anymore, but to be small and fast for the browser.
Yeah, that’s true, generated code is rarely for human consumption. (Ever look at the C code spit out by a cfront translator from C++ input? Yikes!)
Back when I was doing a lot of 8086 (and 6502 and Z80) assembly code, I made it as pretty as possible. Running comments along the side describing each operation — essentially writing the code twice, once for the chip, once for readers. (I even designed an object-oriented framework for assembly.)
Which reminds me, recently I wrote a Python-based software CPU simulator for a made-up CPU for when I feel like messing with assembly again.
embedded programming and real-time often overlap, but they are not the same. You can make a program for real time audio processing for example, and that can be on a laptop. On the other hand, you can program with upython on an ESP32, but I wouldn't trust it to manage the automatic breaks on my car. You can do real time with a GC.
But it's true most real time happens on embedded devices.
"nevertheless, I think it's safe to say we will not see a "real-time" Python tsunami. " => Are you talking about embedded programming?
Around 2000-2001, I have been writing Perl code for a year or two. That's when I discovered and started using Python. I never went back to Perl after that ;)
This article contains nostalgia triggers alright.
Thank you for your insights !
Nice overview, and yeah, the future is impossible to accurately predict.
FWIW, I got into Python after I retired in 2013 and used it for hobby projects. Version 2.7, as I recall. Currently on 3.10. I loved it because it was so close to the pseudocode I'd used for decades to rough out ideas on paper. No BEGIN/END, no curly braces. Loved the idea of indentation for block scope. The xkcd cartoon about it is right on the money. And the alt joke on it, yeah, Perl was instantly history once I got into Python.
As an aside, I used to recommend JavaScript as a first language because of its complete object orientation and that all a newbie needed was a browser and a text editor to start. These days I'd be inclined to recommend Python.
I've recently dipped back into JS after many years, and it looks more and more like "the assembler of the browser", in the sense that I feel we're less and less supposed to directly write JS code. Instead, we code in TS, vue.js and so on... that then are compiled into pure JS.
Usually butt-ugly JS. If not obfuscated JS.
But I still do like ‘plain old’ JS, though I rarely use it anymore. It was fun making active webpages.
Exactly ! But that's the thing: ASM was never meant to be "pretty" to look at (afaik!), it's meant to represent code for the chip. Same thing for compiled JS: it's not meant to be read by humans anymore, but to be small and fast for the browser.
Yeah, that’s true, generated code is rarely for human consumption. (Ever look at the C code spit out by a cfront translator from C++ input? Yikes!)
Back when I was doing a lot of 8086 (and 6502 and Z80) assembly code, I made it as pretty as possible. Running comments along the side describing each operation — essentially writing the code twice, once for the chip, once for readers. (I even designed an object-oriented framework for assembly.)
Which reminds me, recently I wrote a Python-based software CPU simulator for a made-up CPU for when I feel like messing with assembly again.