No one. We should be on a hard money standard. The Fed shouldn't be able to socialize the impact of bad business decisions like what was recently done with Silicon Valley Bank using the BTFP. Sometimes consequences need to be realized, even at the cost of bad downstream impact to those indirectly involved. It's the only way for more resilient systems to arise since our current system interrupts important feedback mechanisms.
So… it’s a good thing that the design emperor is poached by Meta, yeah?
Funny enough, I never suffered this because my mouse pointer has always been configured to be comically large. So I had adapt with inaccurate click area for many many years due to my own cause.
Javalin was inspired by https://sparkjava.com/ which was inspired by Sinatra (which I think also inspired Express?).
Anyway, libraries like this were only really feasible after Java 8 because of the reliance on lambdas. Having to instantiate anonymous nested classes for every "function" was a total pain before that.
Kinda now that Java has lambdas, but still async in that disn't work as easily as JS, which is important. This is only recently starting to change with Project Loom.
Author here, we don't use generative AI for software development. We've been building since 2018, and our number one goal has always been ensuring our software remains maintainable.
Did you use the 'litmus' test suite? I found it very useful when building Fastmail's (perl) WebDAV file server implementation.
There were also a bunch of fun things with quirks around unicode filename handling which made me sad (that was just a matter of testing against a ton of clients).
As for CalDAV and CardDAV - as others have said, JMAP Calendars/Contacts will make building clients a lot easier eventually... but yeah. My implementation of syncing as a client now is to look for sync-collection and fall back to collecting etags to know which URLs to fetch. Either way, sync-collection ALSO gives a set of URLs and then I multi-get those in batches; meaning both the primary and fallback codepath revert to the multi-get (or even individual GETs).
I've tried that (with Sonnet 4.5 at least, not Opus) and Claude isn't good at code analysis because it's too lazy. It just grepped for a few things and then made the rest of it up.
I think the issue is mostly that it desperately tries to avoid filling its context window, and Anthropic writes system prompts that are so long it's practically already full from the start.
A good harness to read code for you and write a report on it would certainly be interesting.
Those two things aren’t mutually exclusive. It may be worthwhile to at least have Claude (or whatever LLM you favor) to look at the other libraries and compare it to yours. It doesn’t have to write the code, but it could point out areas/features you’re missing.
We know what we're missing (a lot, we didn't implement the full spec). We don't know what weird edge cases the clients/servers will have, and I would bet you decent money a LLM won't either. That's why manual testing and validation is so important to us.
I wouldn’t be so sure about the LLM not helping. The LLM doesn’t need to know about the edge cases itself. Instead, you’d be relying on other client implementations knowing about the edge cases and the LLM finding the info in those code bases. Those other implementations have probably been through similar test cycles, so using an LLM to compare those implementations to yours isn’t a bad option.
Because that’s what happened in the real world when generating a bunch of untyped Python code.
reply