reaction latency doesn't cover everything. the round trip from trigger to action is a few hundred ms at best, yes, but to enable that we are processing inputs at ~30hz minimum and integrating at ~5hz. you would total your car pretty quickly if you couldn't constantly adjust
the problem is that single-source advantage gradually falls away as you develop your software into something that feels good to use on each platform. and once you have a quality product you're left with perfunctory coupling that makes it harder to adopt the latest platform features
Yea that never made sense to me. I think and solve problems as I code, and having someone yapping while I'm trying to do that is a great way to disrupt my thinking process.
In my limited experience, the 'pairness' part of pair programming , is best done in silence. The discussion / planning happens up front, the keyboard person does the implementation and the second person doesn't 'backseat drive', but thinks about test cases (writes it down), thinks about weaknesses (writes it down) and writes documentation while the code is written.
All of these are reviewed before commit.
The 'interrupting' while coding is the shitty part (I agree with you), not having someone working with you.
I don't really see how this provides any benefit over pairing asynchronously, pinging with questions or updates on what's shifted, sharing pull requests, requesting comments, etc.
This process respects each other's time and allows each person to visit the relevant pieces without interruption. The common rebuttal to this is "Slack messages are too interrupting!" and my response is: ignore the message until you're in a good spot to address it, or if you can't spend meaningful time on it yet, just reply with an "I'll check this out later, thanks!"
The idea that we have to sit on a video call in silence while losing the ability to think and write privately is such a huge distraction. Half of my mental bandwidth is occupied with self-consciousness of being "watched", or if I have my video off, it's the idea of being present and tied down by simply being there.
As someone with ADHD, those circumstances do not mix and eliminate any possibility of being productive because it's too distracting on all fronts. Not to mention, I need intense music to really get in a flow state. You might be surprised by how many engineers feel this way because they similarly experience neurodivergent realities around this.
You might be working on much smaller and well constrained problems, pair programming works well when the problem is unconstrained with many complex and interconnected layees
Like, not as a rule. There are times when it would be helpful to have my trusted coworker helping to work through something. The answers aren’t all obvious and we don’t know exactly how it’s going to go. We’ll feel it out as we go. He has better instincts for some stuff and I have better ones for others. We’ll get there better and faster pairing.
But most of the time we have our own stuff to do and have our respective things well in hand. Then there’s no reason to force a pair programming situation.
likewise, taking a wrecking ball to systems refined over centuries should come with some burden of proof for the positive claim that a tool can replace an institution. most times this has happened before, we've had to strengthen credentialing requirements to stop people from dying
The burden of proof is on peer review not the other way around. Peer review is a fairly modern invention post WWII. Prior to that “peer review” looked very different.
i'm saying all positive claims need to be justified, not that priors are exempt. there is one claim with a vast body of evidence supporting it, and a competing claim that must meet the same standard. the world is not so magically different now that we can't look at software engineering and computer science the same way we look at real (credentialist, regulated) science and engineering disciplines. really all i was implying is "peer review WAS vital" is jumping the gun
OP says "you want to select a whole Markdown document built from SwiftUI primitives", but who wants that? what sort of product thinking tells us we want that? that sounds like a document editor, which has been hard to build for decades and sounds out of scope for an llm chat ui. everyone has landed on only supporting selection within each contiguous block, with a copy button for the entire message
LLMs are often used to generate Markdown because they're quite good at it and unlike HTML it's very forgiving.
Rendering text into things like chat bubbles or even just generic output panes as it comes in is a massive pain. Every new word requires redoing layout, detecting LTR versus RTL flows and overrides, figuring out word breaks and line breaks, possibly combined with resizing the containing UI element (which involves measuring the render space, which is often implemented by rendering to a dummy canvas and finding out the limits).
Document editors have it relatively easy because humans type at a relatively low speed and pasting is a single operation (although pasting large amounts of text does hit the render performance of the UI). They're also often provide relatively limited features on phones.
If you want to render something like ChatGPT with similar features in native UI, youre going to need to find a fully-fledged document component or build one yourself. And, as it turns out, we have document components that work quite well: web engines.
If you embed a webview rendering just HTML and CSS, you get better performance, features, and accessibility than any home-grown renderer will provide. And with every major OS coming with a browser built in, it won't even bloat your app.
HTML is famously forgiving as well - that's the whole reason XHTML failed, because one typo in the latter will make your entire web page fail to render with an error. Markdown is probably a little more forgiving, which mattered more with previous-gen LLMs with small context windows. Any near-frontier model should have no problem generating valid HTML.
Also a lot of LLMs are trained specifically to expect Markdown in their instructions, OpenAI's models in particular (Anthropic expects more pseudo-HTML/XML, but that is different from real HTML/XML).
reply