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 believe most people don't want AI because I read the Pew Research report linked by the parent comment, which indicated most non-experts don't want AI. That report has a pretty large sample size, the methodology seems sound, and Pew is an organization that's historically pretty good at studying this sort of thing.
Obviously one report is not the end of the discussion. And if more research is done that indicates that most people really are interested in AI, I'll shift my beliefs on the matter.
I was interested in that 400 million weekly user number you posted, so I did a little digging and found this source [1] (I also looked through their linked sources and double checked elsewhere, and this info seems reasonably accurate). It seems like that 400 million figure is what OpenAI is self-reporting, with no indication how that number is being calculated. Weekly user count is a figure that's fairly easy to manipulate or over-count, which makes me skeptical of the data. For example, is this figure just counting users that are directly interacting with ChatGPT, or is it counting users of services that utilize the ChatGPT API?
In addition, someone can use ChatGPT while having a neutral or negative opinion on it. My linked source [1] indicates that around 10 million people are actively paying for a ChatGPT subscription, which is a much more modest number then 400 million weekly users. There clearly are a lot of people who use and like AI, but that doesn't mean the majority of the population feels positively about it.
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.