Barnacles can cut you pretty badly if you're not aware of them, and they have a habit of reproducing. When you have a large colony on the hull of your vessel they impose a nontrivial amount of drag.
(I'm more committed to the bit than this position though, it's a judgement call that an engineer must make relative to the requirements and resources available.)
There 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 it's a bad thing.
in my experience, if there's no will or budget for a rewrite, it gets virtualized, locked away behind a firewall/corporate network with a restricted set of users, and will basically run forever as long as the ISA and virtual storage is supported by emulation and the business process still exists and is able to support the infra/people involved.
think of it like a zero coupon 100 year bond in technical debt issuance underwritten by the central bank (corporate hq). and highly liquid in the sense that a virtual image is easy to move around.
the good part is it just gets faster and takes up less % resources as hardware improves, and forever-bugs are usually worked around and documented by the people pushing the buttons.
I got a new laptop recently and I hadn't used Windows in probably a decade. It came with windows 11 and I saw so many old interfaces under the hood while exploring that it made me laugh a few times.
The fun thing is that, until CS slows down, stuff gets better so fast that we get to reimplement the same thing, but 10x better every 5 years or so.
First I wrote single threaded code code with automatic memory management, then single threaded synchronous with manual memory management, then synchronous multi-threaded, then async, and then async lock free.
Now I am writing async lock free, and the compiler is helping me prove it is data-race-free and memory safe.
Each time I rewrite this stuff, someone hands me 6-7 figures. This is awesome.
Right, I worked on a async non-blocking project in C++ in the 90s. It was a lot simpler than any modern project, no cloud, no yaml, no containers, no fancy security. Sure it didn't have a pretty web interface but was great software.
You could've cited Slack or Discord. Teams is an anomaly in horrible software quality that *only* Microsoft can manage to produce (also see OneNote (but DON'T see VS Code -- that's somehow really efficient despite being Electron!)).
For a lot of this stuff 20 years is basically new in my book. MPI dates back at least 30 years and I still sometimes wonder if the only reason we don't use it anymore is because nobody wants to deal with C. I spend too much time these days watching technology like Spark make things slower rather than faster because nowadays the Java platform (not to mention containerization) is becoming an increasingly efficient way to splat oneself into the memory wall.
what exactly is 10x better than 5 years ago? the technology gets better but the outcome gets worse somehow.
most of the programs i use (besides the browser) are 20-50 years old (paste, cut, xterm, grep, emacs etc), almost any new thing i try is horribly slow (slack, whatsapp etc, the mac terminal app, even the mail app is slow compared to mutt)
open a web page on a computer without adblock and look at what we have built
> Now I am writing async lock free, and the compiler is helping me prove it is data-race-free and memory safe.
I am writing async lock free code as well, but which compiler is helping you? Rust? As far as I know, it's cutting edge research to figure out a type system that fixes this for you. But maybe i'm not up to date.
> stuff gets better so fast that we get to reimplement the same thing
So you are leaving the API in-tact and just change the implementation with new techniques? Or even better, you just rewrite low-level libraries you are using? Sounds like the ideal job to me.
Unfortunately users are not seeing 10x better performance with the average application. A bit of the curse of more resources leads to using more resources wastefully.
When I look at team sizes for '80s and '90s programs, and how fast those teams worked, and consider what I'd expect to be the team size for a modern program tackling the exact same features and how long I'd expect development to take, it also makes me wonder just how much these supposed productivity improvements—which are promoted as where these benefits are being realized, since they're plainly not showing up in program & system performance for the user—actually, like, exist.
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.
Is it interesting? Somewhere along the chain someone needs to know assembly. Either hand crafting it or some compiler exists for some language that is one step removed. At this level my feeling is that there is less desire to constantly change tools.
I think C and its direct descendants will slowly fade away over the next 20 years as new developers want to get away from the legacy of language specifications that span existing codebases. There are so many sharp edges in C that have automatic fixes/detections/etc in newer languages and don’t get me started about multiprocessing complexity in C.
It will fade away the same way COBOL faded away, which is to say that it will still be at the core of a great many critical systems in 50 years, even if new critical systems aren't written in it.
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<T>::writer::new(connection.clone()).clone();
// TODO ???
writer.write(*data.clone()).unwrap();
Meanwhile in C++ I'm like
if (!write(connection, data, data_len))
{
return false;
}
let &mut -- Essential keywords.
writer = -- Duh
Writer<T> -- 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, that requires .clone hacks to solve.
Flip-side is, I'm coding in CMake right now. I've had to create multiple bash scripts for manually deleting my build files and general day to day.
I feel like those clones don't get enough attention. At a glance, you don't really know what those clones are doing. Is it allocating, is just increasing reference counter? Makes code hard to understand
clone() makes an immutable, deep copy/recursive copy of the original data structure.
clone() itself makes perfect sense. Why the programmer needed those clones... is a legitimate issue with Rust.
In my experience so far, it's usually to hack around an interaction between the borrow checker and the output of a function constructed using dot syntax.
Asking as someone who has tried learning Rust but didn't get very far, doesn't unwrap essentially mean "this might panic but I don't care to implement error handling here"?
I’m not sure why the API wouldn’t implement Write for connection so you could do:
connection.write_all(data)
Where data could be an argument that impls ToOwned or Into so that it would either use the object you pass in (if by value) or implicitly clone it (if by reference).
Basically this looks more like an API design problem than a limitation of the language.
My example wasn't meant to be taken so literally. I'd say there's some truth to there being an API design problem to untangle, though. It's a relatively new language in a repo with dozens of contributors all frantically trying to get their work done. I'm just the salty senior engineer that's getting sucked in before wheels fly off. Stepping back even further, I think there was perhaps an overeager desire to use multithreading, both unnecessarily and at the wrong level of abstraction. That lead to a lot of lifetime management complexity at the lowest, deepest level. Then, folk slapped on progressively higher level abstractions, applying band-aids as they went rather than refactoring the lower layers.
I'm sorry but that doesn't look normal. Code smells with all those clone()'s and unwrap(). It allocates a new Writer and then clones it?! "let &mut writer=" isn't right. The new'ed Writer is a struct; why is there a need to get a reference to it? Why is data being clone() and then immediately de-referenced to create a copy of the clone?
A normal writer API would look like one of the variations:
Writer<T>::new(&connection).write(&data)
Writer<T>::new(&mut connection).write(&data) // if conn needs changes.
It's rare to unwrap(), which can cause a crash at runtime, but to handle the result. E.g. to write more data if the previous write is successful.
let mut writer = Writer<T>::new(&connection);
let mut written_len = 0;
written_len += writer.write(&data1)? // ? returns the err if it's Err
written_len += writer.write(&data2)? // or unwrap the result value
written_len += writer.write(&data3)?
As you can see, "writer.write(&data1)?" is equivalent to the C++ version.
You're interpreting my example more literally than I intended. :-) What does it say about the language, when parody is indistinguishable from poorly written code?
The actual code we were working on involved functions returning closures with mutable captures, so the borrow checker was especially persnickety.
To be blunt, the code you copied out as example is crap. I don't know what you expect how it's being interpreted. It says more about the programmer than the language.
> functions returning closures with mutable captures
That sounds like another bad design, but to each his own.
My apologies if I hit a nerve. I'm just trying to have fun chatting about the foibles of contemporary software development with fellow nerds on HN. I expected something like urthor's post, where they seemed to appreciate the levity of my comment, and responded with some interesting insights. I also appreciated the follow up comment raising a serious concern about the prevalence of cloning and resulting confusion in realistic codebases.
> let &mut writer = Writer<T>::writer::new(connection.clone()).clone(); // TODO ??? writer.write(data.clone()).unwrap();
It's not difficult to arrive at the caricature of baroque generic code if you combine lack of knowledge with miscommunication. The knowledgeable coworker should be aware that a writable object implements the Write trait, and know, or find out, the signature of the Write::write() method. Even fully generic, a function accepting a connection and returning the result of writing a block of data is not too gnarly:
No unwraps, no clones. Because they're not necessary here. But someone has to know the language and the idioms. Even your "easy" C++ code depends on knowing that write() returns zero on success, and that integers can play the role of booleans in conditions.*
Eh, zero on failure, I suppose. The real write(2) syscall returns -1 on failure, and a non-negative value is the number of bytes actually written. But the general point still stands.
When I wrote my hypothetical example, I was imagining the return type to be a bool. My apologies for overloading "write", a more representative example function name would have been something like "FooWrite". I appreciate your follow-up!
I totally agree with you that folk writing code need to understand the semantics of what they're building on top of. Humans and now AI models have a great capacity for generating tons source code without understanding the semantics, though.
is there a chance that someday unwrap will be visible to the typesystem and we can safely proclaim that "neither this library not its dependencies contain an unwrap"?
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.
Yep. C and SQL are the two languages I've used my entire career (30+ years). I still use SQL almost every day, C not as much. Shell scripts and unix utilities are in there as well as daily-use tools.
It is, relatively speaking, far easier to write a C compiler[1] than one for any other higher-level language, and the language lends itself to low-level tasks without needing to use Asm.
[1] There have been multiple articles on HN where a single person has written a C compiler.
lots of compilers have been written by a single person, including compilers for c++, d, turbo pascal, forth, scheme, ml, haskell, ancient lisp, and so on. craig burley got g77 to the point of compiling useful fortran programs before other people got interested. i think graydon wrote the first versions of the rust compiler himself too
it's probably always better to do it with someone else, because you get better ideas and faster debugging, but pretty much all hlls are possible for a single person to implement
Brian Kenighan wistfully removed the lex/yacc parser in the OneTrueAwk many years ago, and replaced it with a custom parser (I believe for performance reasons). The OneTrueAwk remains the standard awk in BSD, renewed, but not replaced. I don't think it's going anywhere.
The POSIX standards, flawed as they may be, have incredible staying power. These standards run our phones and embedded, supercomputers, current Apple workstations, game consoles, and are significant in many other places.
Microsoft itself implemented POSIX in Windows from the beginning (likely recognizing it's importance as the former vendor of Xenix), and while this has waxed and waned, running the "wsl.exe -l -o" command on modern Windows will catalog Ubuntu, Kali, and Oracle Linux that are not Linux, but serviced by the Windows kernel's POSIX layer under WSL1.
Applications that implement or greatly enhance POSIX have staying power.
Those who seek code longevity would do well to study it.
Counterpoint: POSIX is increasingly a creaky anachronism required to support a legacy base of old Unix software. Every modern Unix-derivative OS replaces or significantly augments core POSIX functionality with something that works better for modern hardware and software needs, or suffers in some areas if they don’t/can’t.
But is WSL1 supported by the POSIX layer? I don't think so. I think it uses some of the mechanisms built for the POSIX layer but I think it is a separate "personality".
Alright, let me be more clear: WSL1 is NOT the POSIX personality of Windows NT. The POSIX personality was very dumb and minimal. WSL1 is NOT that. It is a different thing. And the POSIX personality doesn't even exist anymore.
Look at the wiki for Mica. The goal was for a whole implementation of Ultrix alongside of VMS.
It fell apart in trying to allow both sets of system calls to be used by a single process. This failure is likely a huge reason for Windows NT, as it led to cancelation.
I used Utrix on a Decstation 240 in college.
"However, it proved to be impossible to provide both full ULTRIX and full VMS compatibility to the same application at the same time, and Digital scrapped this plan in favour of having a separate Unix operating system based on OSF/1 (this was variously referred to as PRISM ULTRIX or OZIX)."
I had known for some time that VAX/VMS was strikingly similar to Windows NT, but I learned a few days ago that the failed Mica project introduced a POSIX interface.
It can be argued the other way round. POSIX is tech debt and exists in modern machines so widely mostly because there happen to be free implementations of it. My experience from interviewing has been that a remarkably large number of developers actually never interact with POSIX directly these days: they never work with files and never open a socket or fork process trees. They certainly never use UNIX-adjacent stuff like X. Instead they interact with APIs layered on top like NodeJS, Java, C#, Android, Swift, HTML. None of which bears much resemblance to POSIX. Like, if you read about how to work with the network in iOS or Android you won't be directed to POSIX APIs.
I am somewhat amazed at the list of tech from that article, it's like he has a magical knack for picking dead ends.
C was the 2nd language I learned and I'm still using it. The big surprise for me has been javascript - it's so...bad it became good or at least ubiquitous.
C and Javascript are both worse-is-better languages, as is SQL. They have known gotchas and quirks and lots of them. But they basically work, they were good enough, and because of that they became so ubiquitous that it's impossible to replace them.
They were both THE languages of systems that became/were important. I agree that they both have the "worse-is-better" quality about them, but C is a much more appropriate language for what it's supposed to do than JavaScript is. The fact that we (mostly) haven't been able to execute anything else reasonably in the browser is the reason why it's stuck with us. C has had alternatives for a long time but stays put, because it's just better at what it does.
Not ... really. Those languages all became popular and got critical mass because they were the only way to access operating systems-like things. People wanted the value provided by those platforms and had to go through the language to get at them. So they buckled up, tolerated it and promptly spent decades and billions of dollars on creating wrappers, FFIs, transpilers and the like to avoid having to touch the underlying monopoly language.
People wanted browsers. JS came along for the ride. It wouldn't have been so popular if it had lived its life outside the browser
That's exactly how worse-is-better works. You're not doing it well, but you're consistently showing up in the right place and interoperate well with the things people want to use so they are forced to get to know you.
JavaScript is that guy you knew who didn’t have a lot of talent but has stuck at it for the last 30 years, so is now embarrassingly doing much better at his thing than you are.
Python is weird. It's a nice language but it was heading for tech debt status along with (maybe) Ruby, then the ML guys went all-in on it and that saved it. But how often do you find new programs being written in Python outside of the ML/AI space? People got burned repeatedly in the 2000s/2010s by building giant empires on the back of dynamically typed scripting languages and they all ended up either doing rewrites into statically typed languages or (when successful enough) funding PL R&D to try and dig themselves out of it.
I use it - and I suspect a lot of other people also - as a replacement for Matlab. I am an electrical engineer and I write short scripts to calculate stuff and hook it up to simulations etc. Matlab has great toolboxes, but is pretty expensive and the language is a bit clunky. Python is just very versatile and has a huge eco-system now that would be hard to replace. A lot of system administratiors also use it for scripting.
Which is weird because Perl didn't really go anywhere, and only got better over time. I mean, at this point it's a large dose of network effect, but I'd love to learn how this transition happened in the early days of it.
Edit: I just tried to look it up and as far back as I can find data (which is early 2000s something), it seems that Python has always been more popular than Perl. TIL!
But how often do you find new programs being written in Python outside of the ML/AI space?
Python is pretty huge in most numerical spaces outside of ML/AI, basically anywhere people would have used MATLAB in the past. It is also the go to language in GIS and quite popular in civil engineering.
I was thinking the same thing. Silverlight? Silverlight??
I just ended a job with a guy who going on about how he was a Flash hotshot back in Y2K days, lamenting "Steve Jobs for killing it." Like, dude, everyone with two neurons to rub together told you it was a fundamentally terrible idea, doomed from the start. Gawd.
I also fell for a few of his picks — Angular was a rough blow — but what a list of lousy bets.
MS Visual Basic 6, MS ActiveX, MS Silverlight, MS Visual Foxpro, MS C# .NET Compact Framework, MS ASP.NET WebForms, MS ASP.NET MVC, MS Windows Communication Foundation...
I think there common is a theme there. But shhh, don't tell him.
Most of that was replaced by their own .net core and Google's efforts to optimize JavaScript and establish Chrome as the defacto browser, which remains as one of Google's few ongoing projects.
I 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 problem. It probably lasts 5/10 years and then someone rewrites it in a new language, or more often the task isn’t relevant anymore so the code gets deleted.
I find myself thinking that maybe if I’d been in civil engineering or something then I’d be building stuff that lasts, but speaking to people who’ve worked a long time in construction has taught me that it’s the same there. Most of the buildings that go up, come down again in a few decades once regulations/fashions change or the new owner of the site wants something else.
Every so often something like a Cathedral gets built, and those get built to last. But most people don’t get to work on those. If there’s a software equivalent of a Cathedral then I still haven’t found it.
To invoke the RIIR train, probably a lot of fertile ground in being the definitive Rust implementation of "solved" foundational libraries: zlib, libpng, libjpeg, etc. Something ubiquitously used which has very minimal/no churn. As Rust usage grows, dependency on the original C implementation will diminish.
It will diminish, but never go away until POSIX foundations or graphical programming standards get replaced (most of them defined via C ABIs).
When I was mostly doing C++ and C on day job, 20 years ago, they were the languages to go when doing any kind of GUI or distributed computing, nowadays they have been mostly replaced for those use cases.
Yet they are still there, as native libraries in some cases, or as the languages used to implement the compilers or language runtimes used by those alternatives, including Rust.
Even those change substantially over time, even if they're not directly rewritten, things get updated and relocated.
It's like how the streets in Rome have been the same for much longer than many of the buildings have been standing, even though the buildings are hundreds of years old.
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. The best we can do is do the best with what we have in front of us. And maybe all the work you did to make sure your one-off database code correctly handled the Y38 problem back in 2000 will never be noticed; because your software is still running and didn't fail.
> pdfTEX is based on the original TEX sources and Web2c
So it at least ties back to original code. XeTeX appears to be similar but with even more extensions, but other of the "TeX" tools are complete rewrites.
Externally visible stuff: definitely. You really need something like TeX or by now Linux and some GNU Tools etc. to stand the test of time.
My very first job was to work on the backend of some software for internal use. You have probably all bought products that were "administered" in said software. When I worked on it it was 15 years old. It evolved over this time of course but original bits and pieces were all around me. And I evolved bits and pieces of it as did others. By now it's been another 15 years and while I know they did a rewrite of some parts of the system I bet that some of both my code and the code I found to have been written almost 15 years before I started there is still around and you and me keep buying products touched by that software without knowing. The rewrite was also done by at least one person that was around when the original was built. He learned a new language to implement it.ut he took all of his domain and business logic knowledge over.
Its even more funny because I knew the guy that wrote some of the code I worked with directly from a different company but I had no idea he worked there or that he worked in that project until I saw his name in the CVS history. Yes CVS. I personally moved it to SVN to "modernize". I hope that was recognized as "technical debt" and they moved to git but I wouldn't know.
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.
It's comforting to think that 2000 years from now, all that may remain of the early web and modern culture is the Space Jam website. Maybe Space Jam the movie will be looked at as our Gilgamesh or Iliad.
From the outset, the framing of a Web site as staying "up" (or going "down") is definitely an accessory to the mindset that leads to the effect observed. Rather than regarding Web sites as collections of hypertext-enabled publications like TBL spelled out in "Information Management: A Proposal", we have this conception of a Web page being something like one part software, two parts traditional ephemera. But they're documents. Merely observing this difference in framing and being conscious of the contrast between intent/design and practice can go a long way to addressing the underlying problems that arise from the practice.
Most code that survives 5 years survived for all the wrong reasons. That said, most code that's survived five years is often a profitable product with a reasonable human at the helm telling us needs to not to touch it
When I was young I spent a year framing houses. I reflect a lot on how much longer those have lasted then so much of what I built software wise along the way.
I think this is by far the most common outcome for work. A chefs product only lasts an hour at most. Most jobs don’t create anything other than a temporary service.
That’s because most of the things we need are temporary services, of course. You need dinner. And gas to get to work. And a roof that will last 10 years. Etc.
That's a very romantic view of the life of a chef but I'm afraid that by an overwhelmingly enormous margin the output of a chef is servings of food not century-spanning recipes.
The comparison between developer and chef is kind of a stretch but there is a similarity of sorts. It could be argued that the recipes are analogous to the algorithms or patterns that we use day-to-day in software development, and that the servings of dinner are analogous to the applications we build. The algorithms/patterns and recipes might persist for a while, the apps and food have a shorter lifetime.
I'm not advocating for throwaway or disposable code (though I'm not above implementing a quick hack, personally) but I don't think we need to think less of ourselves or our profession because we're producing things which currently have a shelf-life of years or decades at most.
The Youtuber Max Miller's channel "Tasting History with Max Miller" has a number of good examples of old recipes for now-familiar foods. His Semlor episode[1] compares a recipe from 1755 and one from more modern times, and there are substantial changes.
SQLite is awesome. TIL that its database structure is robust enough to have been chosen as one of only 4 Recommended Storage Formats for long term data preservation[0].
> "Recommended storage formats are formats which, in the opinion of the preservationists at the Library of Congress, maximizes the chance of survival and continued accessibility of digital content.
I never saw this page before. Brilliant! Like catnip for nerds.
Disaster planning → Every byte of source-code history for SQLite is cryptographically protected and is automatically replicated to multiple geographically separated servers, in datacenters owned by different companies. Thousands of additional clones exist on private servers around the world. The primary developers of SQLite live in different regions of the world. SQLite can survive a continental catastrophe.
> If there’s a software equivalent of a Cathedral then I still haven’t found it.
Probably like, some parts of Windows or Linux, or GNU tools, or some thing like that that, while still being updated, also has ancient components hanging around.
This is completely random, but you remind me of something that makes me laugh every time I use Google Maps navigation.
Last year I was messing around with my phone's text to speech settings, and I selected a male voice but cranked the pitch setting to the max. I proceeded to forget about it. For some reason when navigating, the voice is still the default pitch. Maybe about 1 in 20 turns at random though, the voice has the pitch cranked up to the max. It's rare enough that my 4 year old and I always burst out laughing when it happens.
It isn't necessarily software, but algorithms will likely last a long time. Euclid's algorithm and the sieve of Eratosthenes are still around. Researchers are still developing new ones. Just like building techniques may outlive the buildings that were created in their shadows.
But the thing is, that the ghost of the code lives on. Many times I saw specific database designs, and technical decisions all taken to accommodate a solution that didn't exist for a decade or so.
> I find myself thinking that maybe if I’d been in civil engineering or something then I’d be building stuff that lasts, but speaking to people who’ve worked a long time in construction has taught me that it’s the same there.
Right. People who assume otherwise aren't spending much time browsing the relevant subjects on Wikipedia or historical registers or just paying attention to their municipality. Simple demonstration: look into how many Carnegie libraries that were built are now gone versus how many are still around.
Why though? Does it really matter if something outlives you by 200 years? 500? On a not-that-long timeline like 10,000 years, nothing lasts. The "cathedral-like" timeline is completely arbitrary I think.
Imho, there’s freedom in accepting that nothing I produce will last a long time.
I agree with your takeaway message, but the timeline isn’t completely arbitrary. From the perspective of humans appreciating things, there’s a difference between something that endures for .01x vs. 10x a person’s expected lifespan.
Because what matters is not the number you can think of, but the scale proportionate to human life / needs.
For somewhat related context: all my life until recently I rented, but now had become a house owner. My strategy with things I bought for daily use was that they were meant to survive until the next move. For many things it wasn't economical to take them with me to the new place. So, for example, I didn't want to buy a "proper" pan / skillet, and was happy with a teflon one just because it would wear off about the time I needed to move again. I could just throw it away and get a new one. Now that I don't intend to move, I'd choose to buy things that last, because cost of moving vs cost of garbage cleanup changed.
Now, when it comes to software, it looks like the industry is overwhelmingly motivated by short-term benefits, where, in principle, it shouldn't have been. And this is the surprising part. Lack of vision / organization leads to the situation where we never even try to make things that last. There are millions of e-commerce Web sites in the world, but they are all trash because nobody could spend enough time and effort to make one that was good (so that others could replicate / build on top of it, and also have a good product). We have the most popular OS, that's absolute garbage, both the core and the utilities around it, which is due to shortsightedness and even unwillingness to plan on the part of the developers. Same thing with programming languages, frameworks etc.
So, looping back to your question: why the magnitude matters? -- what matters is how your own planning compares to the lifespan of your product. Many times in my career I was in the situation where I was building an already broken thing from a design that was known to be broken from the start or very soon afterwards. And that had nothing to do with changing requirements, it had all to do with the rat race of getting a product to the market before someone else does / investor's money dries out. The idea behind "things that last" is that at least at the time you are making them you cannot see how whatever you are making can be done better (as in more reliable / long-lasting).
In the end of the day, what happens now in programming is that things that shouldn't outlive their projected deadlines do, or, predictably, die very fast. But we don't have any section in the industry that builds things to last. We just keep stuffing the attic with worn-out teflon pans.
Compare this to, for example, painters, who despite knowing that most of their work will likely be lost and forgotten, still aspire to produce "immortal" works of art, and if a picture takes a lifespan or more to make, then so be it. (In the past, some works of art were carried out by generations of artists, especially, when it comes to books where scribes were succeeded by their children who'd continue writing the book after their parents death).
Games seem to have a longer shelf-life, or at least tend to be passed around for longer. Some of my Flash games from 15 years ago are still being passed around game torrents and still playable on Newgrounds, and the console games I worked on are still playable in emulators and part of rom collections (and the one physical game I worked on, a PSP game, is still available to buy used on Amazon).
Now, how many people are actively playing those games? Probably very few people. But at least it's still there when people get the urge, or decide to play through a collection.
Consider constructions that have survived thousands of years such as the Tarr Steps or Stonehenge, or more recent constructions such as roman roads, Dunfermline Abbey or St Bartholemew's Hospital.
These sorts of constructions have been repaired and re-set hundreds of times over their existence, and have sometimes gone through periods of destruction during war and natural disasters, disrepair then subsequent periods of restoration and reuse. At a certain point, very little or nothing of the original construction really remains, but you can nevertheless draw a line through hundreds or thousands of years of history.
Software may be more like this: continually rebuilt and maintained, but still physically or philosophically related back to some original construction. Nobody uses Multics any more, but almost everything in use today is derived from it in some way.
To your point about buildings, I wish we considered the "technical debt" of our society's built infrastructure more. It seems we went very wrong with this habit of building and rebuilding on such short cycles, especially on large projects that have much longer lasting consequences on the more important infrastructure of our natural ecosystems. All that carbon burned to extract, produce, and transport building materials. All those sprawling roadways built over habitats and forcing people into unsustainable patterns of living, burning more carbon in their day to day to get around. This debt needs to be measured and it needs to be addressed with high priority.
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.
I’ve worked on the same website for 20+ years. Recently we were informed that the site was being shutdown and we would be reassigned to other teams. On the one hand, as long as they are still paying my exceedingly well, do I really care what I am working on? On the other hand, it is a bit painful seeing 20+ years worth of work being deleted.
I've been doing this for over 30 years. Not only have I seen years of my work deleted, I've also seen large fractions of the rest of it never even used.
> I've also seen large fractions of the rest of it never even used
These were some of my favourite as a young freelancer (long time ago): they'd pay me $90/hr to write stacks and stacks of code with our small parents-garage team and when we finished, we demoed to the client who were very happy. But instead of having to wait for bugs, fixes and addition, we just got a new assignment after learning 'great job, but this is no longer needed'. Now I find it painful, but back then we could just focus on 'new things' like that. It didn't happen often, but there were a few large ones that I remember well.
Everyone one that has counter examples thinking they prove the opposite, are just not waiting long enough. All the kids think they will be young forever. Can't blame MS for new JS libraries every month, or a new language released every month. This web site is dedicated to people showing off things they created, which replace something that turns into debt, and in turn also become flavor of the month.
Yes, biased old man that saw 30 years of code get replaced with the latest "thing that kind of works like the old thing, but not really as good, but we have to do it to keep up with technology or we'll have debt". I've seen old VB6 apps fulfill a business need just as well as anything written in a full LAMP stack that takes a team to implement. (not that I'd ever use VB6, but hey, it did a job).
Take me out back of the shed and end it quick while I'm hunched over programming something cool.
It’s so weird, I used to be much more of STEM triumphalist, the kind of person who used to think the past was evil and the future can’t come fast enough.
I wouldn’t consider myself conservative by any means but increasingly in 30s I’m beginning to think everyone needs to stop messing with stuff and accept imperfection.
As the adage goes, things that are new when you're a kid are the norm, things that are new when you're a young person are exciting, things that are new when you're older are unnecessary, confusing, or scary.
It's true for everyone in every subject I'm afraid:)
Even when young, new stuff is scary. Look at any community, ranging from RPGs (new rule editions, new meta plots (those are in the example I think of getting worse, objectively ;-)) to stuff like World of Warships (new classes and ships introduced after person started bad). Nothing to do with age, but rather emotional attachment. I try to avoid that kind of attachmemt, especially with regarda to my work. The odd time I stumble across something I didnyeaes ago more often than not I embarassed to thebpoint wantin to deprecate it myself! The rare, even odder, exception notwithstanding.
That's the usual path of becoming conservative as you grow up. Or phrased another way, becoming normal. The training process humans go through leads to a lot of weird biases, just like how RLHF contributes to models getting bad ideas as well as good.
For example, you spend years in school being instructed as efficiently as possible in the one right way to do things that was already discovered. You are only rarely or never shown the messy process of trial and error needed to get there, and many really big errors are hardly covered at all (the history of communism didn't even get a look-in when I was at school!).
Another: you're instructed near exclusively by specialists, who are definitionally always right (if you argue with the teacher, you lose).
Yet another: as you progress through the system, you're rewarded as the ideas you handle get more complex. You aren't rewarded for simplicity. You are also rewarded for bullshitting, because just like RLHF, exams don't award points for saying "I don't know" but they can award points for a lucky guess.
These sorts of systems inevitably lead to an assumption that progress is linear, mistakes rare, complexity intrinsically has value, that expertise is nearly infallible, that guessing is OK if you don't know and the situation seems important etc. The longer one spends in education the further from reality these intuitions become, until you reach academia and become a public intellectual who produces the most complex/radical ideas possible based on educated guessing and then ignores whether they work or not.
Life outside the training environment eventually starts to correct these false ideas. You see how many things are tried that fail, how nuanced and ambiguous the value of ideas really is, how complexity blows up in people's faces due to problems they didn't anticipate and so on. You start to value incrementalism, evolutionary processes, systems that gather and aggregate the wisdom of the crowds. You become less impressed with ivory tower intellectuals who think they got it all figured out in advance on a blackboard. You become conservative, and end up railing against the young radicals who have some bright idea for reshaping society by force.
Well, becoming small-c conservative, to a certain extent, is probably fairly normal, though perhaps not inevitable. Capital-C Conservative, not so much: that doesn't come with age, it comes with wealth.
These things are conflated because it usually takes time to accumulate wealth especially if self-made, so older people will tend to both be richer and more small-c conservative.
Also although in the tech industry this link has been broken/inverted, there's usually a correlation between excessive risk taking (i.e. lack of conservatism) and losing all your money. In most sectors of society wealth is built up over time through care and perhaps a bit of moderate risk taking, but not too much.
Anecdotally speaking it came with paying taxes not with accumulating wealth (though I wish it were the latter).
My first contracting job where I had to pay quarterly tax estimates (apologies for the U.S. tax-code specific reference) literally changed the way I thought about the world. Instantly financially conservative.
By far the smartest thing the US government ever did was take your taxes out of your paycheck so you "never see it".
BTW this applies to personal taxes not corporate taxes. Still think we're going about inflation completely wrong by raising rates and not raising corporate taxes. But the U.S. has been on a genocidal campaign against the middle class for decades now and we keep electing the same politicians so I guess we get what we deserve.
Not sure why you are downvoted, this is one of the best comments I've read in a long time. How idealism turns into realism and the sweet spot is probably somewhere in the middle.
It's because conservatism whether big or small c, political or technological, tends to be seen as standing in the way of progress by those who didn't arrive at the same underlying intuitions about the difficulty of tabula rasa development. Because the intuitions are so deep, we barely articulate them and that leads quickly to misunderstandings. Conservatism can easily be perceived as errant obstructionism or even the result of a hidden agenda that stands in the way of a better future, if Great Leaps Forward feel easily achievable. Hence why the OP said when he was younger he saw the past as "evil" - a very common way for young radicals to perceive conservatives.
For example, most companies with large software assets will at some point go through a fight between the old hands and younger devs about whether to do a rewrite in the hot new thing. Which side you're on may appear dominated by age, but it's really more about your intuition about the risks of rewrite projects. That in turn is determined by your experiences of people's ability/inability to fully comprehend complex systems.
Also I didn't try to to be neutral, hence the digs at communism and academia. If I was aiming for karma I'd have left those out. But I'm not.
Steven Colbert once jokingly said, "Reality has a well known liberal bias".
It should probably be the other way around, that liberals have a reality bias, but it doesn't quite land. Liberalism is based on what can be proven. Especially in science, starting with some preconceived reservations leads to inaccurate models. If you can't articulate it, all the worse. Even things like categorization and taxonomy can't account for our in-built intuitions, there's always an exception. So, we really must try a tabula rasa type approach. This tends towards a, you guessed it, a world view more constrained by reality, which typically falls left (see, most of academia).
I'd say holding on to heuristics is good, but I don't think we'd be where we are today by not trying to rethink, destruct, unravel, play, squish, open many mental gateways.
If your contention is with Whig history then we might agree. But I don't think there's any surity in being sure.
Trying desperately to stay on technical topic here, I'd say the only places where this dichotomy comes up are in cases that are inherently ambiguous and subjective. If something is genuinely proven then everyone does actually accept it. Conservatives and liberals don't disagree on the energy of an electron or the color of the sky. Disagreement occurs over things that can't be proven: how valuable is spending time on feature X instead of rewrite Y? Is this choice of library really "debt" that needs to be paid down by rewriting, or is it a mature tech whose imperfections should just be accepted as an inevitable part of life? If you rewrite, how likely is the project to create new problems at the same time as solving old ones? How can anyone prove such a thing one way or another ahead of time? It will ultimately always boil down to a complex interacting set of intuitions and experiences which vary between people.
The Colbert snark is illuminating because it gets to the nub of the conflict. It's an attempt to claim that reality, something often ambiguous and subjective, as if it was simple and obvious. Look at how straightforward the world is to comprehend - why, all you need is a few nice and neutral academics who do a few studies, write it all down in a model and you're done! Now you know what everyone, everywhere should be doing. Others look at this aghast and say no, that approach has a history of going spectacularly wrong. The model did not match reality and disaster followed.
In the software space it leads to conservatism of the Joel Spolsky "never do rewrites" variety. That's too strong, but it's a famous and widely cited essay even 20 years later because it represented a rare articulation of the value of conservatism in technology along with clear real world examples of cases where the lack of it led to (commercial) disaster. Fortunately, attempts to rewrite Navigator or Word only led to financial disaster and only for specific companies. When attempts are made to rewrite society instead of software the cost of failure is drastically higher.
Vaccines aren't proven compared to things like the color of the sky, are they? Who on earth still believes that after "95% effective against COVID infection and will end the pandemic" turned into whatever this week's version of the story is. COVID shots demonstrated unequivocally that scientists and officials will happily assert things with 100% certainty that are falsifiable, and then continue to assert them even after they've been proven false in front of everyone.
And that's my point - if you intuit that the world is simple and progress easy, you become committed to mental shortcuts like "if a professor/civil servant says it, then it must be true". The education system forces this mentality on you, even. When other (usually older) people who don't take such shortcuts say "but actually that's not true" then it turns into a fight over what reality actually is, which is an enormously complex thing. Rather than engage down in the weeds where they might lose, young radicals prefer to just try and shout down objections. This pattern crops up again and again.
Evolution is an interesting one because in that case it's the creationists who have adopted an overly simplified model of reality and don't want to let it go. Same problem, just different groups. I don't personally think the word "conservative" is all that useful for that reason even though you often have to use it, because it just means trying to conserve things, which as a position is neutral with respect to what's being conserved.
I don't think your take on vaccines is accurate. The recent handling of covid vaccines is being miss-understood because it was a fast moving and dynamic situation. There was an effort to provide information as it was being learned, with partial small studies. Knowledge was changing in front of us, and yet scientist are blamed for not being 100% accurate about everything instantly. But that is covid, there are many Republicans that also stopped giving kids measles and polio vaccines and then there were outbreaks. SO, yes, conservatives are wrong, they want to 'conserve' themselves to pre-scientific ways of life, where we ignore things we do know for fact. I'm not sure some of them do doubt that electrons exist.
For better or worse STEM in the English speaking world is still slightly stuck in the empiricist mindframe where inventing new technology and discovering new things by observation is the main method of advancement.
This creates a bit of a blind spot for stuff like mathematics where a good idea can continue to be used and be improved on for ages, or in physics where some of the most groundbreaking stuff in the 20th century was not found by observation but by thought experiment.
There's a lot that can be gained by recognising and reusing the same good idea for centuries, but it is not really 'progress' in the 'discovering / building new stuff' sense.
There's a difference in the modern era with the term "conservative", and you may find the term "reserved" fits what you're describing here better.
I wouldn't consider myself conservative by any means, but I do find myself more reserved in my decision making - I'll take a bit more time to come to a decision rather than firing from the hip, etc.
If you don't want to be replaced you must solve real issues, like centering a div vertically. Joke aside, the good part of LLMs replacing the programming jobs is that programming can become fully an art [1], such as calligraphy or manual woodworking [2].
It isn't necessarily a cycle, a lot of the issue is just a cultural issue with software development. You can change culture, however slowly, it can change.
It's a good thing if the environment around your VB6 stuff can still work with it, or accept it. Many systems get replaced when the substrate they run on is no longer supported as in "won't run on any hardware still in its warranty cycle or with parts available", or everything around has changed and the layer of glue needed to keep the old system alive and talking to everything else has grown to be prohibitively complex and expensive and is now more like a load-bearing structure by itself. If you can replace it and also fire warm bodies who used to keep it alive by being the irreplaceable wizards with arcane knowledge and job security, it just might be a net win.
I hear tales about several layers of emulators the sources for which are forever lost, with the bottommost of them running some very mission critical early COBOL or ALGOL-69 (or Lisp, who knows) code written back in the days when it had been that newfangled thing young guns liked, and which no one now can reimplement today (maybe because elves have died out from smog and the golden age is over), but they may be bunk.
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.
a 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
It's intriguing, because that implies he can work on most things in a way that "fits inside one's head."
Do you know if he extensively calls out to external tools, custom aliases, and the like?
I imagine there is some fullscreen mode where he can--temporarily--suspend ex, make use of custom sourced mappings, and the output is piped back into his editing session.
It's hard to find certain tidbits, so I'm always glad for even the smallest details.
I'm the ex(1) troglodyte in question. I don't use custom aliases, because I have had all editing tasks hardwired into my brain for decades, ever since I dropped Teco for ed and then ex. (Ed is the standard editor, but I'm willing to trade off a little standardosity for added convenience.) If the te command had been widely available, I might have stayed with it and not used ex, but that day has passed.
I do pipe stuff through various commands more or less constantly. I most often pipeline through awk, sed, sort, uniq, cat -n, etc. I have a back-burner project to write a meta-editor that works by pipelining and maintains a whole persistent undo-redo history.
Not very convincing. The world is full of abandoned open source projects and companies that maintain proprietary platforms near indefinitely. Angular 1 is dead, Python 2 is dead, Perl is dead, GTK 1-3 are dead, old KDE is dead, X11 is dying, but you can still buy supported versions of Delphi, COBOL and even VB6 is still somewhat maintained by MS [1]. ActiveX was killed by browsers (open source), the underlying proprietary APIs are very much not dead.
it's not at all difficult to run code written for angular 1, python 2, gtk 2, gtk 3, or x11; you don't even have to port them, you can just run them, and i do every day. it doesn't even require any effort
contrast that to applications written for silverlight, activex, or flash
with respect to gtk 1, you sort of have a point, but gtk 2 was released in 02002, and it's usually not hard to port gtk 1 apps to gtk 2 (and almost all of them have already been ported). and i'm not sure what you mean about 'old kde'
free software licenses provide strong legal protections to users to do whatever is necessary to maintain and extend the software they depend on and share that with others, and in practice they do, and the consequence is that the hype cycle is much slower and less destructive
Nice. I was a less smart person who wanted to learn, like everyone does these days it seems (but not back then), the latest and the greatest. My Django projects of 10-15 years are running fine in production and get updates in their respective companies. All the rest I've written has all kinds of issues. And Django is still relevant, just not hip. Should've stuck with it.
Absolutely, 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.
> One of the biggest challenges we had at Stackify was getting stuck on an old version of Elasticsearch. At one point, they made some significant changes to how it worked that were not entirely backward compatible.
I am glad I am not the only one who hit this roadblock with Elasticsearch. It felt like always trying to play catch up.
One company I worked at had heavy SQL Server stored procs. I was pretty dismissive initially ("don't put business logic in the database layer!") but grew to understand that really those were the gold. The first versions were written in 1997 and by the time I arrived that code was bulletproof. There were about 4 UI technologies over 20+ years (VB, ASP, Forms + asp.net), but the procs were the same shape with thousands of edits for edge cases. Changing UX for the new hotness was massively de-risked and faster because the procs were solid.
think around 2010 I worked for the one and only payment processor in my country. All ATM tx, POS, online were handled. The back office handling was done with Agile and Java. It was a pile of garbage. The frontend was still a massive mainframe. It had 10k+ COBOL program running it. With comment changelog on top from somewhere end of the 70s. The code review guy was doing this for 20 years and could tell if things would be slow and not scale all the Tx with just reading the code. Until today they never replaced it and is still running on it.
sometimes you don't need fancy new stuff. Just learn the things very well at your disposal. Heck sed, awk and bunch of simple cli tools still work well on Big data sets :)
Yeah, when I started in this field 20+ years ago, the wisdom I learned was that it was bad practise to tie yourself to the DB like that. But just like you I can see the value in doing it. SQL may be one of the most futureproof languages there are.
I think it's normal. Some systems I've built were quite sticky in the sense that they started as prototypes to be scrapped once we figure out the "real" system architecture, and 8 years later they're still in use and integrated into dozens of business processes, so hard to replace.
In general, looking back at old code I wrote it seems my solutions were better when I was more naive / less experienced, as I would often go for the immediately obvious and simple solution (which is the right one in 90 % of cases). Working many years in software development and reading HN seems to have made me more insecure regarding software, as I tend to over-engineer systems and constantly doubt / second-guess my technical decisions. So one thing I'm actively trying to do is to go back to using simpler approaches again, and caring less about perfect code.
> as I tend to over-engineer systems and constantly doubt / second-guess my technical decisions
I find this as well. I also think that there is a sub-conscious fear as you become more senior that you need to justify that with more elaborate/complex solutions. In my experience there are also a lot of people in software who never come out of the other side of that view and constantly equate "complex" with "good". Being in an environment with lots of people like this makes it hard sometimes. Ultimately you need to trust yourself and do what you think best. If it goes wrong, at least you know you did it for the right reasons.
Anyone with young children may be familiar with Peppa Pig, an animated British show. Daddy Pig is an expert when it comes to concrete. A far off land sends for him to inspect their concrete, and he travels by overnight train. In the dining car, his breakfast is catered to better than royalty. When he gets there, he taps a block of concrete with his pen, declares it good, and the king and everyone rejoices.
In many ways, that's what it's actually like when you've punched through and become a true expert in your field. Important problems are solved with an overnight sleep, a cup of coffee, and a few careful taps. By the time you get there you're insane, but at least you're offered both coffee and orange juice if you ask.
I don't know what this means about my personal (in-)ability but I've been developing for years (15+) and I feel like all of the other developers I have to deal with are constantly turning to weird, convoluted solutions to problems. I have also never been able to get past the first step in the google interview process so I have this deep, frustrated insecurity. And people constantly like to point out how simple my stuff is in a tone that suggests that is a bad thing.
My hatred of the complex solutions is so deep that I just suffer through all of the commentary silently.
You probably need to study the Complex, get to know it really well, almost, but not entirely, embrace it, and only then ditch it in favor of Simple.
I mean, it could just be that your simple solutions have been missing something, maybe something crucial, or you lacked the understanding of the mindset of people loving their complex stuff, which presented a communication barrier.
Definitely my experience as well. My dark horse is trying to optimize for speed when i don't need it, and not doing it when i do.
When i was more naive, i'd just stick with the first solution that worked. Now, i find that i'm always worried that someone is going to try to input a 30000-line csv in my tool and that i must use the slightly faster way because it's the right thing to do.
One of my tools to prevent this has been the non-accepted answers from stackoverflow. I find that they are generally of similar quality to the accepted answer, but that because they are less tailored to the (necessarly) different problem, they fit less and have a lesser chance of being accepted despite being more useful to more people.
Recent example: I have a side project with Typescript on the backend and frontend which also uses an Audio Worklet, so it loads a JS file at runtime to be run in a separate process, isolated from anything else.
I also have a class which I need to use in all three mentioned pieces.
Three years ago I would spend hours trying to figure out how to make this work with the build system so as to not have duplicated code and maybe eventually arrive at a mostly working solution before the e.g. frontend framework maintainers update their build system version which may or may not break something.
This time I just copied the damn file everywhere - the Audio Worklet got the compiled JS output pasted at the start. It's a class, it works and I have maybe one idea what changes I could make there in the future at which point I'm just going to copy everything again.
Insert Pirates of the Caribbean meme. "This is without doubt the worst ship that's ever floated." "But it does float." There's no inherent shame in Ship-of-Theseusing something to accommodate changing requirements! Complete rewrites are hard and take forever!
The guy way overused "deprecated" in that article.
Perl 5 is alive and well, and while not the most actively developed of languages still has a steady trickle of small improvements.
It's installable in all major linux distros and you can probably get code from 2 decades ago running without much hassle.
Most people would shudder at the thought of starting a new project in it, but if you need to keep a legacy codebase going the community have your back for many many years to come.
582 comments
[ 3.5 ms ] story [ 380 ms ] threadThe barnacle did provide more lifetime business value after all.
(I'm more committed to the bit than this position though, it's a judgement call that an engineer must make relative to the requirements and resources available.)
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 it's a bad thing.
in my experience, if there's no will or budget for a rewrite, it gets virtualized, locked away behind a firewall/corporate network with a restricted set of users, and will basically run forever as long as the ISA and virtual storage is supported by emulation and the business process still exists and is able to support the infra/people involved.
think of it like a zero coupon 100 year bond in technical debt issuance underwritten by the central bank (corporate hq). and highly liquid in the sense that a virtual image is easy to move around.
the good part is it just gets faster and takes up less % resources as hardware improves, and forever-bugs are usually worked around and documented by the people pushing the buttons.
First I wrote single threaded code code with automatic memory management, then single threaded synchronous with manual memory management, then synchronous multi-threaded, then async, and then async lock free.
Now I am writing async lock free, and the compiler is helping me prove it is data-race-free and memory safe.
Each time I rewrite this stuff, someone hands me 6-7 figures. This is awesome.
Citation needed. Seems that it just us getting more and more abstracted which can make it easier but not necessarily easier.
The hardest part for the next gen of developers is not having Moore's law to save them from crappy coding.
You could've cited Slack or Discord. Teams is an anomaly in horrible software quality that *only* Microsoft can manage to produce (also see OneNote (but DON'T see VS Code -- that's somehow really efficient despite being Electron!)).
Lock-free goes way back. Multi-threaded goes way back. Both more than 20 years. SIMD goes way back. GPGPU goes way back.
What is newer-ish are large scale distributed systems. But even that isn't so new any more.
most of the programs i use (besides the browser) are 20-50 years old (paste, cut, xterm, grep, emacs etc), almost any new thing i try is horribly slow (slack, whatsapp etc, the mac terminal app, even the mail app is slow compared to mutt)
open a web page on a computer without adblock and look at what we have built
https://www.youtube.com/watch?v=pq7NLMwynYg (funny video demonstrating the state of the modern web)
I am writing async lock free code as well, but which compiler is helping you? Rust? As far as I know, it's cutting edge research to figure out a type system that fixes this for you. But maybe i'm not up to date.
> stuff gets better so fast that we get to reimplement the same thing
So you are leaving the API in-tact and just change the implementation with new techniques? Or even better, you just rewrite low-level libraries you are using? Sounds like the ideal job to me.
I envy you.
20 years from now, C will probably still be a core language in its niche.
I think C and its direct descendants will slowly fade away over the next 20 years as new developers want to get away from the legacy of language specifications that span existing codebases. There are so many sharp edges in C that have automatic fixes/detections/etc in newer languages and don’t get me started about multiprocessing complexity in C.
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<T>::writer::new(connection.clone()).clone(); // TODO ??? writer.write(*data.clone()).unwrap();
Meanwhile in C++ I'm like
if (!write(connection, data, data_len)) { return false; }
Flip-side is, I'm coding in CMake right now. I've had to create multiple bash scripts for manually deleting my build files and general day to day.
Software is a young profession.
Everything is shit.
clone() itself makes perfect sense. Why the programmer needed those clones... is a legitimate issue with Rust.
In my experience so far, it's usually to hack around an interaction between the borrow checker and the output of a function constructed using dot syntax.
No. clone() calls std::clone::Clone::clone. For many std collections that means deep/recursive copy.
For custom data structures, it can mean anything. It depends entirely on your implementation of the Clone trait.
Basically this looks more like an API design problem than a limitation of the language.
A normal writer API would look like one of the variations:
It's rare to unwrap(), which can cause a crash at runtime, but to handle the result. E.g. to write more data if the previous write is successful. As you can see, "writer.write(&data1)?" is equivalent to the C++ version.The actual code we were working on involved functions returning closures with mutable captures, so the borrow checker was especially persnickety.
> functions returning closures with mutable captures
That sounds like another bad design, but to each his own.
It's not difficult to arrive at the caricature of baroque generic code if you combine lack of knowledge with miscommunication. The knowledgeable coworker should be aware that a writable object implements the Write trait, and know, or find out, the signature of the Write::write() method. Even fully generic, a function accepting a connection and returning the result of writing a block of data is not too gnarly:
No unwraps, no clones. Because they're not necessary here. But someone has to know the language and the idioms. Even your "easy" C++ code depends on knowing that write() returns zero on success, and that integers can play the role of booleans in conditions.*I totally agree with you that folk writing code need to understand the semantics of what they're building on top of. Humans and now AI models have a great capacity for generating tons source code without understanding the semantics, though.
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."
All versions of SQLite released after that time are run through the test harness that maintains this standard.
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.
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.
[1] There have been multiple articles on HN where a single person has written a C compiler.
it's probably always better to do it with someone else, because you get better ideas and faster debugging, but pretty much all hlls are possible for a single person to implement
The POSIX standards, flawed as they may be, have incredible staying power. These standards run our phones and embedded, supercomputers, current Apple workstations, game consoles, and are significant in many other places.
Microsoft itself implemented POSIX in Windows from the beginning (likely recognizing it's importance as the former vendor of Xenix), and while this has waxed and waned, running the "wsl.exe -l -o" command on modern Windows will catalog Ubuntu, Kali, and Oracle Linux that are not Linux, but serviced by the Windows kernel's POSIX layer under WSL1.
Applications that implement or greatly enhance POSIX have staying power.
Those who seek code longevity would do well to study it.
that's not how that works.
wsl is a Linux kernel running under a hypervisor integrated with windows.
Windows was designed in part as a UNIX kernel.
It fell apart in trying to allow both sets of system calls to be used by a single process. This failure is likely a huge reason for Windows NT, as it led to cancelation.
I used Utrix on a Decstation 240 in college.
"However, it proved to be impossible to provide both full ULTRIX and full VMS compatibility to the same application at the same time, and Digital scrapped this plan in favour of having a separate Unix operating system based on OSF/1 (this was variously referred to as PRISM ULTRIX or OZIX)."
https://en.m.wikipedia.org/wiki/DEC_MICA
Still said syscall reimplementation was not based off the old and long gone NT posix personality (just sayin' so I save face...)
https://en.m.wikipedia.org/wiki/Windows_Subsystem_for_Linux
I had known for some time that VAX/VMS was strikingly similar to Windows NT, but I learned a few days ago that the failed Mica project introduced a POSIX interface.
https://en.m.wikipedia.org/wiki/DEC_MICA
C was the 2nd language I learned and I'm still using it. The big surprise for me has been javascript - it's so...bad it became good or at least ubiquitous.
People wanted browsers. JS came along for the ride. It wouldn't have been so popular if it had lived its life outside the browser
Edit: I just tried to look it up and as far back as I can find data (which is early 2000s something), it seems that Python has always been more popular than Perl. TIL!
Python is pretty huge in most numerical spaces outside of ML/AI, basically anywhere people would have used MATLAB in the past. It is also the go to language in GIS and quite popular in civil engineering.
I just ended a job with a guy who going on about how he was a Flash hotshot back in Y2K days, lamenting "Steve Jobs for killing it." Like, dude, everyone with two neurons to rub together told you it was a fundamentally terrible idea, doomed from the start. Gawd.
I also fell for a few of his picks — Angular was a rough blow — but what a list of lousy bets.
MS Visual Basic 6, MS ActiveX, MS Silverlight, MS Visual Foxpro, MS C# .NET Compact Framework, MS ASP.NET WebForms, MS ASP.NET MVC, MS Windows Communication Foundation...
I think there common is a theme there. But shhh, don't tell him.
https://www.spacejam.com/1996/jam.html
29athrowaway said eight times what's common. Eight times!
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 problem. It probably lasts 5/10 years and then someone rewrites it in a new language, or more often the task isn’t relevant anymore so the code gets deleted.
I find myself thinking that maybe if I’d been in civil engineering or something then I’d be building stuff that lasts, but speaking to people who’ve worked a long time in construction has taught me that it’s the same there. Most of the buildings that go up, come down again in a few decades once regulations/fashions change or the new owner of the site wants something else.
Every so often something like a Cathedral gets built, and those get built to last. But most people don’t get to work on those. If there’s a software equivalent of a Cathedral then I still haven’t found it.
When I was mostly doing C++ and C on day job, 20 years ago, they were the languages to go when doing any kind of GUI or distributed computing, nowadays they have been mostly replaced for those use cases.
Yet they are still there, as native libraries in some cases, or as the languages used to implement the compilers or language runtimes used by those alternatives, including Rust.
It's like how the streets in Rome have been the same for much longer than many of the buildings have been standing, even though the buildings are hundreds of years old.
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. The best we can do is do the best with what we have in front of us. And maybe all the work you did to make sure your one-off database code correctly handled the Y38 problem back in 2000 will never be noticed; because your software is still running and didn't fail.
So it at least ties back to original code. XeTeX appears to be similar but with even more extensions, but other of the "TeX" tools are complete rewrites.
My very first job was to work on the backend of some software for internal use. You have probably all bought products that were "administered" in said software. When I worked on it it was 15 years old. It evolved over this time of course but original bits and pieces were all around me. And I evolved bits and pieces of it as did others. By now it's been another 15 years and while I know they did a rewrite of some parts of the system I bet that some of both my code and the code I found to have been written almost 15 years before I started there is still around and you and me keep buying products touched by that software without knowing. The rewrite was also done by at least one person that was around when the original was built. He learned a new language to implement it.ut he took all of his domain and business logic knowledge over.
Its even more funny because I knew the guy that wrote some of the code I worked with directly from a different company but I had no idea he worked there or that he worked in that project until I saw his name in the CVS history. Yes CVS. I personally moved it to SVN to "modernize". I hope that was recognized as "technical debt" and they moved to git but I wouldn't know.
https://www.spacejam.com/1996/jam.html
Nearly 30. Sorry :-)
http://www.questarian.com/
gazelle battery chair figment
> Greater then [an error occurred while processing this directive] Pages requested since December 28, 1999
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.
I've built IKEA bookcases that have outlasted most of the stuff I have written.
A chef's recipe, which is also something the chef creates, may last hundreds of years.
The comparison between developer and chef is kind of a stretch but there is a similarity of sorts. It could be argued that the recipes are analogous to the algorithms or patterns that we use day-to-day in software development, and that the servings of dinner are analogous to the applications we build. The algorithms/patterns and recipes might persist for a while, the apps and food have a shorter lifetime.
I'm not advocating for throwaway or disposable code (though I'm not above implementing a quick hack, personally) but I don't think we need to think less of ourselves or our profession because we're producing things which currently have a shelf-life of years or decades at most.
Perhaps the most enduring a chef can do is invent a new technique.
[1] https://www.youtube.com/watch?v=0Ljm5i5N6WQ
https://sqlite.org/lts.html
> "Recommended storage formats are formats which, in the opinion of the preservationists at the Library of Congress, maximizes the chance of survival and continued accessibility of digital content.
[0] https://www.sqlite.org/locrsf.html
Probably like, some parts of Windows or Linux, or GNU tools, or some thing like that that, while still being updated, also has ancient components hanging around.
Also: That includes the man pages. They should be around in 50 years.
That one old file dialog window that still somehow shows up in windows 11 from time to time?
Or the Linux kernel.
Last year I was messing around with my phone's text to speech settings, and I selected a male voice but cranked the pitch setting to the max. I proceeded to forget about it. For some reason when navigating, the voice is still the default pitch. Maybe about 1 in 20 turns at random though, the voice has the pitch cranked up to the max. It's rare enough that my 4 year old and I always burst out laughing when it happens.
Right. People who assume otherwise aren't spending much time browsing the relevant subjects on Wikipedia or historical registers or just paying attention to their municipality. Simple demonstration: look into how many Carnegie libraries that were built are now gone versus how many are still around.
Imho, there’s freedom in accepting that nothing I produce will last a long time.
For somewhat related context: all my life until recently I rented, but now had become a house owner. My strategy with things I bought for daily use was that they were meant to survive until the next move. For many things it wasn't economical to take them with me to the new place. So, for example, I didn't want to buy a "proper" pan / skillet, and was happy with a teflon one just because it would wear off about the time I needed to move again. I could just throw it away and get a new one. Now that I don't intend to move, I'd choose to buy things that last, because cost of moving vs cost of garbage cleanup changed.
Now, when it comes to software, it looks like the industry is overwhelmingly motivated by short-term benefits, where, in principle, it shouldn't have been. And this is the surprising part. Lack of vision / organization leads to the situation where we never even try to make things that last. There are millions of e-commerce Web sites in the world, but they are all trash because nobody could spend enough time and effort to make one that was good (so that others could replicate / build on top of it, and also have a good product). We have the most popular OS, that's absolute garbage, both the core and the utilities around it, which is due to shortsightedness and even unwillingness to plan on the part of the developers. Same thing with programming languages, frameworks etc.
So, looping back to your question: why the magnitude matters? -- what matters is how your own planning compares to the lifespan of your product. Many times in my career I was in the situation where I was building an already broken thing from a design that was known to be broken from the start or very soon afterwards. And that had nothing to do with changing requirements, it had all to do with the rat race of getting a product to the market before someone else does / investor's money dries out. The idea behind "things that last" is that at least at the time you are making them you cannot see how whatever you are making can be done better (as in more reliable / long-lasting).
In the end of the day, what happens now in programming is that things that shouldn't outlive their projected deadlines do, or, predictably, die very fast. But we don't have any section in the industry that builds things to last. We just keep stuffing the attic with worn-out teflon pans.
Compare this to, for example, painters, who despite knowing that most of their work will likely be lost and forgotten, still aspire to produce "immortal" works of art, and if a picture takes a lifespan or more to make, then so be it. (In the past, some works of art were carried out by generations of artists, especially, when it comes to books where scribes were succeeded by their children who'd continue writing the book after their parents death).
Now, how many people are actively playing those games? Probably very few people. But at least it's still there when people get the urge, or decide to play through a collection.
Actually you have. It’s HN! The website that hasn’t changed in decades… used by the most tech savvy people in the world!
These sorts of constructions have been repaired and re-set hundreds of times over their existence, and have sometimes gone through periods of destruction during war and natural disasters, disrepair then subsequent periods of restoration and reuse. At a certain point, very little or nothing of the original construction really remains, but you can nevertheless draw a line through hundreds or thousands of years of history.
Software may be more like this: continually rebuilt and maintained, but still physically or philosophically related back to some original construction. Nobody uses Multics any more, but almost everything in use today is derived from it in some way.
Remember Crystal Reports? Oh god, the pain. The pain.
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.
I work outside of tech. We still use it.
These were some of my favourite as a young freelancer (long time ago): they'd pay me $90/hr to write stacks and stacks of code with our small parents-garage team and when we finished, we demoed to the client who were very happy. But instead of having to wait for bugs, fixes and addition, we just got a new assignment after learning 'great job, but this is no longer needed'. Now I find it painful, but back then we could just focus on 'new things' like that. It didn't happen often, but there were a few large ones that I remember well.
Yes, biased old man that saw 30 years of code get replaced with the latest "thing that kind of works like the old thing, but not really as good, but we have to do it to keep up with technology or we'll have debt". I've seen old VB6 apps fulfill a business need just as well as anything written in a full LAMP stack that takes a team to implement. (not that I'd ever use VB6, but hey, it did a job).
Take me out back of the shed and end it quick while I'm hunched over programming something cool.
I wouldn’t consider myself conservative by any means but increasingly in 30s I’m beginning to think everyone needs to stop messing with stuff and accept imperfection.
It's true for everyone in every subject I'm afraid:)
For example, you spend years in school being instructed as efficiently as possible in the one right way to do things that was already discovered. You are only rarely or never shown the messy process of trial and error needed to get there, and many really big errors are hardly covered at all (the history of communism didn't even get a look-in when I was at school!).
Another: you're instructed near exclusively by specialists, who are definitionally always right (if you argue with the teacher, you lose).
Yet another: as you progress through the system, you're rewarded as the ideas you handle get more complex. You aren't rewarded for simplicity. You are also rewarded for bullshitting, because just like RLHF, exams don't award points for saying "I don't know" but they can award points for a lucky guess.
These sorts of systems inevitably lead to an assumption that progress is linear, mistakes rare, complexity intrinsically has value, that expertise is nearly infallible, that guessing is OK if you don't know and the situation seems important etc. The longer one spends in education the further from reality these intuitions become, until you reach academia and become a public intellectual who produces the most complex/radical ideas possible based on educated guessing and then ignores whether they work or not.
Life outside the training environment eventually starts to correct these false ideas. You see how many things are tried that fail, how nuanced and ambiguous the value of ideas really is, how complexity blows up in people's faces due to problems they didn't anticipate and so on. You start to value incrementalism, evolutionary processes, systems that gather and aggregate the wisdom of the crowds. You become less impressed with ivory tower intellectuals who think they got it all figured out in advance on a blackboard. You become conservative, and end up railing against the young radicals who have some bright idea for reshaping society by force.
Also although in the tech industry this link has been broken/inverted, there's usually a correlation between excessive risk taking (i.e. lack of conservatism) and losing all your money. In most sectors of society wealth is built up over time through care and perhaps a bit of moderate risk taking, but not too much.
Ref: "Have the Boomers Pinched Their Chiren's Futures", David Willets, Royal Society lecture. https://www.youtube.com/watch?v=ZuXzvjBYW8A
My first contracting job where I had to pay quarterly tax estimates (apologies for the U.S. tax-code specific reference) literally changed the way I thought about the world. Instantly financially conservative.
By far the smartest thing the US government ever did was take your taxes out of your paycheck so you "never see it".
BTW this applies to personal taxes not corporate taxes. Still think we're going about inflation completely wrong by raising rates and not raising corporate taxes. But the U.S. has been on a genocidal campaign against the middle class for decades now and we keep electing the same politicians so I guess we get what we deserve.
For example, most companies with large software assets will at some point go through a fight between the old hands and younger devs about whether to do a rewrite in the hot new thing. Which side you're on may appear dominated by age, but it's really more about your intuition about the risks of rewrite projects. That in turn is determined by your experiences of people's ability/inability to fully comprehend complex systems.
Also I didn't try to to be neutral, hence the digs at communism and academia. If I was aiming for karma I'd have left those out. But I'm not.
It should probably be the other way around, that liberals have a reality bias, but it doesn't quite land. Liberalism is based on what can be proven. Especially in science, starting with some preconceived reservations leads to inaccurate models. If you can't articulate it, all the worse. Even things like categorization and taxonomy can't account for our in-built intuitions, there's always an exception. So, we really must try a tabula rasa type approach. This tends towards a, you guessed it, a world view more constrained by reality, which typically falls left (see, most of academia).
I'd say holding on to heuristics is good, but I don't think we'd be where we are today by not trying to rethink, destruct, unravel, play, squish, open many mental gateways.
If your contention is with Whig history then we might agree. But I don't think there's any surity in being sure.
The Colbert snark is illuminating because it gets to the nub of the conflict. It's an attempt to claim that reality, something often ambiguous and subjective, as if it was simple and obvious. Look at how straightforward the world is to comprehend - why, all you need is a few nice and neutral academics who do a few studies, write it all down in a model and you're done! Now you know what everyone, everywhere should be doing. Others look at this aghast and say no, that approach has a history of going spectacularly wrong. The model did not match reality and disaster followed.
In the software space it leads to conservatism of the Joel Spolsky "never do rewrites" variety. That's too strong, but it's a famous and widely cited essay even 20 years later because it represented a rare articulation of the value of conservatism in technology along with clear real world examples of cases where the lack of it led to (commercial) disaster. Fortunately, attempts to rewrite Navigator or Word only led to financial disaster and only for specific companies. When attempts are made to rewrite society instead of software the cost of failure is drastically higher.
This is demonstrably untrue. Vaccines. Evolution. Anthropogenic Global Warming.
And that's my point - if you intuit that the world is simple and progress easy, you become committed to mental shortcuts like "if a professor/civil servant says it, then it must be true". The education system forces this mentality on you, even. When other (usually older) people who don't take such shortcuts say "but actually that's not true" then it turns into a fight over what reality actually is, which is an enormously complex thing. Rather than engage down in the weeds where they might lose, young radicals prefer to just try and shout down objections. This pattern crops up again and again.
Evolution is an interesting one because in that case it's the creationists who have adopted an overly simplified model of reality and don't want to let it go. Same problem, just different groups. I don't personally think the word "conservative" is all that useful for that reason even though you often have to use it, because it just means trying to conserve things, which as a position is neutral with respect to what's being conserved.
And vaccines don't cause autism. Some things we actually do know.
This creates a bit of a blind spot for stuff like mathematics where a good idea can continue to be used and be improved on for ages, or in physics where some of the most groundbreaking stuff in the 20th century was not found by observation but by thought experiment.
There's a lot that can be gained by recognising and reusing the same good idea for centuries, but it is not really 'progress' in the 'discovering / building new stuff' sense.
I wouldn't consider myself conservative by any means, but I do find myself more reserved in my decision making - I'll take a bit more time to come to a decision rather than firing from the hip, etc.
[1] Was looking at another HN thread, CS 61B Data Structures, Spring 2023 UC Berkeley, https://news.ycombinator.com/item?id=35957811 and in one of the videos, Lecture 27 - Software Engineering I, https://youtu.be/fHEVKqYb9x8?t=387 the professor says "Programming is an act of almost pure creativity"
[2] Japanese Joinery, https://www.youtube.com/watch?v=P-ODWGUfBEM
I hear tales about several layers of emulators the sources for which are forever lost, with the bottommost of them running some very mission critical early COBOL or ALGOL-69 (or Lisp, who knows) code written back in the days when it had been that newfangled thing young guns liked, and which no one now can reimplement today (maybe because elves have died out from smog and the golden age is over), but they may be bunk.
I will leave that to juniors who probably appreciate doing the coding.
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
It's intriguing, because that implies he can work on most things in a way that "fits inside one's head."
Do you know if he extensively calls out to external tools, custom aliases, and the like?
I imagine there is some fullscreen mode where he can--temporarily--suspend ex, make use of custom sourced mappings, and the output is piped back into his editing session.
It's hard to find certain tidbits, so I'm always glad for even the smallest details.
Thank-you.
I do pipe stuff through various commands more or less constantly. I most often pipeline through awk, sed, sort, uniq, cat -n, etc. I have a back-burner project to write a meta-editor that works by pipelining and maintains a whole persistent undo-redo history.
[1] https://learn.microsoft.com/en-us/previous-versions/visualst...
contrast that to applications written for silverlight, activex, or flash
with respect to gtk 1, you sort of have a point, but gtk 2 was released in 02002, and it's usually not hard to port gtk 1 apps to gtk 2 (and almost all of them have already been ported). and i'm not sure what you mean about 'old kde'
free software licenses provide strong legal protections to users to do whatever is necessary to maintain and extend the software they depend on and share that with others, and in practice they do, and the consequence is that the hype cycle is much slower and less destructive
I am glad I am not the only one who hit this roadblock with Elasticsearch. It felt like always trying to play catch up.
CTO's change. They started replacing it with a "proper" ERP system around the time I left and it's been nearly 6 years of pain. Joel spaketh: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
(As usual: of course you can break the rule, but first deeply understand the risk you're taking.)
sometimes you don't need fancy new stuff. Just learn the things very well at your disposal. Heck sed, awk and bunch of simple cli tools still work well on Big data sets :)
When I started I outsourced SQL to the DBA’s or an ORM. Not since that team! It’s been a semi-secret weapon for me because most people ignore it.
In general, looking back at old code I wrote it seems my solutions were better when I was more naive / less experienced, as I would often go for the immediately obvious and simple solution (which is the right one in 90 % of cases). Working many years in software development and reading HN seems to have made me more insecure regarding software, as I tend to over-engineer systems and constantly doubt / second-guess my technical decisions. So one thing I'm actively trying to do is to go back to using simpler approaches again, and caring less about perfect code.
It's because I've so often seen the cycle here of "X is brilliant" and then 2 years later "how we switched off X and saved millions of manhours!".
I find this as well. I also think that there is a sub-conscious fear as you become more senior that you need to justify that with more elaborate/complex solutions. In my experience there are also a lot of people in software who never come out of the other side of that view and constantly equate "complex" with "good". Being in an environment with lots of people like this makes it hard sometimes. Ultimately you need to trust yourself and do what you think best. If it goes wrong, at least you know you did it for the right reasons.
In many ways, that's what it's actually like when you've punched through and become a true expert in your field. Important problems are solved with an overnight sleep, a cup of coffee, and a few careful taps. By the time you get there you're insane, but at least you're offered both coffee and orange juice if you ask.
My hatred of the complex solutions is so deep that I just suffer through all of the commentary silently.
I mean, it could just be that your simple solutions have been missing something, maybe something crucial, or you lacked the understanding of the mindset of people loving their complex stuff, which presented a communication barrier.
When i was more naive, i'd just stick with the first solution that worked. Now, i find that i'm always worried that someone is going to try to input a 30000-line csv in my tool and that i must use the slightly faster way because it's the right thing to do.
One of my tools to prevent this has been the non-accepted answers from stackoverflow. I find that they are generally of similar quality to the accepted answer, but that because they are less tailored to the (necessarly) different problem, they fit less and have a lesser chance of being accepted despite being more useful to more people.
Recent example: I have a side project with Typescript on the backend and frontend which also uses an Audio Worklet, so it loads a JS file at runtime to be run in a separate process, isolated from anything else.
I also have a class which I need to use in all three mentioned pieces.
Three years ago I would spend hours trying to figure out how to make this work with the build system so as to not have duplicated code and maybe eventually arrive at a mostly working solution before the e.g. frontend framework maintainers update their build system version which may or may not break something.
This time I just copied the damn file everywhere - the Audio Worklet got the compiled JS output pasted at the start. It's a class, it works and I have maybe one idea what changes I could make there in the future at which point I'm just going to copy everything again.
Can be hard to decouple overengineered messes from Good Software: an idiot admires complexity, et cetera.
If you think Python 2->3 transition was ugly, you haven't been watching that slow-mo trainwreck.
Perl 5 is alive and well, and while not the most actively developed of languages still has a steady trickle of small improvements.
It's installable in all major linux distros and you can probably get code from 2 decades ago running without much hassle.
Most people would shudder at the thought of starting a new project in it, but if you need to keep a legacy codebase going the community have your back for many many years to come.