how can whisper flow latency be even anywhere close to keyboard? since you've posted to HN i assume you are in tech, and your are not writing novels or long memos or terms-and-conditions corporate lullaby;

continuous stream of words may be faster on whisper flow, however more time is spent formatting, editing, refactoring, commanding etc - and there is no way whisper flow can come remotely close to keyboard performance -- but their whole shtick is fast spoken words that keyboard cannot match. yeah, sure buddy.

llm usage or not, code browsing/refactor etc still need human usable tools like vim/git/tmux etc.

IMO, this whole 'article' has such a corporate bootlicky flavor to it. I pay for subscription (claude, gpt, netflix etc) since there are no real (pragmatic, convenience and financial) alternatives and it's not easy to rig a solution. otherwise the very fact that the only option is app subscription, i stay out of it on principle. even IDApro has perpetual license.

America is well into the midpoint of slow and steady decline; and balkanized states are not helping. Lots of other countries are going downhill as well, but nothing like the spectacular fall of USA.

During the dark days of human slop, the progress was hindered by so many factors -- layers of abstractions, answers hidden behind thin documentation, self-important experts gatekeeping the knowledge, forums doling out rtfm attitude.

Now, it's just a matter of pointing a pack of llm in that direction, and with inquiry based learning, suddenly you are back in control. Heck, to get setup with eval boards and toolchain, it would've cost thousands of dollars 20 years ago.

LLM has allowed me to spend more time on hobbies, at the same time make new tech domain lot more approachable.

Being frugal really helps too - my job might disappear any time.

stepping outside of garbage collection, and managed runtime systems could teach a lot; there was a book written 20 or so years ago;

https://smallmemory.charlesweir.com/

It's common to hear folks in these situation saying that the "tragedy was the best thing that happened to me"; when I was young, I didn't really believe it, (watching the documentary of Walt Lawrence or reading John Callahan's book 'don't worry, he won't get far on foot'), but now that i am older, i can confirm it is definitely believable :)

The speaker has usb interface, and since it uses HID, its bandwidth is limited to 64bytes max per ms; it runs freertos, and for the price of the speaker it is highly unlikely it runs an mcu with trustzone;

moreover, usb descriptors are exchanged with the host in the clear, so patching it and adding a keyboard (that most os will implicitly trust) requires a usb cable, and there is definitely some 'touch' involved to get to that step, even if we ignore the physical access to the speaker/pc for the sake of argument;

of course, once that's done, updating image over bluetooth is easy, and that's the claim behind 'without ever being touched';

IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to spend as much time to sanitize the implementation with Coverity/Valgrind and the ilk when the compiler could've handled it.

With C++98, Bjarne's book on c++ internals could've give you good insight into what went on, but later it turned into a whole cottage industry of "effective, more effective, proficient, performant, c++" series of books -- so kiss goodbye to any notion of being able comprehend existing code that's not written by you (until llms arrived). I'm happy to have spent time to learn problem domain instead.

I'll still watch the documentary since it has some of my favorite folks (Kernighan, Stepanov).