HN user

snickell

417 karma
Posts1
Comments76
View on HN

Can somebody help me understand how they use these, I feel like I'm missing something or I'm bad at something?

I only spent 10 minutes with Handy, and a similar amount of time with SuperWhisper, so pretty ignorant. I tried it both with composing this comment, and in a programming session with Codex. I was slightly frustrated to not be hands free, instead of typing, my hands were having to press and release a talk button (option-space in handy, right-command in superwhisper), but then I couldn't submit, so I still had to click enter with Codex.

Additionally, for composing this message, I'm using the keyboard a ton because there's no way I can find to correct text I've typed. Do other people get really reliable and don't need backspace anymore? Or.... what text do you not care enough to edit? Notes maybe?

My point of comparison is using Dragon like 15 years ago. TBH, while the recognition is better (much better) on handy/superwhisper, everything else felt MUCH worse. With dragon, you are (were?) totally hands free, you see text as you say it, and you could edit text really easily vocally when it made a mistake (which it did a fair bit, admittedly). And you could press enter and pretty functionally navigate w/o a keyboard too.

Its weird to see all these apps, and they all have the same limitations?

iPhone 17e 5 months ago

I would pay extra to get an iPhone mini, they could sell it as a “pro” feature. Still holding on to my mini too.

A Broken Heart 6 months ago

I would much rather use Vue than React too. That said, from a bird's eye view, I would say they're siblings. In a way I would say that Vue inherits the "react approach", and does it much (much) better, but its also not a fundamentally different approach.

Swift is available for Linux, license is Apache 2.0. There's even swift bindings for some linux ecosystem libraries, e.g. adwaita-swift for writing gnome apps and qt bindings for writing kde apps.

I… wow, I actually really like this idea. As you may have seen in my other comments, I’m not blind to the advantages of toll money being used to improve roads etc. This preserves that upside, while making the publicly owned resource roughly equally available to everyone.

Highways are almost always publicly owned monopolies. We, the public, choose to build them because they enrich all of us.

If you want to raise the money to buy land and build a private highway, price segment away. If you want to price segment a publicly owned and operate commons, it needs to be in the public interest.

This is allocating public property, not personal.

The money raised by auctioning access is of some public benefit, but is it enough to offset the deep unfairness of the public granting, for example, software engineers a shorter commute on average than teachers?

Vibe engineering 10 months ago

I really like "agent assisted coding". I think the word "vibe" is gonna always swing in a yolo direction, so having different words is helpful for differentiating fundamentally different applications of the same agentic coding tools.

On an iPhone 12 mini, wishing I hadn’t upgraded to iOS 26 because now my phone is notably laggy. Word to the wise. I use swiping for input and would consider it now unusable due to extreme lag.

The physical aspect I can’t give up is I can hold the phone with my thumb on the bottom and my middle finger on the top and scroll with my index finger to read. Wish I could buy that capability on a new iPhone, maybe one even slightly smaller.

Time to go find out if there’s even a way to downgrade, oof this is slow.

I think many open source projects already experience two buckets of contributors which maps nicely to the two class distinction inherent in this model:

1) a bunch of people who contributed one or two PRs, but it took the maintainers more time to review/merge the PR than the dev time contributed

2) a much smaller set of people who come back and do more and more PRs, eventually contributing more time than it takes to review their work

A major existing reason to review PRs from class 1 "once or twice" contributors (perhaps the main reason?) is that all class 2 "maintainer-level" contributors start as class 1.

I agree there's an awkward middle ground here, now you have to define where the boundary is between class 1 and class 2, but I think if you were able to graph contribution level you'd find there's already something of a bimodal distribution naturally in many projects anyway.

If you want to try what Karpathy is describing live today, here's a demo I wrote a few months ago: https://universal.oroborus.org/

It takes mouse clicks, sends them to the LLM, and asks it to render static HTML+CSS of the output frame. HTML+CSS is basically a JPEG here, the original implementation WAS JPEG but diffusion models can't do accurate enough text yet.

My conclusions from doing this project and interacting with the result were: if LLMs keep scaling in performance and cost, programming languages are going to fade away. The long-term future won't be LLMs writing code, it'll be LLMs doing direct computation.

What scares me is that the obvious pool of money to fund the deficit in the cost of operating of LLMs comes from the most subtle native advertising imaginable. Can you resist ads where, say, AirBnB pays OpenAI privately to “dope” the o3 hyperspace such that AirBnB is moved imperceptibly closer to tokens like value and authentic??

