Regardless of whether they've added them yet, the target audience of Threads is advertisers. They're trying to offer a sanitized version of Twitter that is ultimately boring and soulless just like Facebook
The reason is pretty much irrelevant, either engagement on Twitter is artificially lower because of algorithm shenanigans, or because it's becoming a ghost town of abandoned accounts and spam bots. Neither option is a compelling reason to stay on Twitter
This may be technically true on a long enough timeline, but COBOL is still the backbone of the financial sector even though companies have dumped millions into attempting to convert it to something new with limited success.
For sure, we can debate the timeline, we can debate what language will replace C++. The way I read stefanos82's reply is that they don't believe C++ code will ever be rewritten, which is obviously not true.
COBOL running the financial sector is a myth in my opinion. There are still companies running aspects of their business on it, but calling it the 'backbone' is an overstatement. If you tallied up lines of code by language in the sector, I would wager COBOL makes up less than 1%.
Yep, I've worked for two companies where Fortran handles all of a major department's business - in both cases it was buried deep under layers of more modern stuff... but it was hugely risky to change it so it stayed.
While the argument is generally correct, Fortran and COBOL aren't in the same league. Fortran is still being upgraded and has some use cases that are hard to achieve in another language. I've seen the Rust subreddit recommending use of old Fortran code with Rust, rather than rewriting it in Rust. Unlike most other languages like C++ and Rust, Fortran kept its scope mostly limited to numerical processing - making it still one of the best solutions to code highly parallel numerical algorithms in.
Fortran isn't surviving just because nobody wants to rewrite Fortran code. Unless you're talking about Fortran77 code.
Oh agreed - Fortran is much more alive than COBOL - but in both cases I think the Fortran had outstayed its welcome. I never saw one of the codebases but the one I did see was Fortran 77 I believe, and there were a lot of gotos and labels.
Most importantly, because having to fend off obnoxious assholes and sealions is not a desirable property of a social space. In no way is adding that an improvement. If I wanted more of that, I'd stay at work where at least I get paid to do the work. This is a lesson that Bluesky has learned from the ruins of Twitter.
And secondarily, because your proposition is clearly neither "earnest", "unbiased" nor "honest" and the invitation to "consider" it as if for the first time is laughable. You might need people to annoy, but they don't need you. You protest too much.
> this is HN, a bunch of computer programmers think they know more than <figure of authority>
And they are correct
At least on the programming part, having in mind the huge advances in computers since the Voyager was built.
Any professional computer programmer here knows more in their field than a programmer from 70's. A Voyager built today with similar resources would be much better, 100% guaranteed.
Voyager 1 was a fantastic machine done by a terrific team, but lets not pretend that the state of the art hasn't changed. Anybody with computer skills polished towards building a machine in 1977 would be basically unemployable for building a machine in 2024.
You might be surprised to read the papers written by those early software developers. They were writing in the late 1960's and early 1970's about fundamental issues most developers of today don't fully grasp.
You might think, for example "waterfall, ewwww", but if you go back and re-read the first paper on waterfall development, it makes clear that waterfall development is in fact an anti-pattern. How many here are stuck on "modern" teams that think waterfall is a good idea, and yet those clueless old folks had figured out it was a dead end 50+ years ago.
One of the most critical aspects of managing software development is Conway's law. For distributed scalable systems, if you aren't thinking about Amdahl's law you're just a hacker and not actually an engineer. Check the dates on those papers.
They built incredibly sophisticated systems using incredibly primitive building blocks. If you honestly think they couldn't ramp up on PHP or Python or k8s, you need to spend a bit more time around some actual badasses.
I seriously doubt that the average dev today knows more than the average dev in the 70s. In fact, I would happily wager money on it, if it were somehow provable one way or the other.
There are so many abstractions today that you don’t _have_ to know how computers work. They did.
Re: state of the art, you don’t need or want state of the art for building things that go into space, or underwater (closest analogue I can think of that I have experience in [operating, not coding for]). You want them to be rock-steady, with as close to zero bugs as possible, and to never, ever surprise you.
The average dev knows far far less today. Just how deeply people had to know hardware back then is a massive difference.
And if we look at the average dev today, most code is in the framework, or a node package, or composer package, and the average dev gets by via stack overflow or AI.
There are certainly devs that actually understand coding, but the average dev barely does. Most devs don't understand the underlying OS, the hardware, or externals such as databases at all. It's all abstracted away.
And coders back then had almost nothing abstracted away.
> Any professional computer programmer here knows more in their field than a programmer from 70’s
Programming for regimes with different constraints is…very different. In a very real sense, “their field” for most modern programmers isn’t even the same field as developing software for 1970s deep space probes, plus, the issue wasn’t even about software but about end-to-end building and launching space probes (that was both what the quote was about and the field of the Voyager project manager.
But thanks for demonstrating the kind of hubris that the post you were responding to described.
But this is about the overall engineering of Voyager, not just the programming. Also, I'm skeptical how much better modern hardware will fare in deep space conditions, considering the use of finer and more fragile electronics. Since you're talking about general people instead of specialists, also consider how the median software developer seem to focus less on correctness, reliability, and optimization, compared to the standards of spacecraft engineering.
1) It was sophisticated indeed, top of its game, but lets not lie to yourselves. We still have best engineers and better programmers today. Just to put things in context in that time we moved from "Pong" to "World of Warcraft".
And is not just software. Reducing an entire computer room to the palm of your hand but with better storage, graphics and computing power is basically black magic. I can't imagine what Voyager could do with a current Nvidia chip.
2) Just because people is not trained in some specific domain does not mean that they couldn't be motivated to do it. I bet that the people that built the Voyager didn't born with the instructions engraved in their brains. And if they learned, other people can also.
If I learned something after lurking HN for a lot of years is to never, ever, underestimate this community. This place stills keep surprising me in good ways.
> Also, I'm skeptical how much better modern hardware will fare in deep space conditions, considering the use of finer and more fragile electronics.
Since then, we had massive advantages in manufacturing. Maybe COTS parts aren't as usable in space as they were back then, but we can now easily manufacture something more resilient or, as a fallback, simply use those old parts. Also, basically all current electronics are designed to be and are used on earth ~100% of the time. Over-engineering it for use in space is just a waste.
> skeptical how much better modern hardware will fare in deep space conditions
Why? Deep space radiation is only 4x the dosage compared to LEO. Starlink satellites use modern tech and they've spent >10,000 collective years in space since we launched more than 2 of them. The whole "modern electronics are more fragile" issue is overblown. The CPUs are tiny and easy to shield. The MMICs use huge features that you can see with a normal microscope.
Where did you get the number of 4x from? It seems different than what I understand, but I don't have any sources handy.
"Modern electronics are more fragile" issue really is not overblown. One of my peers have tested different types of non volatile memory in LEO and the TLC NAND sample gets totally wiped by ionizing radiation within the first week. CPUs, while being mostly logic and less susceptible to low energy events, can still be easily destroyed especially if radiation causes latchup. MMICs and discrete devices have huge features in comparison yes, but the junctions still degrade notably under radiation.
From my opinion as someone working on LEO satellite hardware, it's easy to have opinions about stuff like correctness and reliability because it is not naturally intuitive and usually requires observation of many samples over a long time that it doesn't affect most engineers. However, I've definitely seen a strong correlation between the effort spent on correctness and reliability, and the success of missions.
What is Starlink’s failure rate? Genuinely asking; I don’t know. My point is that if it’s > 0, that’s a problem for something designed to go billions of miles away.
The longevity of Voyager has only a little to do with software engineering, and latest software engineering has even less to do with building spacecraft like Voyager.
If anything I expect modern software engineering to have significantly higher risks of failure than programmers of ye olde days.
Why? The first step today would be installing Discord[1], the second step would be updating code live 420 no scope[2], and the third step would be figuring out how many JavaScript abstractions are desired.
I think the pushback is b/c this falls on common stereotypes about modern software being bloated and unnecessarily fragile. Those are justified stereotypes often enough, but spacecraft software is such a different animal that it just doesn't really apply very often.
That's an authority argument, even if in this case a strong one. What you seem to be overlooking is, that merely from this one quote, we cannot conclude, whether that is really all of methodology that went into building the Voyager 1 and 2. So while it is a witty quote, it doesn't actually tell us much, without additional statement, that we don't need to look any further for other methods that were applied.
If they aren't profitable when taking into account their negative externalities than the owners are stealing from the rest of the world and they should go bankrupt. They'd probably figure out a better way to do business instead though
Even if true, which I'm skeptical of, social media sites don't have to be permanent. It's no different from any other service being enshittified, just use it until it sucks and then stop.
reply