71–80 of 111 posts
What about using Lua? Sure, different versions of the language are incompatible, but you could target a particular version. Anyone in the future who would be able to compile your C program would also be able to compile the correct version of the Lua interpreter, because it’s written in pure ANSI C.
Using Lua instead of C would gain memory safety, at the expense of performance.
What a pile of garbage. First of all try to compile C code written for 8 bit and 16 bit 80's micros to see how well it has stood the time, without making use of hardware emulators, spoiler alert it won't even compile. Then plenty of programming languages, some of them older than C, are doing great. Anyone with enough money can enjoy NEWP on Unisys ClearPath, a systems programming language almost 10 years older than C…
The real message in Trusting Trust is that the language has been backdoored at the design level, it doesn't need a malicious compiler. A message always has multiple parts, most people miss the important ones and just assume that literal interpretation is the intended one.
I thought this was going to be about concurrency, but it's instead about the risk that programming languages will become obsolete quickly.
I thought this was going to be about bounding the time complexity of your algorithms; I don't know if any language does that yet. I suppose this title has a lot of interpretations.
Earlier quoted context omitted.
With the new research being done in macro-level type systems there's a lot of great reasons to check out lisp again (as a person who loves strongly typed languages)! Type Systems as Macros - https://www.ccs.neu.edu/home/stchang/pubs/ckg-popl2017.pdf Dependent Type Systems as Macros - https://www.ccs.neu.edu/home/stchang/pubs/cbtb-popl2020.pdf It's so cool - especially the bits where they reconstruct each part of the…
I used macro expansion for type checking in Zeta-C [0], the first C compiler for Lisp Machines, in 1983. Didn't write a paper about it, though. Dependent types are certainly interesting -- I'll give this a read. Thanks! [0] http://bitsavers.trailing-edge.com/bits/TI/Explorer/zeta-c/
Earlier quoted context omitted.
> The PC architecture is extremely well-documented in practice (as are alternatives like WebAssembly), and there are going to be emulators for them around for the foreseeable future. Intel has patents on the x86 ISA. Though the basics of the instruction set (386, 486, Pentium) are outside the scope of a patent, it's impossible to write a complete emulator for a chip made within the past 20 years without infringing on…
Nintendo claims the same about emulation of their consoles. It hasn't appeared to be much of a deterrent.
For example on the original Gameboy the thing you have to avoid is using the copyrighted BIOS ROM. But you can avoid that by just initializing the CPU registers and instead starting at the cartridge start address.
Counterpoint: NES games were handwritten in assembler for a long-dead architecture. You couldn't pick a worse development environment for "time safety". The source code for most of the games is lost, too. Yet they remain some of the most portable programs in existence, because of emulation. The PC architecture is extremely well-documented in practice (as are alternatives like WebAssembly), and there are going to be e…
> The PC architecture is extremely well-documented in practice (as are alternatives like WebAssembly), and there are going to be emulators for them around for the foreseeable future. Intel has patents on the x86 ISA. Though the basics of the instruction set (386, 486, Pentium) are outside the scope of a patent, it's impossible to write a complete emulator for a chip made within the past 20 years without infringing on…
Regardless, complete emulators exist today, and Intel hasn't sued anyone over them so far. Intel did threaten to sue Microsoft over Windows-on-ARM's x86 emulator do so a few years ago [1], but that doesn't seem to have gone anywhere, and even if it did, it's unlikely anything would happen to open-source emulators.
[1] https://www.theregister.co.uk/2017/06/09/intel_sends_arm_a_s...
Earlier quoted context omitted.
Nintendo claims the same about emulation of their consoles. It hasn't appeared to be much of a deterrent.
Anyone can claim anything that helps their cause. All you have to do is not implement the emulator using the official developer documentation for the system. For example on the original Gameboy the thing you have to avoid is using the copyrighted BIOS ROM. But you can avoid that by just initializing the CPU registers and instead starting at the cartridge start address.
I actually have had the pleasure of porting a program from a defunct 16-bit language called Actor to C++. It wasn't a huge deal even at around 800 kLOC. All mainstream languages in the future are going to have some combination of structured, functional, and object-oriented programming. Converting is mostly going to be about syntax and libraries. As someone who has worked with C and C++ for living for over 20 years, I…
> Rust is the language that the C++ Committee would make if they could start over. Bjarne has explicitly refuted this opinion.
Sigh. Again this circular logic. And again, this is a fact simply because many people chose to muscle through a lot of problems that C has. It's NOT because C is amazing or anything. Many people chose to muscle through COBOL's problems as well. Is COBOL amazing? Is COBOL giving you time safety?
This is like saying that the Amish have the superior philosophy because there are still Amish communities. They have... a philosophy. They hold it dear. They insist on living by it. That's it. There's nothing more to it. No deeper revelation.
I am not going to engage in the "C vs. Go/Rust" debate apart from saying that clearly many people dislike C and C++ and are looking for alternatives. Which by itself should immediately hint the author that his case is not as universally accepted as he seems to want to make it.