Interesting how C programming has survived that entire time period in the operating system and embedded worlds, although the spread of multicore hardware running lots of threads in parallel has also led to many changes (but even those changes were beginning to be implemented 20 years ago). 20 years from now, C will probably still be a core language in its niche.
My 20 year career is technical debt or deprecated
41–50 of 585 posts
Re: My 20 year career is technical debt or deprecated
#42> printing from the browser was its own fun nightmare Remember Crystal Reports? Oh god, the pain. The pain.
Re: My 20 year career is technical debt or deprecated
#43Re: My 20 year career is technical debt or deprecated
#44Interesting how C programming has survived that entire time period in the operating system and embedded worlds, although the spread of multicore hardware running lots of threads in parallel has also led to many changes (but even those changes were beginning to be implemented 20 years ago). 20 years from now, C will probably still be a core language in its niche.
SQLite's achievement of DO-178B compliance could carry C forward on it's own. Dr. Hipp spent years achieving this, and any reimplementation will suffer his travails, regardless of language safety. DO-178B means that SQLite can be used in avionics. No other major database has reached this level of code quality, as the database written for "programmers who are not yet born."
Re: My 20 year career is technical debt or deprecated
#45I feel like this is heavily connected with the idea of legacy. I grew up in Scotland, and lots of the buildings, culture, etc, have been around for hundreds of years. It would be nice to feel like something I was building would last as long and outlive me. It doesn’t though. Sometimes I think that this is just the nature of software development. Most of the stuff I build is built to solve an immediate business proble…
People are commenting core OS libraries and kernels, but the Space Jam movie website from 96 is still up. I bet the guy that wrote that didn't think it'd be around nearly 20 years later, I hope it never goes down. https://www.spacejam.com/1996/jam.html
Re: My 20 year career is technical debt or deprecated
#46There is plenty of code I've written that's still out there doing useful things. I'm sure some not insignificant parts of Windows, Linux, tools, libraries, browsers etc. etc. are fairly old code that just keeps working .. perhaps with fixes and improvements. Good code lasts a long time. Technical debt is something you are continuously paying "interest" on. Just like any debt, sometimes it's a good thing and sometimes…
Re: My 20 year career is technical debt or deprecated
#47Interesting how C programming has survived that entire time period in the operating system and embedded worlds, although the spread of multicore hardware running lots of threads in parallel has also led to many changes (but even those changes were beginning to be implemented 20 years ago). 20 years from now, C will probably still be a core language in its niche.
SQLite's achievement of DO-178B compliance could carry C forward on it's own. Dr. Hipp spent years achieving this, and any reimplementation will suffer his travails, regardless of language safety. DO-178B means that SQLite can be used in avionics. No other major database has reached this level of code quality, as the database written for "programmers who are not yet born."
Looks like it may not be used exactly in avionics (or maybe most critical parts of avionics), as it isn't certified for the highest levels of DO-178B (and certification for lower levels was done by particular users of SQLite on their own, so the info is not public). Still very impressive.
Re: My 20 year career is technical debt or deprecated
#48Re: My 20 year career is technical debt or deprecated
#49> printing from the browser was its own fun nightmare Remember Crystal Reports? Oh god, the pain. The pain.
I work outside of tech. We still use it.
Re: My 20 year career is technical debt or deprecated
#50Earlier quoted context omitted.
My coworker and I were pair programming some Rust today. We were working on a convenience wrapper whose whole purpose is to reduce boilerplate. So, by its nature there's a lot of internal generic traits, thread safety, etc. He knows Rust well but software design not so much. I know software design well but Rust not so much. My experience can be summed up with: let &mut writer = Writer ::writer::new( connection.clone(…
See as someone who knows Rust fairly well. let &mut -- Essential keywords. writer = -- Duh Writer -- Generic types. Important. ::writer::new -- Boilerplate. (connection.clone()).clone; -- Relentless cloning is a big problem. ... .unwrap -- "Consistent names for optional types," is an issue in Rust. Every module has different jargon for Some(x). Rust certainly isn't perfect. The borrow checker creates... awkwardness,…