I started with 6510 assembly. I have 25 year old delphi apps. But nodejs and go hypes are also 10+ years old. If you haven't learned, maybe you are stuck on purpose.
My 20 year career is technical debt or deprecated
51–60 of 585 posts
Re: My 20 year career is technical debt or deprecated
#52Earlier quoted context omitted.
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."
That's impressive! Is it a specific version and what features or is it a subset?
The certification was attained ~ 2008.
All versions of SQLite released after that time are run through the test harness that maintains this standard.
Re: My 20 year career is technical debt or deprecated
#53a thing most of these have in common is that they're proprietary, so the users are dependent on the companies that own them for enhancements, bug fixes, and ports to new platforms. this is a recipe for wasting your time
visual basic, asp, coldfusion, foxpro, activex, flash, and silverlight, windows ce, asp.net, webforms? proprietary, proprietary, proprietary, proprietary, proprietary, proprietary, proprietary, and proprietary
and mostly pretty dead as a result
how about the non-proprietary things in the list? html, css, js, fortran, java, ruby, and rails are all just about as alive as they were 10 or 20 years ago, if not more so, except that rails didn't exist then
the exceptions are perl, objective-c, and the js frameworks. perl, ember, and backbone aren't going to disappear anytime soon but they will likely continue to stagnate. but unlike silverlight or windows ce, you can probably run your perl and backbone and angular and react and swift code 10 or 20 or 30 years from now on whatever platform people like then
unless the platform is centrally controlled by an owner who forbids it, so try to avoid platforms like that
(java applets were already dead 20 years ago, and soap sucked from the beginning, so these examples are out of place)
there is certain knowledge with a very limited half-life. but hopefully you aren't spending most of your time learning react apis or wasm instructions or editor keystrokes or chromium bugs, but rather general principles that transfer across domains. algorithms, reasoning, type theory, math, writing skills, hierarchical decomposition, scientific debugging, generative testing, heuristic search, that kind of thing. a lot of that stuff goes back before computing
and most code has an even shorter lifespan than the knowledge we use to build it. which is as it should be: most code is written to solve a problem that won't last decades or even years, but it's still profitable for companies to have it written. modifying a big system is harder than modifying a small one, so it's better to maintain just the code you need for today's problems. writing code and throwing it away is mostly fine
still, i've spent my career on free-software tools, and their half-life seems to be a lot longer, about 25 years. i reviewed some of the stuff i'm using right now in a comment on here 10 days ago, https://news.ycombinator.com/item?id=35829663
i know a guy whose preferred programming editor is ex. the non-full-screen version of vi
Re: My 20 year career is technical debt or deprecated
#54I 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…
I'd say something like TeX might be a software cathedral, and even that one isn't going to last much longer than Knuth himself (almost everyone today doesn't run TeX, they run a compatible software platform, some are even entirely different). But even a Cathedral changes over time, and your work may not last; but all human work is a shrill scream against the eternal void - all will be lost in time, like tears in rain…
pretty sure most latex papers and chapters are formatted with tex82, though translated from pascal to c
Re: My 20 year career is technical debt or deprecated
#55Earlier quoted context omitted.
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."
This got me curious, so I searched for some info and found this thread on HN: https://news.ycombinator.com/item?id=18039213 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.
It was Rockwell-Collins in Cedar Rapids, Iowa that first urged Dr. Hipp to pursue this certification.
They would not have done so if they had no plans or intention to deploy it.
I would be surprised if they were not able to do so.
Re: My 20 year career is technical debt or deprecated
#56Earlier quoted context omitted.
I'd say something like TeX might be a software cathedral, and even that one isn't going to last much longer than Knuth himself (almost everyone today doesn't run TeX, they run a compatible software platform, some are even entirely different). But even a Cathedral changes over time, and your work may not last; but all human work is a shrill scream against the eternal void - all will be lost in time, like tears in rain…
pretty sure most latex papers and chapters are formatted with tex82, though translated from pascal to c
Most people use pdfLaTeX or XeTeX, which may have some basis in the original Tex82 but have since moved on, at least in code.
Re: My 20 year career is technical debt or deprecated
#57> printing from the browser was its own fun nightmare Remember Crystal Reports? Oh god, the pain. The pain.
I got hired for a job specifically because I knew crystal reports! I don't miss that.
I got hired for a job because I was willing to learn to program on OpenVMS. I'd never heard of it, but asked the interviewer "it's a lot like UNIX, right?". He looked at me, waited 5 or 10 seconds, and said "no." Oh well, I passed their C and SQL tests, they weren't going to let me go that easily.
I'll probably retire when they finally retire it, but at the rate they're going I may beat them to it. I won't miss it, but I won't regret it either.
Re: My 20 year career is technical debt or deprecated
#58I guess I was lucky: I started 15 years ago doing web development using python and django on linux, which is still my toolset today ;)
Re: My 20 year career is technical debt or deprecated
#59I 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…
100% agree.
But I like to think that ideas and solutions and products can be legacies.
It's semi-uncommon to write code that legitimately lasts 5+ years.
But it's very common to work on projects/products/companies that last 15+ years.
And I have to be content with that.
Re: My 20 year career is technical debt or deprecated
#60Absolutely, that's why I'm trying to move to management, to leverage on my non tech experience. I'm 40 and younger colleagues are faster learner if not already "expert" on new stuff. I often have to "forget" what and how I learned old things to learn new techs, the effort can easily double.