Yeah it's the one place that crosses the triple point of water, not by a huge margin, but likely enough to trigger planetary protection concern.
But there's places like the araneiform terrain where you likely get much higher transient pressures, and maybe they create enough of a greenhouse effect to warm up before they burst through the CO2 ice crust. They'd be a great way for life to spread mechanically using those pressurized bursts.
Maybe Clevo, since they are more of an OEM producer for other brands meaning they don't control all the eyes on the hardware all the way to the sale point, i.e. to sneak things in.
Being slower than a compiled language is not saying much for an interpreted language. But it's slower than PHP which is a closer comparison, and PHP has had JIT for six years now.
Ruby has the reputation of being a very slow language, but Python has been slower still since Ruby jumped ahead with version 1.9, almost 20 years ago. Ruby also has had far more success with JIT compilers than Python has.
>Ruby also has had far more success with JIT compilers than Python has.
Ruby is on its third (I think?) JIT now? I'm a little surprised, given Ruby's reputation as a wacky "anything goes" language with a very complex grammar, and it makes me wonder why that is? Does it have to do with the design of the runtime itself more than the language semantics? Or is it more incidental, e.g. many popular ibs are C wrappers, already generates bytecode files, and so on.
The difference is that Ruby follow the BDFL model, and Ruby's BDFL was willing to allow people to experiment with in-tree development of JITs.
If the Python steering committee isn't willing to do the same, they'll probably won't get a working JIT any time soon. Developing a JIT externally, or even from a branch, is just too hard.
Getting a JIT right is hard work because time spent by the JIT is time not spent doing actual work, and finding the correct tradeoffs is very much an empirical problem.
And PHP is quite the hot mess. Always has been, really. See the security issues over the years, including the most recent for example. Meanwhile I've never seen any serious issues for Python that's triggered mass required fixing. There's something to be said for moving carefully and ensuring things aren't broken to the best of one's ability, which is the SC's purpose.
Are you helping me to prove my point? I see 156 results, with 1 in 2023 and the rest before that. Meanwhile there are 801 results with at least a dozen in 2026 for PHP[0], and we still have 2 more months to go.
Not at all. I specifically stated "serious issues for Python that's triggered mass required fixing", ie. it was so bad that there were public notices for users to update ASAP. The closest thing I can find is CVE-2022-34265, and that's in Django, not Python itself.
Agreed. And Python usage is far more diversified. But I fail to see the relevance of usage to a language being stable vs ridden with issues. Well, beyond that one would expect the one being so many things to so many different communities would have more issues than the other used by a single community for a single purpose.
Captioning and subtitling has taken a direct hit from AI tools, but about half of it is from clients severely reducing their quality standards.
Back in the early 1990s the widely referenced BBC guidelines required 99.9% accuracy overall. Nowadays it is assumed that viewers will be used to and understanding about frequent errors, and that you don't need to take pride on your product to keep them in your platform.
I've been watching quite a few old BBC series on iPlayer and something they did a lot back then was paraphrase the dialogue to reduce the length of the subtitles. They tended not to have spelling mistakes or comprehension errors, but they weren't accurate.
That was often a "mechanical" issue with analog captions. You could send only 4 bytes of caption content with each frame (and some were control codes) and the display only fit 32 characters per line. If several people were talking over each other, talking rapidly, or there were on screen texts that needed captioning too, they'd make compromises to try and fit everything.
Then, because of legacy broadcasts and backwards compatibility, that carried over well into the 2010s.
I feel back in the day you still saw ads that were kind of creative and there was a certain glamour around being the one brand with the best ads.
Current ones are outright unpleasant, the "make the viewer feel bad about something" kind or directly spam folder level of scammy. Nobody takes pride anymore on their advertising.
Always puzzled me how much money can possibly be in trying to optimize sales by some low digit percentage points, versus how much is sacrificed for it.
The problem is that advertising works! I hate that it works!
Marketing and advertising aren't the same thing but I swear both sides of that coin have devolved via some process of carcinization where their claws emerge from the darkness everywhere people gather. Especially places where those claws are inappropriate and unwanted and yet it still works.
Yeah, people in our line of work tend to look down on it and don't understand it because we discover things more manually. But that's not the case with the vast majority of people. Advertising works and it works really, really well.
We do not "discover things more manually", whatever that means. Statistically, the more someone thinks they're not affected by advertising, the more they're actually affected by advertising in reality.
It works only to a point and only if the product has not degraded/enshittified. Retention is often terrible for bad products/service. Humans are not robots. Most people think about what they are purchasing and no amount of ads can fix it if the product/service is bad.
This is one angle of the productivity story. You don't have any sort of plausible deniability covering all these bugs, test cases etc. when they are comprehensively discoverable by tooling. It's like having typing bugs on a strongly typed language with static analysis, you just can't make a lot of excuses.
So that's one measure of extra time that will be spent on every single feature, where in the past things would've been rolled out in a more barebones state. It's better overall, but is it going to be perceived as being more productive?
Not in my experience. I've pointed agents like Claude at existing codebases I work on, and it does a pretty solid job at identifying bugs. It's not garbage or slop at all.
There's a big difference between randos getting agents to hallucinate bug reports on GitHub, vs. when your own internal workflow of LLM-assisted code review is identifying real, legitimate problems in your new features.
This totally matches my experience. It's actually kind of insane how well LLM's like Claude are able to find edge cases, race conditions, overflows, states you didn't think could be reached. It really makes you think about code quality in a whole new way. Becoming aware of so many potential bugs when you write the code, vs. finding out from users over the coming months/years -- it forces you to really consider the costs of quality all at once in a way that simply wasn't possible before.
There’s plenty of things you can very deterministically verify — if the LLM writes a test case which causes an ASan violation, you probably have a bug; if the LLM writes a test case which run the various corruption checking tools and they find corruption then you either have corruption or you have a bug in the corruption checking tool; etc.
There’s plenty of ways in which you can guide LLMs, and sandbox them, to get a much higher hit rate.
And that’s before the increase of validity of bugs compared with a year ago — we’re past the peak of slopageddon, and maybe even at a point where a higher percentage of security bugs reported are valid than was the case pre-LLMs.
Opus continues to tell me that my API is missing a `/ready` route that a smoke test can check against. I assume it’s part of its memories, but it’s now 3 or 4 weeks that it won’t let go of that whenever tasked with test design.
reply