OSDev.org

So I used to think that the C language will be here for quite some time and assembly is slow being phased out. This is based on I working in the field of UEFI BIOS as BIOS-s has been gradually transitioning to C based UEFI from proprietary asm legacy BIOS few years back.

Now coworker of mine approached to me the other day, about in the future, we wont be needing of low-level languages and blubbered something about his friends saying all these new IoT devices are being developed with JSON or something like. I did not quite comprehended his speech about how this will work out but nevertheless left me wondering and very curious about this topic. And I also attempted to veer the conversation about how the server side development i.e. BIOS development will play out.

In the past, I normally thought that whether the extinction of C and asm is stupid as for app developers, obvious choice will be high-level languages but for system development it is different.
Although I am seeing more and more even system development tools and other stuff being done in python.

So I decided to bring this up in this forum.
I am thinking to strike a conversation with that employee again to get a better view of what he said so that I can analyze and put my own view.

Yes, more and more projects are using higher level languages instead of C. But that's not a sign that C is dying- those higher level languages are all implemented with C (or similar).

The only thing that could kill C is another language capable of expressing the same low-level semantics (no runtime, memory layout, etc.). But even then, there is so much existing code written in C, and even more in C++, that it will stick around for decades (see also Fortran, COBOL, still in use today).

You can program anything in Assembly or C even if the specification doesn't foresee it. Open-source assemblers and compilers are always being developed and maintained so even if there's no real access to a CPU architecture, you or anyone can still emulate the execution of a binary, or write programs in those languages without any restriction, so developers just keep doing it.

Currently the problem isn't Assembly or C, but the lack of documentation for the inner workings of file formats and the most modern hardware and software (we would need to make that documentation ourselves again with no detail left out, study many courses for that and make clear which of them all are the most complete, important and clear). The PC platform started greatly explaining how everything worked and that's why DOS was so rich in capabilities despite being 16-bit or 32-bit with Unreal Mode or DPMI (and it still is the base and one of the main keys to understand the PC -and Assembly/C...- with maximum ease). But since Super VGAs, sound cards beyond the Sound Blaster and proprietary printers appeared, everything started to become more and more closed source and nonstandard, the books and courses started to get poorer and much more unspecific to the core of the technology, and almost everyone stopped having enough time to understand, investigate and keep the integrity of that knowledge publicly and freely (not even standard committees), and so we can now see the current poor state of the quality of the applications and of the knowledge of the programmers that generate them without worrying for all of the inner workings.

Languages like C and Assembly are things too simple and fundamental to become obsolete.

There have been things in the past like CPUs that execute Java bytecode natively.

To have something like a CPU that runs JavaScript natively, it would always need to run Assembly microcode internally, so it would only be trying to make a closed-source Assembly instruction set, not making it obsolete.

It would probably be better to simply make the WinAPI, the Linux syscalls, direct I/O, hardware and memory manipulation fully accessible from JavaScript, Java, Python, or any other language, and let it take the place of Assembly as they have always done it. So we could reuse source code and final binaries in any environment, from the OS we use to a webpage attempting to run x86 code...

If not, the compilers and assemblers would need to be written in Java or JavaScript for that architecture.

Anyway, if you can write something in a programming language, you can write it in any other (like running x86 instructions from JavaScript or Python by emulating them).

It's just that Assembly specially is nearest to the digital components of the machine.

Assembly language is actually on the top of the technology, as in the end everything goes down to Assembly programs or hardware microcode. It has important and special

It's not difficult; it's just that you simply need to start from the beginning to understand it, usually at the MS-DOS 8086-386 level. It (Assembly) practically means nothing if you don't understand the inner workings of everything (like executable files, image and resource file formats, multimedia formats, file systems, etc...).

As you can see, it contains algorithms and optimizations that other languages could very rarely teach you clearly but that you can benefit from.

Maybe for user-space it will happen soon, but they won't go obsolete in OSDev.

The UEFI spec fully describes the calling conventions, binary objects, and other interface declarations that you need to interface with firmware on an x86, x86_64, or ARM architecture. The spec gives examples in C, but any language that has the capability to access those interfaces will work.

As long as processors use traditional instruction-based architectures there will be traditional procedural "assembly" languages to interface with them, consisting of little more than mnemonics for instructions. There are plenty of architectures without traditional instructions, and they are programmed differently. If assembly is ever obsolete it will only be because traditional instruction-based architectures are obsolete.