12 Fs across 34 students is not statistically significant. Comparing the spring 2022 vs spring 2026 rates only works if the composition of the groups is similar (e.g. same % of students that previously failed the course), which seems dubious given the dramatically different sample sizes.
That doesn't mean there isn't a problem worth investigating. If I was a dean I'd certainly have some questions if I found out that 35% of students failed a class. But without knowing the specifics it's irresponsible to draw any conclusions about these 34 students with the limited data we have available.
Additionally, if someone is taking an intro class in the Spring, that's probably because they already failed it in the previous semester. While that doesn't guarantee that they'll fail again, it does make it more likely.
The main reason lithium batteries are used in cars and electronics is because they offer some of the best energy storage per kilogram. That's really important for something meant to be portable, but it's completely irrelevant for a large permanent installation.
> _However_, for the use cases that most developers or agents are looking for
What use cases are those? How did you determine that these are the use cases most developers/agents are looking for?
For me, git has a ton of features that I rarely use. But when I need them, I really need them. Any replacement that doesn't cover these edge cases is fundamentally incomplete and insufficient, even if it works fine 99% of the time.
> Sure, if you have a complete test suite for a library or CLI tool
And this is a huge "if". Having 100% test coverage does not mean you've accounted for every possible edge or corner case. Additionally, there's no guarantee that every bugfix implemented adequate test coverage to ensure the bug doesn't get reintroduced. Finally, there are plenty of poorly written tests out there that increase the test coverage without actually testing anything.
This is why any sort of big rewrite carries some level of risk. Tests certainly help mitigate this risk, but you can never be 100% sure that your big rewrite didn't introduce new problems. This is why code reviews are important, especially if the code was AI generated.
> Yeah, sure, and with LLMs you can do this, and you can do that. But if we're talking about languages and their features, relying on IDE features feels slightly off-topic.
Refacoring tools (such as renaming properties) have been supported by IDEs for decades. And in Typescript specifically, the language is designed with these tools in mind, which are developed and distributed directly by the Typescript team. For all intents and purposes, IDE integration using the Typescript language server is a feature of Typescript.
And if somehow these tools don't work, the compiler will catch it immediately! This means I can refactor with confidence, knowing any type issues will be caught automatically.
It seems like you're vastly overestimating the time and effort it takes to change types in Typescript. In my experience it's something that takes basically no time and effort, and has never caused me any issues or headaches.
In your Typescript example, the solution would be to use your IDE to refactor hosts to hostnames, a process that takes like 2 seconds. You might have problems if the change exists at a service boundry, but in that case I'd just put the transformation at the service boundry, and keep everything the same internally.
> Personally, I prefer to spend the extra time I get from dynamic languages to write proper unit tests that can actually ensure the absence of specific logic bugs, rather than further ossifying the architecture with static types while changes are still ongoing.
I'd argue static typing makes this much easier, because I know any input types (or output types from other components) will be enforced by the type system. So I don't need to bother writing tests for "what if this parameter isn't set" or "what if this function returns something unexpected". The type system handles all of that, which eliminated a lot of tedious boilerplate tests.
I don't find that dynamic typing reduces the number of places I need to update stuff. It just changes when the error occurs.
If I change the shape of some data (such as renaming object properties), I'll need to update all the code that used that data, regardless of the type system. Static typing just ensures that I catch those cases at compile time, not runtime.
IIRC Musk wanted to get an LBO, but wasn't able to find anyone willing to loan the money.
Keep in mind that a LBO is actually a good deal for the bank, because if the purchased company goes bankrupt, the bank can recoup their investment by liquidating the company.
However, that only works if there are assets to liquidate. This can include physical assets, valuable IPs, or favorable lease agreements. In other words, anything that someone else would want to purchase.
Twitter, being a website, doesn't have a whole lot of assets they could sell. Which meant that other collateral was required for Musk to secure financing.
Are there any examples where a company was purchased via a leveraged buyout and the company went on to be more profitable afterwards? Because the only examples I know of resulted in the purchased company going bankrupt fairly quickly.
If you want a deep dive into chess cheating, including a lot of wild stories, Sarah Z put out an entertaining Youtube video [1] a couple of months ago that explores the concept. It's a long video, but well worth the watch.
Nothing Hamas has done justifies what Israel is doing to Palestinian civilians, because collective punishment is a war crime. "But they did it first" is not a valid excuse, especially when trying to excuse mass starvation and bombing population centers.
The fact that there isn't a rail line from the airport to the strip is wild. It would simplify travel for tourists dramatically, and get a lot of hotel shuttles and taxis off the street. There's a reason why even cities with bad public transit usually have a line to the airport, and it's wild that Las Vegas doesn't have one.
You're right, and I realize my post implied that multiplayer was a complete non-starter on Linux, which isn't true. Kernel-level anticheat is mostly found in big, mainstream releases (especially competitive shooters). Of course, these games happen to be very popular, which gives them an outsized impact.
Personally, I know that the upcoming Battlefield 6 is making me question if I want to switch to Linux once Windows 10 support dies. For a lot of people, being able to play 99% of games on Linux doesn't matter if they can't play one specific game they enjoy. It's a situation that just sucks all around, and I don't see it getting fixed anytime soon.
The main hurdle for Linux gaming right now is kernel-level anticheat. Kernel-level anticheat is increasingly common in multiplayer games, and it does not play well with Linux. This makes it difficult to play new multiplayer games on Linux.
Of course it's easy to argue that kernel-level anticheat gives way too much system access for a simple video game. But it's currently the most effective form of anticheat, and I don't see it going away anytime soon.
But also that's been part of Wikipedia's website for years now, no special browser support necessary. And because it's tailored specifically to Wikipedia, it works great!
Page preview seems nice in theory, but I'm unconvinced it'll be that useful. Web pages just don't have a the level of standardization necessary to automatically grab a useful preview. And I don't think Firefox has a big enough pull to make that sort of standard.
But at that point wouldn't it be easier to just search the web yourself? Obviously that has its pitfalls too, but I don't see how adding an LLM middleman adds any benefit.
I've got to ask, do you play much chess? Because this post reads like you don't understand much about chess.
The issue with "solving" chess isn't that there isn't an objectively best move in every position. The issue is that calculating that move is functionally impossible for most positions. That's because chess gets exponentially more complicated the more pieces there are on the board. For example, there are around 26 million positions with 5 or fewer pieces, and over 3.7 billion positions with 6 or fewer pieces.
And most of those positions are distinct. This isn't like a Rubik's cube, where there are a lot of functionally identical positions. Any experienced chess player can tell you that a single piece placement can be the difference between a winning position, and a losing position.
And this complexity is what I love about chess! I love the fact that I can enter positions that no one has ever encountered before just by playing some chess online. I love the fact that deep analysis is possible, but that the sheer size of the possibility space means we can never truly solve chess. Chess strikes a perfect balance of complexity. Any simpler, and evaluating the best move would be too easy. Any more complicated, and evaluation becomes so difficult that it's hardly worth trying.
Which isn't to say that we can't build computers that are very good at chess. A person hasn't beaten a top computer in decades. Magnus Carlson is probably the greatest chess player to have ever lived, and you can run software on your phone that could easily beat him. But there's a wide gulf between "can beat every human alive" and "plays objectively perfect chess."
That doesn't mean there isn't a problem worth investigating. If I was a dean I'd certainly have some questions if I found out that 35% of students failed a class. But without knowing the specifics it's irresponsible to draw any conclusions about these 34 students with the limited data we have available.