I had a couple of courses that had open-book exams, where you could bring _any_ material you wanted. Any books, notes, equipment, really anything you wanted. The exam was still hard, because it focused on defining problems. Knowing what question to ask. This is still the hardest problem, even with LLMs. My guess is that most teachers don't like open-book exams, because they are hard to make. But maybe LLMs could help with this too. There is no putting the genie back in the bottle anymore, and restrictions are only going to be effective for dumb cheaters. You have to create exams which make the smart cheaters do actual work.
I mean... I get it. It's annoying. But the outrage is getting old. LLMs hallucinate. It's an unfixable problem. We're going to have to get used to it.
In all fairness, fake reviews and just people lying on the internet has always been a thing. The fact that gemini once in a while gets something wrong is just not very upsetting anymore IMO.
I get the usefulness of allocators, I just don't see them as useful enough where I'd pick zig over another established systems programming language. Do you have an example?
I really love everything about zig except the language itself. The governance, the culture, all of it seem really cool, but reading https://ziglang.org/learn/why_zig_rust_d_cpp/ I still don't get _why_ I would use it. To an untrained eye, it seems like go, but with manual allocation. Or an imperative-only rust. Like it has some features of all the languages it competes with, but not the ones that would make me reach for them.
What do people use zig for, and why zig and not one of the others?
yeah, what I feel happens is that priorities get a lot harder. I'm two courses and a project away from a master in robotics, but when you have a steady, well-paying job already and a spouse and kid, it's gets really hard to motivate exactly _why_ you want that degree.
as much as I feel for the maintainers here, this sort of (again) puts the spotlight on our collective dependence on a handful of individuals basically working for free _with no backup_.
Most normal organizations stagger vacations to avoid these things. Most normal organizations _have_ to do this, because their customers require it. Here, we're all customers of curl, but not really. It's a weird, IMO unhealthy, twilight zone that isn't good for anybody.
And it surprises - and saddens - me that not even friggin curl has the financial muscles to have somebody on-call for one month...
this resonates with me, but fortunately one difference between LLMs and rockstar developers, is that LLMs will at least _try_ to explain what they are doing, and why something has to be certain why. I've gotten quite a lot of mileage from being a five-year-old with Claude and just asking "why" until I'm satisfied
I think the missing piece here is nuance. Of course there are certain tasks that software engineers do that will be replaced. But will AI replace _everything_ a software engineer does?
The most difficult bit about software engineering is to keep a mental model of _everything_ a product does with varying levels of granularity. The way I see LLMs fail at my company the most is that they are very good at the big picture, and very good at the very small picture, but have difficulty moving between those two levels. And especially when changes have occurred or accumulated over time. Most of all production systems have an extremely long tail of gotchas which are only managed by people who have been around for long enough to have some kind of deep storage access in their heads to those little tidbits of information.
And I think current LLMs might be fundamentally incapable of replacing that.
Given Boeings later history this is pretty chilling...