How much would AirBnB pay for the intelligence everyone gets all their info from having a subtle bias like this? Sliiightly more likely to assume folks will stay in airbnbs vs a hotel when they travel, sliiightly more likely to describe the world in these terms.

How much would companies pay to directly, methodically and indetectably bias “everyone’s most frequent conversant” toward them?

This is a really interesting project, and a great read. I learned a lot. I'm falling down the rabbit hole pretty hard reading about the "Leap" algorithm (https://www.usenix.org/system/files/atc20-maruf.pdf) it uses to predict remote memory prefetches.

It's easy to focus on libgraft's SQLite integration (comparing to turso, etc), but I appreciate that the author approached this as a more general and lower-level distributed storage problem. If it proves robust in practice, I could see this being used for a lot more than just sqlite.

At the same time, I think "low level general solutions" are often unhinged when they're not guided by concrete experience. The author's experience with sqlsync, and applying graft to sqlite on day one, feels like it gives them standing to take a stab at a general solution. I like the approach they came up with, particularly shifting responsibility for reconciliation to the application/client layer. Because reconciliation lives heavily in tradeoff space, it feels right to require the application to think closely about how they want to do it.

A lot of the questions here are requesting comparison's to existing SQLite replication systems, the article actually has a great section on this topic at the bottom: https://sqlsync.dev/posts/stop-syncing-everything/#compariso...

It definitely knows what GTK4 is, when it freaked out on me and lost the code, it was using all gtkmm-4.0 headers, and had the compiler error count down to 10 (most likely with tons of logic errors, but who knows).

But LLMs performance varies (and this is a huge critique!) not just on what they theoretically know, but how, erm, cross-linked it is with everything else, and that requires lots of training data in the topic.

Metaphorically, I think this is a little like the difference for humans in math between being able to list+define techniques to solve integrals vs being able to fluidly apply them without error.

I think a big and very valid critique of LLMs (compared to humans) is that they are stronger at "memory" than reasoning. They use their vast memory as a crutch to hide the weaknesses in their reasoning. This makes benchmarks like "convert from gtkmm3 to gtkmm4" both challenging AND very good benchmarks of what real programmers are able to do.

I suspect if we gave it a similarly sized 2kloc conversion problem with a popular web framework in TS or JS, it would one-shot it. But again, its "cheating" to do this, its leveraging having read a zillion conversion by humans and what they did.

Yes, very much agree, an interesting benchmark. Particularly because it’s in a “tier 2” framework (gtkmm) in terms of amount of code available to train an LLM on. That tests the LLMs ability to plan and problem solve compared with, say, “convert to the latest version of react” where the LLM has access to tens of thousands (more?) of similar ports in its training dataset and more has to pattern match.

This is the smoothest tom sawyer move I've ever seen IRL, I wonder how many people are now grinding out your GTK4 port with our favorite LLM/system to see if it can. It'll be interesting to see if anyone gets something working with current-gen LLMs.

UPDATE: naive (just fed it your description verbatim) cline + claude 3.7 was a total wipeout. It looked like it was making progress, then freaked out, deleted 3/4 of its port, and never recovered.

How do you even read code without types?

We're not going to settle the preference for dynamic vs static types here. Its probably older than both of us, with many fine programmers on both sides of the fence. I'll leave it at this: well-informed programmers choosing to write in dynamically typed languages DO read code without types, and have happily done so since the late 1950s (lisp).

The funny thing is, I experience the same "how do you even??" feeling reading statically typed code. There's so much... noise on the screen, how can you even follow what's going on with the code? I guess people are just different?

LLMs will make fewer type errors, and more errors that are uncaught by types

The errors I'm talking about are like "this CSS causes the element to draw part of its content off-screen, when it probably shouldn't". In theory, some sufficiently advanced type system could catch that (and not catch elements off screen that you want off-screen)? But realistically: pretty challenging for a static type system to catch.

The errors I see are NOT errors that throw exceptions at runtime either, in other words, they are beyond the scope of current type systems, either dynamic (runtime) or static (compile time). Remember that dynamic languages ARE usually typed, they are just type checked at runtime not compile time.

perhaps that gives the delusion that the LLM is doing it completely without type system.

I mentioned coding in JS with cline, so no delusion. It does fine w/o a type system, and it rarely generates runtime errors. I fix those like I do with runtime errors generated when /I/ program with a dynamic language: I see them, I fix them. I find they're a lot rarer in both LLM generated code and in human generated code that proponents of static typing seem to think?

