I was wondering if it'd be possible to go further, and actually use it as a fully fledged keyboard, but with your choice of switches and mechanical layout... and turns out that somebody has been doing that already! basically reverse-engineering the matrix and hooking up your own switches to the logic board. You get TouchID, pretty good BT performance and integration in the Apple ecosystem, good battery life, ... and all in a single device.
You mean the cost of EDA software directly (paying Synopsys/Cadence for the software used to design, verify, and synthesize your own chips)? Or the actual R&D cost to design the chip itself? Or paying for prepackaged IP blocks (major ones like CPU cores, or lesser ones like I/O)?
Cursor has been an enabler for unfamiliar corners of development. Mind you, it's not a foolproof tool that writes correct code on the first try or anything close to that.
I've been in compilers, storage, and data backends for 15ish years, and had to do a little project that required recording audio clips in a browser and sending them over a websocket. Cursor helped me do it in about 5 minutes, while it would've taken at least 30 min of googling to find the relevant keywords like MediaStream and MediaRecorder, learn enough to whip something up, fail, then try to fix it until it worked.
Then I had to switch to streaming audio in near-realtime... here it wasn't as good: it tried sending segments of MediaRecorder audio which are not suitable for streaming (because of media file headers and stuff). But a bit of Googling, finding out about Web Audio APIs and Audio Worklet, and a bit of prompting, and it basically wrote something that almost worked. Sure it had some concurrency bugs like reading from the same buffer that it's overwriting in another thread. But that's why we're checking the generated code, right?
Since the read part is handled by another chip (feeding off of USB power, therefore not terribly power constrained), you could present as a MTP device, or even mass storage, while generating the file structure on the fly. Maybe TIFFs are simple enough so you don't have to mess with the actual image bytes.
And yet they couldn't agree with Apple on a protocol that could be implemented by both. Imagine how much better tracking you'd get with tags that could be picked up by either Android or iPhones. Especially in the _third world_ where Android phones are way more prevalent.
A very simple optimization for those complaining about having to fetch a large file every time you need a little datapoint: if they promised the file was append-only, and used HTTP gzip/brotli/whatever compression (as opposed to shipping a zip file), you could use range requests to only get the new data after your last refresh. Throw in an extra checksum header for peace of mind, and you have a pretty efficient, yet extremely simple incremental API.
(Yes, this assumes you keep the state, and you have to pay the price of the first download + state-keeping. Yes, it's also inefficient if you just need to get the EUR/JPY rate from 2007-08-22 a single time.)
> While alphabetic keyboards typically provide autocomplete features for more expedient typing, predictive features in Chinese input methods are more crucial when using input methods such as pinyin where hundreds of characters might match an inputted pinyin syllable. For longer strings of syllables, an IME will commonly reach out over the network to a cloud-based service for suggestions if suitable suggestions are not available in the input method’s local database.
Not saying whether they should, but it's pretty easy to understand why they do it.
Then you should probably check out Hoffmann's "ultimate french press technique" https://youtu.be/st571DYYTR8
IMO it produces the best coffee I've ever been able to make in a french press.