Conversation

Notices

1. Embed this notice
   Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 24-Dec-2024 21:54:09 JST Rich Felker

   C compilers: we gave you a 30 year grace period to fix your invalid code, and now finally it's erroring out.

   Python: version N says "use method foo", version N+0.01 says "no, foo is gone, now it's called fooo because that's a more correct spelling".

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 24-Dec-2024 22:20:01 JST Rich Felker

     in reply to

     Like seriously, if you're making a programming language, any program written *correctly, to the spec* in year Y should still run unmodified in year Y+25. If you can't guarantee that, your language is a joke.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 24-Dec-2024 22:28:52 JST Rich Felker

     in reply to

     • Steve Canon

     @steve This is kinda true but an exaggeration. C is a fairly simple language without too many footguns, and if you're not trying to show off living on the edge of the rules, they're not hard to avoid.

     C code which hits them is mostly written by smartasses trying to do "portable asm", premature optimization, etc.

   • Embed this notice
     Steve Canon (steve@discuss.systems)'s status on Tuesday, 24-Dec-2024 22:28:53 JST Steve Canon

     in reply to

     @dalias C and C++ solve this by littering the spec with so many landmines that no one can write a “correct to the spec” program. Newer languages solve it by simply not having a spec.

     Fortran and COBOL remain undefeated as the only widely-used serious languages.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 24-Dec-2024 22:37:06 JST Rich Felker

     in reply to

     • Steve Canon

     @steve It's still worth something that the degree to which you might have to fix stuff is proportional to how nonconforming your code accidentally was. As opposed to being at random whim of someone who thought changing the name of something would make the language prettier.

   • Embed this notice
     Steve Canon (steve@discuss.systems)'s status on Tuesday, 24-Dec-2024 22:37:07 JST Steve Canon

     in reply to

     @dalias yes, I’m exaggerating, it is _possible_ to write conforming C programs. But still we live in a world where only a very small fraction of the C code written actually is strictly conforming.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Tuesday, 24-Dec-2024 22:47:27 JST Rich Felker

     in reply to

     • jn RA, RB (primary opcode 31)

     @jn *sigh* I thought they'd finally fixed that.

   • Embed this notice
     jn RA, RB (primary opcode 31) (jn@boopsnoot.de)'s status on Tuesday, 24-Dec-2024 22:47:28 JST jn RA, RB (primary opcode 31)

     in reply to

     @dalias a bit of a different issue, but it reminds me that the rust 'libc' crate it still stuck on musl 1.1, i.e. before the big y2038 proofing

   • Embed this notice
     Wanja (muvlon@hachyderm.io)'s status on Wednesday, 25-Dec-2024 08:13:24 JST Wanja

     in reply to

     @dalias Yes, and same for operating systems. OpenBSD regularly has breaking API (not just ABI!) changes, potentially requiring 3rd party software to be ported to every new release.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 25-Dec-2024 11:13:39 JST Rich Felker

     in reply to

     • Wanja

     @muvlon And just ignores the standards when Theo thinks "hey, a function by that name should do something different"... 🤬