Even in early 2025, LLMs are already the most powerful type inference algorithm. Why would they need a static type system in 2030?

My guess is it'll be the opposite: I suspect compared to humans, LLMs will make fewer type errors, and more errors that are uncaught by types. Thus I expect type systems will be of lower value to them (compared to humans), leading to a shift toward dynamic languages and the possible extinction of typed languages.

The alternative I could imagine is moving toward Haskell-like languages with MUCH stronger type systems, where higher-level errors ARE type errors.

My one concrete observation in this direction: "press . to see valid options" behavior is a traditional strong point of typed languages. And interestingly, proved to be one the first thing that early/dumb LLMs were actually pretty good at. I believe that indicates LLMs are relatively good at type inference (compared to other things you can ask them to do), and we should expect that to continue being a strong point for them.

In working with Cline in both TypeScript and JavaScript, I find the LLM making tons of errors it has to go and fix in a future iteration, but virtually none of them are type errors.

I suspect LLMs are relatively good at duck-typed languages because they have a much bigger working memory than humans. As a result, the LLM can hold in working memory not just e.g., the function argument in front of them, but also all the callers of the function, and how they used the variable, and callers of the callers, and thus what "duck-type" it will be.

A system that can do this level of automatic type inference doesn't necessarily benefit from a formal, static, compile time type system.

The main things I'm blocking on before submitting a "Show HN" are:

- Getting the instant-replay gallery sorted to make it usable, maybe sorting via likes.

- Selecting a couple interesting sessions from the gallery and turning them into a short video

- Making sure I have enough credits lined up (hopefully donations!) to survive an "Ask HN".

Anyone know order-or-magnitude how many visits to expect (order of magnitude) from an Ask HN? A thousand? 10? 100? I need to figure out how many credits I'd need to line up to survive one.

had to charge you a few dimes

s/you/openrouter/: ty to openrouter for donating a significant chunk of credits a couple hours ago.

Really appreciate the feedback on needing a video. I had a sense this was the most important "missing piece", but this will give me the motivation to accomplish what is (to me) a relatively boring task, compared to hacking out more features.

wow, that would be amazing, sending you an email.

I don't think the project would have gotten this far without openrouter (because: how else would you sanely test on 20+ models to be able to find the only one that actually worked?). Without openrouter, I think I would have given up and thought "this idea is too early for even a demo", but it was easy enough to keep trying models that I kept going until Claude 3.7 popped up.

What I'm currently doing is caveman: I ask the LLM to attach a unique id= to every element, and I gave it an attribute (data-use-cached) it can use to mark "the contents of this element should be loaded from the preivous frame": https://github.com/snickell/universal/blob/47c5b5920db5b2082...

For example, this specifies that #my-div should be replaced with the value from the previous frame (which itself might have been cached): <div id="my-div" data-use-cached></div>

This lowers the render time /substantially/, for simple changes like "clicked here, pop-open a menu" it can do it in 10s, vs a full frame render which might be 2 minutes (obviously varies on how much is on the screen!).

I think using HAML etc is an interesting idea, thanks for suggesting it, that might be something I'll experiment with.

The challenge I'm finding is that "fancy" also has a way of confusing the LLM. E.g. I originally had the LLM produce literal unified diffs between frames. I reasoned it had seem plenty of diffs of HTML in its training data set. It could actually do this, BUT image quality and intelligence were notably affected.

Part of the problem is that at the moment (well 1mo ago when I last benchmarked), only Claude is "past the bar" for being able to do this particular task, for whatever reason. Gemini Flash is the second closest. Everything else (including 4o, 4.5, o1, deepseek, etc) are total wipeouts.

What would be really amazing is if say Llama 4 turns out to be good in the visual domain the way claude is, and you can run it on one of the LLM-on-silicon vendors (cerebrus.ai, grok, etc) to get 10x the token rate.

LMK if you have other ideas, thanks for thinking about this and taking a look!

No, I wasn't planning to post this for a couple weeks, but I saw the comment and was like "eh, why not?".

You can watch "sped up" past sessions by other people who used this demo here, which is kind of like a demo video: https://universal.oroborus.org/gallery

But the gallery feature isn't really there today, it shows all the "one-click and bounce sessions", and its hard to find signal in the noise.

I'll probably submit a "Show HN" when I have the gallery more together, and I think its a great idea to pick a multi-click gallery sequence and upload it as a video.