It's an artifact of the problem that they don't show you the reasoning output but need it for further messages so they save each api conversation on their side and give you a reference number. It sucks from a GDPR compliance perspective as well as in terms of transparent pricing as you have no way to control reasoning trace length (which is billed at the much higher output rate) other than switching between low/high but if the model decides to think longer "low" could result in more tokens used than "high" for a prompt where the model decides not to think that much. "thinking budgets" are now "legacy" and thus while you can constrain output length you cannot constrain cost. Obviously you also cannot optimize your prompts if some red herring makes the LLM get hung up on something irrelevant only to realize this in later thinking steps. This will happen with EVERY SINGLE prompt if it's caused by something in your system prompt. Finding what makes the model go astray can be rather difficult with 15k token system prompts or a multitude of MCP tools, you're basically blinded while trying to optimize a black box. Obviously you can try different variations of different parts of your system prompt or tool descriptions but just because they result in less thinking tokens does not mean they are better if those reasoning steps where actually beneficial (if only in edge cases) this would be immediately apparent upon inspection but hard/impossible to find out without access to the full Chain of Thought. For the uninitiated, the reasons OpenAI started replacing the CoT with summaries, were A. to prevent rapid distillation as they suspected deepSeek to have used for R1 and B. to prevent embarrassment if App users see the CoT and find parts of it objectionable/irrelevant/absurd (reasoning steps that make sense for an LLM do not necessarily look like human reasoning). That's a tradeoff that is great with end-users but terrible for developers. As Open Weights LLMs necessarily output their full reasoning traces the potential to optimize prompts for specific tasks is much greater and will for certain applications certainly outweigh the performance delta to Google/OpenAI.
> Lately, I see a lot of drivers who turn on their brights and just leave them on and this includes cars with the older halogen and even incandescents. This is a change in behavior. Something has changed in how we use headlights, and not for the better. Historically, drivers behaved very differently. When "brights" were actually rare and reserved for dark stretches of highway, you'd dim them the moment you saw another car approaching. Often that meant switching to low beams when the other vehicle was more than a thousand feet away. Courtesy and safety were the norm. The technology has come a long way. Early headlights in the 1880s burned oil or kerosene. Acetylene gas lamps followed, and electric lighting appeared in the early 1900s. For decades after 1940, U.S. regulations froze headlight design into a two-lamp, 7-inch sealed-beam configuration. That rule unintentionally limited improvements in beam shape and brightness. Only in the 1970s and 1980s did halogens and replaceable-bulb designs become widely permitted, which opened the door to much brighter and more varied systems. Then came the xenon era in the late 1990s and early 2000s. High-Intensity Discharge (HID) lamps felt futuristic at the time, but they were also infamous for their glare, especially when installed into housings not designed for them. This is where "riced-out" aftermarket kits made things worse. People would drop cheap HID or later LED bulbs into reflector housings built for halogen. The result was scattered, unfocused light that looked bright from the driver's seat but created a wall of glare for everyone else. That trend never fully went away. Today, Federal Motor Vehicle Safety Standard 108 (FMVSS 108) governs headlamps. It sets minimum performance requirements and basic definitions for high and low beams, but it does not impose strict limits on maximum brightness or color temperature. The old "300 candlepower requires a dimmer switch" phrasing still floats around, but there is no tight federal cap on lumens or color warmth. States can enforce aiming requirements, but in practice they rarely do. Nobody is pulling cars over with a light meter. Modern LEDs changed the equation again. They're efficient, crisp, and extremely "white" (actually "blue") which makes them appear even brighter to human eyes at night. Complaints about perceived glare have been climbing for years, and there's no shortage of real-world examples of it in the wild. https://old.reddit.com/r/fuckyourheadlights/ Automakers tried to help with automatic high-beam systems, but these were designed to detect oncoming headlamps, not pedestrians. If you're walking your dogs at night, the system may not dim because it "sees" nothing to react to. Many drivers rely on auto mode and never manually intervene, so they cruise around blasting full brightness without realizing it. My workaround is simple. I carry a high-power flashlight and give a quick shine toward cars running high beams. The auto-dimmer interprets it as another vehicle and drops to low beam. It also alerts the driver that something is off. Plenty of neighbors have told me they had no idea their headlights weren't dimming. (Teslas are by far the worst offenders.) This is the flashlight I use: https://www.costco.ca/infinity-x1-7000-lumen-flashlight.product.4000368630.html
My other pet peeve is the opposite - they've got LED daytime running lights, and use those instead of headlights. They're driving around at 11pm with no taillights and abysmal forward lighting, but there's enough of a glow from the DRLs that they assume their lights are on. Or worse, they're accustomed to "automatic" lights and don't even know where the switch is, so they're driving around at dusk or in fog, rain, or snow in a white, gray, or black vehicle without their lights on. I have also been tempted to purchase digital billboard space, but not on the side of the road. I want LED signs on my roof rack (one forward, one back) with column or two of buttons on the dash to call up a slate of messages: 1. TURN YOUR BRIGHTS OFF! BLUE MEANS BLINDING. 1b. OW! YOUR HEADLIGHTS ARE MISALIGNED. 2. TURN YOUR HEADLIGHTS ON! THOSE ARE DRLs. 3. TURN LIGHTS ON TO BE SEEN EVEN IF IT'S NOT DARK. 4. MY SAFE FOLLOWING DISTANCE IS NOT A SPOT FOR YOU. 5. YOU ARE TAILGATING. I WILL NOT SPEED FOR YOU. 6. YIELD DOES NOT MEAN STOP. 7. I AM ZIPPER MERGING, NOT CUTTING THE LINE. 8. DRIVE CAREFULLY! I JUST SAW A DEER. 9. GO AHEAD, I SEE YOU. 10. YOU HAVE A PROBLEM WITH YOUR VEHICLE, PULL OVER. 11. THANK YOU! Plus a few spare slots to be implemented as needs arise. I've been unimpressed with the automatic high-beams on my wife's newer Toyota and on other rentals I've driven, they usually depend on a direct line-of-sight to the other car's headlights, which means they stay on just long enough to hit the windshield of another car cresting a hill and blind them. Then they courteously turn off a few camera frames and vision analyses after the low beams become visible. If a __competent__ driver is controlling the high/low beams manually, they'll see the headlights of the other car illuminating the trees and such and turn off the high beams a couple critical seconds earlier. But I admit that the automatic systems are miles better at managing it than the __incompetent__ drivers who are all too common.
I love electromechanical arcade games. My father mentioned one from his youth that had you manning an anti-aircraft gun and shooting down incoming WWII fighters. This would have been made in the 1950s or maybe even the late 40s, given the time frame at which he played it. I managed to find a game that was conceptually similar, but certainly not the game my father played. It was Sky Hawk by Nintendo, made in 1976: https://m.youtube.com/watch?v=2GMAWtqJr3w The way it works is there are actually three clips of footage: plane attacking, plane exploding, and a light spot indicating the target area needed to register a hit. The latter two are shown on the bottom half of the film frame at different times. A mirror usually reflects the top half of the film, showing the "attacking" footage, toward the screen where the player can see it. However, the gun is mechanically linked to a light sensor pointed at the bottom half, and if it picks up the light spot in the "light spot" footage, a hit will be registered. When the "plane blowing up" footage starts, the mirror will pivot to reflect that to the screen instead, and you will be awarded a point. It was an ingenious setup that required no computers to operate. It was pure mechanics and optics. Another difference is, Sky Hawk used footage of R/C model planes to simulate the incoming fighters. From my father's description, the game he played used footage of actual fighters taken during actual WWII engagements. But the idea is the same, and it makes me wonder if a similar mirror setup were used in his game as well.
I grew up on Scarborough Beach, in Perth, Western Australia, during the 70's. This was basically peak Australian beach culture - everything you could want in a sunny day at the beach - bikini's, surf, sharks, hamburgers, the lot. Bike gangs and surf nerds, newly returned from Vietnam, beating each other to smithereens in the parking lot while the girls watched on. I can still smell the sun cream lotion, and remember the smell of my Dads hamburger grill, erected in the ruins of the famous 50's "Snake Pit" haunt, replete with ghosts and memories of dances gone by, of rock and roll been and gone, replaced with stoner rock and KISS or Abba, depending on your thing.. I have muscle memory buried deep for the regular cleaning of the onion slicing machine, the giant bottles of mayo I had to refill, every single day. The beetroot stains and the harvesting of the 'crispies' from the competing deep fryer shop, "Peters by the Sea", who sold us kids a pack of the junk for 10c a bag, and which is the only remaining survivor of the era, still slinging buns even today .. The esplanade in those days was basically a sullen row of shops, one after the other offering beach-goers refreshments and entertainment, luring every customer in with the promise of fun and cheer .. and every single one of those 8 or so shops had a small Cold War going on against the other, for entertainment devices. At one end, there was an air-hockey paradise with a side row of electromechanical games, one of which was indeed Killer Shark, along with another airplane bombing game that ran on a big map, rolling underneath the camera through which the player would view and send down their 'light bombs' as we kids referred to them, way back then. My first impression of "Germany", as it were, rolling endlessly in some kind of ethereal, hypnotic landscape. Pinballs and stuff too, almost an overwhelming selection of blinking chaos into which to pour coins. Each shop had its speciality - my Dads' place (MINDERBINDERS, in case there are any sand gropers about) specialised in pinball and stag films in a back room, for those who knew the secret handshake. Killer Shark was great - it was so clearly a mechanical game that you could never beat, but on occasion the odd punter would score a free game or so. Even more of a treat, the proprietors would sometimes start off the games with 20 credits or so, just sitting there, to attract the teens. There was another electro-mechanical, ocean themed game, something like "SPEAR HUNT", which offered players a few snapper and some stingrays upon which to direct their sun-kissed ire, should they have a remaining 20c or two to waste. I loved that era of my life (was just a boy starting school) .. 1976 .. the brand new "Breakout" appears suddenly, and it immediately soaked up all the coins from the neighborhood. I remember seeing the service guy open up Breakout and all the coins just came pouring out .. and then, slowly, the rest of the strip went video and computer, Space Invaders arrived, and the electromechanical games slowly phased out, becoming ever more unpopular and under-used as the year rolled over. My first memory of Killer Shark was fun - my last, sadness, as its faded exterior got loaded onto the truck to be replaced by something brighter, flashier, more challenging. Soon enough there were only 'computer games' and pinballs, and all those delicate machines got replaced, one by one. Eventually, the esplanade itself got replaced with a modern monstrosity, and the era ended with the fervent twang of the 80's arriving, power synth chords and all. But I still remember the squealing joy of a player, spearing themselves a shark, only to be pissing themselves with laughter/fearjoy once the shark 'recovered' and made them face a frontal attack. It was, somehow, cathartic. Until a real shark showed up in the surf and bit a kids leg off, during prime surf hour. That made me the computer kid I still am, today.
> No runtime cost in production is the goal Clojure's persistent data structures are extremely fast and memory efficient. Yes, it's technically not a complete zero-overhead, pragmatically speaking - the overhead is extremely tiny. Performance usually is not a bottleneck - typically you're I/O bound, algorithm-bound, not immutability-bound. When it truly matters, you can always drop to mutable host language structures - Clojure is a "hosted" language, it sits atop your language stack - JVM/JS/Dart, then it all depends on the runtime - when in javaland, JVM optimizations feel like blackmagicfuckery - there's JIT, escape analysis (it proves objects don't escape and stack-allocates them), dead code elimination, etc. For like 95% of use cases using immutable-first language (in this example Clojure) for perf, is absolutely almost never a problem. Haskell is even more faster because it's pure by default, compiler optimizes aggressively. Elixir is a bit of a different story - it might be slower than Clojure for CPU-bound work, but only because BEAM focuses on consistent (not peak) performance. Pragmatically, for the tasks that are CPU-bound and the requirement is "absolute zero-cost immutability" - Rust is a great choice today. However, the trade off is that development cycle is dramatically slower in Rust, that compared to Clojure. REPL-driven nature of Clojure allows you to prototype and build very fast. From many different utilitarian points, Clojure is enormously practical language, I highly recommend getting some familiarity with it, even if it feels very niche today. I think it was Stu Halloway who said something like: "when Python was the same age of Clojure, it was also a niche language"
 Top