- it's easy to prompt an LLM to do it for you, especially if you're targeting a pre-existing runtime like CLR or transpiling to another language. previously you'd have to grind out the parser and compiler for a new language, but a lot of that work is mechanical
- "I want a language that works a little differently"
- programming language theory (PLT), generally
- languages are tools. the authors should explain what their languages are best suited for
- Obj C and C++ were both developed around the same time as extensions of C. Obj C was focused on message passing and Smalltalk's object system, while C++ was focused on adding as many abstractions as possible to C. Neither language has good support for avoiding null pointer dereferences, one of the primary things Swift addresses with its richer type system and Optionals.
BitTorrent's bencoding format, used in .torrent files, effectively uses netstrings-- but without the trailing commas, so it uses "5:hello" to represent filenames and similar.
It's not really a big problem. You should be storing arbitrary binary strings as blobs (and length() works properly with them), but the underlying encoding is nearly identical: https://www.sqlite.org/fileformat.html#record_format
if you happen to regenerate your protos 5 times in an hour you'll get ratelimited
it's a very frustrating system. you should spend a modicum of effort figuring out how to generate your things locally yourself instead, be that docker, arcane wasm...
The absolutely easiest way to write a JIT is to use Javascript and eval() (or "new Function()", which is just eval in a Java-shaped tuxedo). You can quite easily speed up little matching functions, especially arithmetic heavy ones, by just filling in some templates at runtime!
Cloudflare's Deepseek V4 Pro prices are 4x more than Deepseek's for input and output tokens, and 100x more for cached input tokens, which is crucial for the tool uses of agents which cause multi-turn conversations.
The main thing holding most people back from web-based IDEs is restricted filesystem and tools integrations, but cloud office suites are extremely popular. Google has excellent infrastructure for distributed build and test cycles built into Cider to go along with the entirely remote version control system.
Best of luck on your web-based demos! Dropping people into a working dummy environment with a few tutorial prompts should really help conversions.
Apple could easily support eGPUs if they wanted to, but they choose to have vertical integration over fragmentation or usefulness. It's the same as them not supporting OpenGL or Vulkan: they could if they wanted to be a better gaming/porting target, but compatibility of any sort is not a priority.
It's not that it's reserving power, but rather that you hit some bottleneck on a 3070 Ti before running into thermal limits-- it's likely limited by either tensor core saturation or RAM throughput. Running the workload with Nvidia's profiling tools should make the bottleneck obvious.
They are bullshit machines because they do not have an internal mental model of truth like a human does. The flagship models bullshit less, but their fundamental architectures prevent having truth interfere with output.
I'm glad there's many teams with automated scans of pypi and npm running. It elevates the challenge of making a backdoor that can survive for any length of time.
That's a narrow fair use exception. Many of these open game engines are effectively 1:1 decompilations of the original games, and it would be shocking if they were not effectively copyrighted the same as the original.
I don't think this has been tested in court, but the recent flood of Nintendo game decompilations is likely to change that.
Microsoft released a video that covers effectively all of the Xbox One security system, and it's referred to extensively in the talk. The specific methods of glitching don't require any insider knowledge.
Most businesses can and many businesses do run efficiently out of shared spreadsheets. Choosing the processes well is the hard part, but there's just not much computational complexity in the execution, nor more data than can be easily processed by a single machine.
Many engineers get paid a lot of money to write low-complexity code gluing things together and tweaking features according to customer requirements.
When the difficulty of a task is neatly encompassed in a 200 word ticket and the implementation lacks much engineering challenge, AI can pretty reliably write the code-- mediocre code for mediocre challenges.
A huge fraction of the software economy runs on CRUD and some business logic. There just isn't much complexity inherent in any of the feature sets.