I find that the LLMs are good at the 'glue code'. The "here's a rather simple CRUD like program, please tie all of the important things together in the right way". That was always a rather important and challenging bit of work, so having LLMs take it of our hands is valuable.

But for the code where the hard part isn't making things designed separately work together, but getting the actual algorithm right. That's where I find LLMs still really fail. Finding that trick to take your approach from quadratic to N log N, or even just understanding what you mean after you found the trick yourself. I've had little luck there with LLMs.

I think this is mostly great, because its the hard stuff that I have always found fun. Properly architecting these CRUD apps, and learning which out of the infinite set of ways to do this are better, was fun as a matter of craftsmanship. But that hits at a different level from implementing a cool new algorithm.

So he explains OFDM in a way that implicitly does Amplitude shift keying.

I guess if you want to use different modulations you treat the complex number corresponding to the subcarrier as an IQ point in quadrature. So you take the same symbols, but read them off in the frequency domain instead of the time domain.

And I guess this works out quite equivalently to normally modulating these symbols at properly offset frequencies (just by the superposition principle)

If your value proposition is: do X, and then you have to take action against an open source competitor for doing X better, that shows that you were beaten at the thing you tried very hard at, by people with way fewer resources.

I can see why you would call that embarrassing.

The competitor is not "doing X better"; it's more complicated than that.

CC isn't just the TUI tool. It's also the LLM behind it. OC may have built a better TUI tool, but it's useless without an LLM behind it. Anthropic is certainly within their rights to tell people they can only integrate their models certain ways.

And as for why this isn't embarrassing, consider that OC can focus 100% of their efforts on their coding tool. Anthropic has a lot of other balls in the air, and must do so to remain relevant and competitive. They're just not comparable businesses.

> CC isn't just the TUI tool. It's also the LLM behind it.

No, Claude Code is literally the TUI tool. The LLMs behind are the models. You can use different models within the same TUI tool, even CC allows that, regardless of the restriction of only using their models (because they chose to do that).

> consider that OC can focus 100% of their efforts on their coding tool.

And they have billions of dollars to hire full teams of developers to focus on it. Yet they don't.

They want to give Claude Code an advantage because they don't want to invest as much in it and still "win", while they're in a position to do so. This is very similar to Apple forcing developers to use their apps because they can, not because it's better. With the caveat that Anthropic doesn't have a consolidated monopoly like Apple.

Can they do that? Yes.

Should they do that? It's a matter of opinion. I think it's a bad move.

Is it embarrassing? Yes. It shows they're admitting their solution is worse and changing the rules of the game to tilt it in their favor while offering an inferior product. They essentially don't want to compete, they want to force people to use their solution due to pricing, not the quality of their product.

Claude Code is more than the TUI, it's the prompts, the agentic loop, and tools, all made to cooperate well with the LLM powering it. If you use Claude Code over a longer period of time you'll notice Anthropic changing the tooling and prompts underneath it to make it work better. By now, the model is tuned to their prompts, tools etc.

Sorry to hijavk, but why are drones still on electric power? I'd expect some kind of air breathing engine to be manufacturable at low cost if it only has to function for a single flight. Especially for interceptor drones the speed is valuable. But for all types of drones the extra range is also highly valuable.

Are you perhaps reading a personal advice in a paper, disliking the advice, and then finding that due to the experimental design, it doesn't work on you. And then, rather than concluding the paper didn't intend to inform your personal routine, instead conclude that the paper was badly designed? Or to put it differently. Have you considered how many people live in a way you would never consider close to acceptable?

Because your points make sense but it feels like you are arguing against a bit of a strawman, or arguing for a mostly ideal situation rather than current reality?

For overweight and understrength people, is it not very valuable to know that they don't need the extra steps of resistance training to see real improvement in strength and fitness?

This doesn’t look like a particularly charitable interpretation of my comment, although my interpretation of the article isn’t either, so it’s only fair.

And no, I am not looking for a personal fitness advice in scientific research anymore (too late for that), but am rather trying to see its applicability to others, as per my understanding of those others around me.

Most people in the developed world aren’t 22-year old males. A significant part of the population is comprised of the elderly or middle-aged, a lot of those people have pre-existing injuries due to under- (too sedentary) and over-use (blue collar work, youth sports). Approaching physical fitness in those groups has its its own set of requirements and limitations, and I believe that in many cases resistance training is a more safe and efficient choice.

Not saying that the youth and children are unimportant, but typically they are already well covered by the organized sports and pt classes in schools and universities, unlike the adults.

My opinion is that the study is both badly designed (likely in a way to make it easier to implement) and is not applicable to the majority of the population.

That's why someone suggested a non samesite cookie for reads and a samesite cookie for requests with side effects.

CSRF is mostly about causing side effects, not about access to information. And presumably just displaying your landing page should not have side effects, even when doing authenticated server side rendering. At least no side effects other than creating logs.

No, the program should take care to enable TCP_NODELAY when creating the socket. If the program gets passed a FD from outside it's on the outside program to ensure this. If somehow the program very often gets outside FDs from an oblivious source that could be a TCP socket, then it might indeed have to manually check if it really wants Nagle's algorithm.

I've been trying to convince others of this, and gotten very little traction. One interesting response I got from someone very familiar with the Tamarin prover was that there just wasn't enough example code out there.

Another take is that LLMs don't have enough conceptual understanding to actually create proofs for the correctness of code.

Personally I believe this kind of work is predicated on more ergonomic proof systems. And those happen to be valuable even without LLMs. Moreover the built in guarantees of rust seem like they are a great start for creating more ergonomic proof systems. Here I am both in awe of Kani, and disappointed by it. The awe is putting in good work to make things more ergonomic. The disappointment is using bounded model checking for formal analysis. That can barely make use of the exclusion of mutable aliasing. Kani, but with equational reasoning, that's the way forward. Equational reasoning was long held back by needing to do a whole lot of pointer work to exclude worries of mutable aliasing. Now you can lean on the borrow checker for that!

Another cool tool that’s being developed for rust is verus. It’s not the same as Kani and is more of a fork of the rust compiler but it lets you do some cool verification proofs combined with the z3 SMT solver. It’s really a cool system for verified programs.

I had a look, and it seems cool. But it doesn't seem to do the thing I love about Kani: work with only very partial annotations, only proving the annotations and being a very light lift on code not relevant for the annotations.

I don't think the parent post is complaining that academics are writing proposals (e.g as opposed to people with common sense). Instead, it seems to me that he is complaining that academics are writing proposals and papers to impress funding committees and journal editors, and to some extend to increase their own clout among their peers. Instead of writing to communicate clearly and honestly to their peers, or occasionally to laymen.

And this critique is likely not aimed at academics so much as the systems and incentives of academia. This is partially on the parties managing grants (caring much more about impact and visibility than actually moving science forwards, which means everyone is scrounging for or lying about low hanging fruit). It is partially on those who set (or rather maintain) the culture at academic institutions of gathering clout by getting 'impactful' publications. And those who manage journals also share blame, by trying to defend their moat, very much hamming up "high impact", and aggressively rent-seeking.

Yes, thank you, exactly. It’s a culture and systems issue. Thank you for clarifying a post I wrote in the early morning while waiting for my baby to fall back to sleep!

Linux is not a smart target. But OpenOffice, nextcloud, postfix, those are much easier targets for developer coercion to compromise widely installed software that is important for "linux on the desktop". Ah and ofcourse also the desktop environments, and perhaps systemD are all in a privileged position with much less eyes on.