Skip to main content

Representative Line: Springs are Optional

3 months 3 weeks ago

Optional types are an attempt to patch the "billion dollar mistake". When you don't know if you have a value or not, you wrap it in an Optional, which ensures that there is a value (the Optional itself), thus avoiding null reference exceptions. Then you can query the Optional to see if there is a real value or not.

This is all fine and good, and can cut down on some bugs. Good implementations are loaded with convenience methods which make it easy to work on the optionals.

But then, you get code like Burgers found. Which just leaves us scratching our heads:

private static final Optional<Boolean> TRUE = Optional.of(Boolean.TRUE); private static final Optional<Boolean> FALSE = Optional.of(Boolean.FALSE);

Look, any time you're making constants for TRUE or FALSE, something has gone wrong, and yes, I'm including pre-1999 versions of C in this. It's especially telling when you do it in a language that already has such constants, though- at its core- these lines are saying TRUE = TRUE. Yes, we're wrapping the whole thing in an Optional here, which potentially is useful, but if it is useful, something else has gone wrong.

Burgers works for a large insurance company, and writes this about the code:

I was trying to track down a certain piece of code in a Spring web API application when I noticed something curious. It looked like there was a chunk of code implementing an application-specific request filter in business logic, totally ignoring the filter functions offered by the framework itself and while it was not related to the task I was working on, I followed the filter apply call to its declaration. While I cannot supply the entire custom request filter implementation, take these two static declarations as a demonstration of how awful the rest of the class is.

Ah, of course- deep down, someone saw a perfectly functional wheel and said, "I could make one of those myself!" and these lines are representative of the result.

[Advertisement] Keep all your packages and Docker containers in one place, scan for vulnerabilities, and control who can access different feeds. ProGet installs in minutes and has a powerful free version with a lot of great features that you can upgrade when ready.Learn more.
Remy Porter

With Starship Flight 10, SpaceX Prioritized Resilience Over Perfection

3 months 3 weeks ago
An anonymous reader quotes a report from TechCrunch: SpaceX has long marketed Starship as a fully and rapidly reusable rocket that's designed to deliver thousands of pounds of cargo to Mars and make life multiplanetary. But reusability at scale means a space vehicle that can tolerate mishaps and faults, so that a single failure doesn't spell a mission-ending catastrophe. The 10th test flight on Tuesday evening demonstrated SpaceX's focus on fault tolerance. In a post-flight update, SpaceX said the test stressed "the limits of vehicle capabilities." Understanding these edges will be critical for the company's plans to eventually use Starship to launch Starlink satellites, commercial payloads, and eventually astronauts. When the massive Starship rocket lifted off on its 10th test flight Tuesday evening, SpaceX did more than achieve new milestones. It purposefully introduced several faults to test the heat shield, propulsion redundancy, and the relighting of its Raptor engine. The heat shield is among the toughest engineering challenges facing SpaceX. As Elon Musk acknowledged on X in May 2024, a reusable orbital return heat shield is the "biggest remaining problem" to 100% rocket reusability. The belly of the upper stage, also called Starship, is covered in thousands of hexagonal ceramic and metallic tiles, which make up the heat shield. Flight 10 was all about learning how much damage the ship can accept and survive when it goes through atmospheric heating. During the tenth test, engineers intentionally removed tiles from some sections of the ship, and experimented with a new type of actively cooled tile, to gather real-world data and refine designs. [...] Propulsion redundancy was also put to the test. The Super Heavy booster's landing burn configuration appeared to be a rehearsal for engine failure. Engineers intentionally disabled one of the three center Raptor engines during the final phase of the burn and used a backup engine in its place. That was a successful rehearsal for an engine-out event. Finally, SpaceX reported the in-space relight of a Raptor engine, described on the launch broadcast as the second time SpaceX has pulled this off. Reliable engine restarts will be necessary for deep-space missions, propellant transfers, and possibly some payload deployment missions. [...] The next step is translating Flight 10 data into future hardware upgrades to move closer to routine operations and days when, as Musk envisioned, "Starship launches more than 24 times in 24 hours."

Read more of this story at Slashdot.

BeauHD