17
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 09 Jan 2025
17 points (75.8% liked)
Programming
17775 readers
312 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
The essence of your answers is "yes, but...". And the "but" is mostly about how slow Python is in contexts that need to be astonishingly fast.
It depends how complex the hardware is and how much time we're willing to waste.
Technically, when I deploy a Python program to a BBC Microbit, that's (more or less) what is happening. Pure Python code is making every decision, and is interacting directly with all available hardware.
We could still argue semantics - virtually no computer exists that isn't running at least one tiny binary compatibility driver written in C.
I believe the compiled C binary on a BBC Microbit to bootstrap a pure Python OS is incredibly small, but my best guess is that it's still present. The C library for Microbit needed to exist for other languages to use, and Python likes calling C binaries. So I don't imagine anyone has recreated it in pure Python for fun (and slower results).
(Edit: As others have pointed out, I'm talking about MicroPython, which is, itself written in C. The Microbit is so simple it might not use MicroPython, but I can't imagine the BBC Microbit team bothered to reinvent the wheel for this.)
Of course, if you don't mind that the lowest level code has got to be binary, and very few people are crazy enough to create that code with Python, then...
It begs another interesting question: Just how much of an OS can we get away with writing in Python.
And that question is answered both by RedHat Linux and Debian Linux - and the answer is that both are built with an awful lot of Python.
In contrast, Android is mostly Java with ~~lots of C~~ a C Linux kernel. Windows is mostly C# and lots of C. iOS is mostly Objective C and lots of C.
You can have an OS built with almost any language you want, as long as you also want parts of it built in C. (Edit: This is meant to amuse you, not be guidance for what is possible. Today, we love our C code. C didn't always exist, and might someday no longer be our favorite hardware driving language.)
An interesting current development is discussion around rebuilding parts of the Linux Kernel with Rust, which can run just as fast as C. This would effectively cause RedHat, Debian and Android to replace some of their C code with Rust. To date, there's been a lot of interest and discussion and not a lot of (any?) actual funding or work completed.
While I get your point that Python is often not the most appropriate language to write certain parts of an OS, I have to object to the supposed necessity of C. In particular, the bolded claim that an OS not written in C is still going to have C involved.
Such an OS could instead have written its non-native parts using assembly. And while C was intentionally designed to be similar to assembly, it is not synonymous with assembly. OS authors can and do write assembly when even the C language cannot do what they need, and I gave an example of this in my comment.
The primacy of C is not universal, and has a strong dependency on the CPU architecture. Indeed, there's a history of building machines which are intended for a specific high-level language, with Lisp Machines being one of the most complex -- since Lisp still has to be compiled down to some sort of hardware instructions. A modern example would be Java, which defines the programming language as well as the ISA and byte code: embedded Java processors were built, and thus there would have been zero need for C apart from legacy convenience.
Agreed! That's a great point!
I appreciate your clarification. Not everything has to run C. It's just a trend in today's products.
I was attempting to humorously reference Monty Python's Spam sketch, where it seems like everything on the menu has at least a little Spam in it. Every device I could think of, that I've toyed with enough to guess what it has running, is running at least a bit of C.
For an attempt at a counterpoint, I thought of a few devices, like my PineWatch, that run an OS codes entirely written in one language. But... That one language is, of course, C.
Yeah. I think legacy convenience is, indeed, why there's C in so many places, even places it doesn't have to be.
There's so many folks with so much hardware driver expertise in C, and they teach our next generation, so I figure that will continue until something really compelling changes their preference.
I appreciate your point. There are lots of non-C ways to create bytecode. My (amused) point is that we don't seem very fond of any of those methods, today.