21–30 of 111 posts
I recall once, not quite 20 years ago, porting a large CL program from a 32-bit implementation to one of the then-new 64-bit Lisps. Someone who didn't know CL thought that would be a hellish job, but it turned out to be quite straightforward.
TL;DR: It's better to have buffer overflows and use-after-free bugs that still work in 50 years than to have secure code you may need to migrate.
I think you're being sarcastic? But I also think the article genuinely believes that's true. In 50 years there will be C programmers who know how to fix a buffer overflow, compile, and run your program. Conversely, a program written in a language and dependent on a package repository that only existed from 2017-2024 will likely never find an academic willing to invest the thousands of hours in learning that legacy co…
It's actually the assumptions around longevity that need to be examined. Software is not like etching perfect museum-pieces. It is the union of the world that defines software's context, and since that will always change, we'll have to continue to write and re-write software to ensure the match is appropriate
I don't have a good intuition for this. I think everyone has anecdotes of both sides; projects that were supposed to be throw-away code that lived on for decades and everyone is familiar with changing scope and requirements requiring changes to otherwise perfectly fine code.
Put another way, the longevity of code is only important to the extent that it still fulfills the needs of its users. Otherwise, as always if you can get away with it, the best code is no code.
It's actually the assumptions around longevity that need to be examined. Software is not like etching perfect museum-pieces. It is the union of the world that defines software's context, and since that will always change, we'll have to continue to write and re-write software to ensure the match is appropriate
It's actually the assumptions around longevity that need to be examined. Software is not like etching perfect museum-pieces. It is the union of the world that defines software's context, and since that will always change, we'll have to continue to write and re-write software to ensure the match is appropriate
I believe this is the most coherent counterargument to the article's point. Given how often software is rewritten and requirements evolve, how much does it make sense to target longevity? And when I say rewritten I don't just mean big-bang rewrites-from-scratch, I also include Ship of Theseus rewrites where over time everything gets rewritten one piece at a time. I don't have a good intuition for this. I think everyo…
Shipping updates used to mean literally shipping new hardware to be installed.
We’ve treated software like a literal thing to meet boxed software business sales expectations. Back in the day people sold things.
There are a number of different ways to build and distribute software that achieve the same level of results. We’ve just stuck to using the ones that traditional business models are willing to fund.
Apparently curve fitting for ephemeral finance growth is achieving literal economic gains. Or something. The epistemology of economics has diverged from the ontology, become less about material goods, more about information organization which is harder to value given as we say here, we curve away too fast and have to rewrite it, no one knows
There's always Common Lisp. Still portable 35 years on. I recall once, not quite 20 years ago, porting a large CL program from a 32-bit implementation to one of the then-new 64-bit Lisps. Someone who didn't know CL thought that would be a hellish job, but it turned out to be quite straightforward.
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 type system and show how each feature they add contributes to the power/capability of it. :D
The knowledge needed to compile a C program into executable code will never die, as long as there is a human race.
C is only about 50 years old. I'd say it remains to be seen (not in our lifetime).
I use Pascal for all my projects because it has memory safe strings and arrays. Almost all buffer overflows and security bugs could be solved by rewriting all software in Pascal. Everytime a software crashes, you should say, it crashed, because it was not written in Pascal I just spend two hours modifying my xml parser to load files that have a doctype with inline declarations. Never needed to load an xml file with a…
Earlier quoted context omitted.
Lots of C code have already bitrotted because APIs it depends on have been abandoned. Resurrecting it isn't just a matter of compiling the code, but recreating the environment it ran in.
That was before storage become abundant and cheap; from a source code storage perspective. It will not become more expensive. Nowadays storage capacity is developed to store video - this is really the only thing that needs a lot of new storage capacity. Every line of sourcecode written by every programmer ever is a fart in the wind compared to what's being uploaded to Youtube in the next 60 seconds.
As someone who has worked with C and C++ for living for over 20 years, I wouldn't think twice about picking either Go or Rust if I were to start again. Go gives you the fast edit/compile/test loop of an interpreted language with the runtime speed of a compiled language. Rust is the language that the C++ Committee would make if they could start over.
That being said, Go will never take over the C, C++, and Rust niche. Going to and from Go-land and C-land is too expensive. Google has no interest in stepping behind libraries that aren't internet servers. Go will live a long life as a great environment to port your Python, Ruby, and other bloated server languages. It just will never be the next language to write a web browser.
Rust is amazing though. I see this as the programming language of the future until the U.S. Government slams down the hammer and forces everyone to use DOD-approved Ada.