I've found swearing at a model to be quite effective in getting it to rethink and correct its mistakes. This seems to apply across Codex, Claude, Qwen, and Gemma/Gemini.
I don't know if the model is picking up on a "need to lock in and be more rigorous" signal, or if the model providers are routing to smarter models if they detect a frustrated user. But if a model keeps making the same mistakes, swearing at it often helped kick it out of a glut and onto the right track.
Can you elaborate on this? I'm seen estimates of ~1.5bit per English letter, and tokens encode a lot more than that - sometimes full words, with multimodal even more. If KV cache embedding are storing more than just simple tokens but entire concepts with context and nuance, that'll bump the entropy up quite quickly.
VPS comes at the cost of potential for oversubscription - even from more reputable vendors. You never really know if you're actually getting what you're paying for.
One annoyance (I don't know if they've since fixed it) was that Docker Hub would count pulls that don't contain an update towards the rate limit. That ultimately prompted me to switch to alternate repositories.
How well do we understand the tokenization for Claude? I'd posit that the exact human-representation of this markup is likely irrelevant if it's all being converted into a single token.
Code length will itself become a problem. The instruction cache is limited in size and often quite small. Bloating instruction counts with lots of duplicated code will eventually have a negative effect on performance.
Ultimately, there's too many factors to predetermine which approach is faster. Write clean code, and let a profiler guide optimizations when needed.
Additionally, so long as we can be sure the human's output is not actively adversarial, we can xor it into the entropy pool. Entropy can only increase this way.
I'm reminded of a diagram from the pitch doc for the original Diablo [0] that made its rounds across the web recently. The dungeon/town split was particularly sharp back then, but the broad design has stuck with modern ARPG design, either in the form of safe zones around town or explicit town zones.
A lot of this seems to be due to modern multiplayer design, with shared town instances and (usually) private dungeon/outside instances.
> Getting on the public suffix list is easier said than done [1].
Can you elaborate on this? I didn't see anything in either link that would indicate unreasonable challenges. The PSL naturally has a a series of validation requirements, but I haven't heard of any undue shenanigans.
Is it great that such vital infrastructure is held together by a ragtag band of unpaid volunteers? No; but that's hardly unique in this space.
A common abuser of this is the Discord desktop app, which listens on a local port.
When your browser navigates to a Discord channel's join page, it sends a request to localhost via this port and sends the channel ID to the client. This lets the app pop open a native 'Join Channel' experience.
I discovered this when I noticed how this behavior worked even in incognito mode and my browser was signed out of Discord.
Not. Cool. We need to massively improve sandboxing - of all applications - in the desktop world.
I feel that every time we talk about Java, we should clarify between Java the language, Java the programming style, and Java the JVM.
As a language, Java's not too bad. It's a bit wordy, in bad need of some syntax sugar, but it's designed to be fairly straightforward and for the most part it does its job well. I don't need a degree in language theory to get started writing it.
Java the programming style, particularly enterprise, is a horrendous over-engineered mess that schools jam down the throats of students who don't know any better. It's designed to (and fails to) enforce a common style that can be written by armies of mediocre developers plodding along inside giant enterprise codebases, so that no matter who wrote the code, some other developer in another department can figure out how to call it.
Java the JVM is a pretty nifty beast. It's made tradeoffs that means it's not always suited for every use case, but put in its element it really shines. The modern GC algos give developers options based on the program's needs. It's currently struggling to overcome some historical decisions that while good back in the old days are now holding it back.
Personally I'm very biased towards Kotlin, which gives me the benefit of the JVM without the barf that is Java. It's not the fastest-executing language out there, but for me it's a perfect balance between development speed, ecosystem of battle-tested libraries, and competitive execution speed.
The YC application asks teams to discuss their current equity split / legal situation. What happens to teams who haven't figured that out, or are looking for advice on those matters from Ycombinator? Will an uncertain equity plan or organizational structure kill an otherwise exciting application, if they are open to advice?