iterance (u/iterance)

iterance commented on Making Google Sans Flex design.google/library/goo... · Posted by u/meetpateltech

mft_ · a day ago

Apple probably has swathes of real-world usability data showing that virtually no-one uses their phone for prolonged periods of time while it's laying down on a hard flat surface.

You may be right about the aesthetics (and Lord Jobs may well have agreed with you) but they may have made the tradeoff consciously.

iterance · a day ago

One can say "they probably had data to support it" about virtually any decision. It is not really a defense from critique. It may have been deliberate, but it still feels wrong and bad.

iterance commented on This is not the future blog.mathieui.net/this-is... · Posted by u/ericdanielski

voxleone · 4 days ago

The author says>> "Not being in control of course makes people endlessy frustrated, but at the same time trying to wrestle control from the parasites is an uphill battle that they expect to lose, with more frustration as a result."

While this reaction is understandable, it is difficult to feel sympathy when so few people are willing to invest the time and effort required to actually understand how these systems work and how they might be used defensively. Mastery, even partial, is one of the few genuine avenues toward agency. Choosing not to pursue it effectively guarantees dependence.

Ironically, pointing this out often invites accusations of being a Luddite or worse.

iterance · 4 days ago

The fact is, most of the systems people use in their day do day that behave the way described simply require no mastery whatsoever. If your product, service, or device is locked behind learning a new skill, any skill, that will inherently limit the possible size of the audience. Far more than most realize. We can rail against this reality, but it is unforgiving. The average person who is struggling to put food on the table only has so many hours in the week to spare to stick it to the man by learning a new operating system.

iterance commented on What Is Generative UI? tambo.co/blog/posts/what-... · Posted by u/grouchy

iterance · 14 days ago

Cold take: honestly, just let users learn how to use your software. Put all your options in a consistent location in menus or whatever - it's fine. Yes, it might take them a little bit. No, they won't use every feature. Do make it as easy to learn as possible. Don't alienate the user with UI that changes under their feet.

Is "learning" now a synonym of "friction" in the product and design world? I gather this from many modern thinkpieces. If I am wrong, I would like to see an example of this kind of UI that actually feels both learnable and seamless. Clarity, predictability, learnability, reliability, interoperability, are all sacrificed on this altar.

> The explosive popularity of AI code generation shows users crave more control and flexibility.

I don't see how this follows.

The chart with lines and circles is quite thought-leadershipful. I do not perceive meaning in it, however (lines are jagged/bad, circles are smooth/good?).

iterance commented on Most technical problems are people problems blog.joeschrag.com/2023/1... · Posted by u/mooreds

another_twist · 15 days ago

Say this in an interview and its a perfect way to fail, even though its true. Its sad how interviewers often take pleasure in pointing out that anything said outside their packets is a signal for lack of technical knowledge. I've been in and passed several tech interviews. I've also interviewed plenty of people, if someone points out the human aspect of a problem, I actually award points. Sad how often I have to fight with my colleagues.

"But what about using a message queue.."

"Candidate did not use microservices.."

"Lacks knowledge of graph databases.." (you know, because I took a training last week ergo it must be the solution).

iterance · 15 days ago

Thankfully, we do not have to judge a blog post by its ability to pass muster in technical interviews. :)

iterance commented on Thoughts on Go vs. Rust vs. Zig sinclairtarget.com/blog/2... · Posted by u/yurivish

throwaway894345 · 16 days ago

I cautiously agree, with the caveat that while I thought I would really like Rust's error handling, it has been painful in practice. I'm sure I'm holding it wrong, but so far I have tried:

* thiserror: I spend ridiculous and unpredictable amounts of time debugging macro expansions

* manually implementing `Error`, `From`, etc traits: I spend ridiculous though predictable amounts of time implementing traits (maybe LLMs fix this?)

* anyhow: this gets things done, but I'm told not to expose these errors in my public API

Beyond these concerns, I also don't love enums for errors because it means adding any new error type will be a breaking change. I don't love the idea of committing to that, but maybe I'm overthinking?

And when I ask these questions to various Rust people, I often get conflicting answers and no one seems to be able to speak with the authority of canon on the subject. Maybe some of these questions have been answered in the Rust Book since I last read it?

By contrast, I just wrap Go errors with `fmt.Errorf("opening file `%s`: %w", filePath, err)` and handle any special error cases with `errors.As()` and similar and move on with life. It maybe doesn't feel _elegant_, but it lets me get stuff done.

iterance · 16 days ago

I will at least remark that adding a new error to an enum is not a breaking change if they are marked #[non_exhaustive]. The compiler then guarantees that all match statements on the enum contain a generic case.

However, I wouldn't recommend it. Breakage over errors is not necessarily a bad thing. If you need to change the API for your errors, and downstreams are required to have generic cases, they will be forced to silently accept new error types without at least checking what those new error types are for. This is disadvantageous in a number of significant cases.

iterance commented on Tiger Style: Coding philosophy (2024) tigerstyle.dev/... · Posted by u/nateb2022

jackfranklyn · 21 days ago

You're not missing much - what you describe is roughly what I do. My original comment was pushing back against the "70 lines max" orthodoxy, not against splitting at all.

The nuance: the context struct approach works well when steps are relatively independent. It gets messy when step 7 needs to conditionally branch based on something step 3 discovered, and step 12 needs to know about that branch. You end up with flags and state scattered through the struct, or you start passing step outputs explicitly, and the orchestrator becomes a 40-line chain of if/else deciding which steps to run.

For genuinely linear pipelines (parse → transform → validate → output), private functions + orchestrator is clean. For pipelines with lots of conditional paths based on earlier results, I've found keeping more in the orchestrator makes the branching logic visible rather than hidden inside step functions that check context.flags.somethingWeird.

Probably domain-specific. Financial data has a lot of "if we detected X in step 3, skip steps 6-8 and handle differently in step 11" type logic.

iterance · 16 days ago

Interesting. I'd love to learn more about the problem class.

iterance commented on Fighting the age-gated internet wired.com/story/age-verif... · Posted by u/geox

whywhywhywhy · 16 days ago

Guess at some point in the future it will come out who bankrolled all this because multiple countries in Europe and America don’t just roll something like this out in 8 months organically without someone paying off politicians to push it

iterance · 16 days ago

The fight for this kind of legislature has been ongoing for many years as part of a broader program that seeks to shape the kinds of information that can be stored, consumed, and propagated on the Internet. Age verification is only one branch of the fight, but an important one to the many who support government control: it is an inroad that allows governments to say they have a stake in who sees what.

iterance commented on Tiger Style: Coding philosophy (2024) tigerstyle.dev/... · Posted by u/nateb2022

jackfranklyn · 22 days ago

The "split long functions" advice works well for most code but falls apart in transaction processing pipelines.

I work on financial data processing where you genuinely have 15 sequential steps that must run in exact order: parse statement, normalize dates, detect duplicates, match patterns, calculate VAT, validate totals, etc. Each step modifies state that the next step needs.

Splitting these into separate functions creates two problems: (1) you end up passing huge context objects between them, and (2) the "what happens next" logic gets scattered across files. Reading the code becomes an archaeology exercise.

What I've found works better: keep the orchestration in one longer function but extract genuinely reusable logic (date parsing, pattern matching algorithms) into helpers. The main function reads like a recipe - you can see the full flow without jumping around, but the complex bits are tucked away.

70 lines is probably fine for CRUD apps. But domains with inherently sequential multi-step processes sometimes just need longer functions.

iterance · 22 days ago

I'll admit this may be naive, but I don't see the problem based on your description. Split each step into its own private function, pass the context by reference / as a struct, unit test each function to ensure its behavior is correct. Write one public orchestrator function which calls each step in the appropriate sequence and test that, too. Pull logic into helper functions whenever necessary, that's fine.

I do not work in finance, but I've written some exceptionally complex business logic this way. With a single public orchestrator function you can just leave the private functions in place next to it. Readability and testability are enhanced by chunking out each step and making logic obvious. Obviously this is a little reductive, but what am I missing?

iterance commented on Music eases surgery and speeds recovery, study finds bbc.com/news/articles/c23... · Posted by u/1659447091

kunley · 23 days ago

The crucial issue is: what kind of music. A lot of what's nowadays called music is actually rather a "sounds with some beat" category.

iterance · 23 days ago

I think you maybe just don't like it?

iterance commented on Slop Detective – Fight the Slop Syndicate slopdetective.kagi.com/... · Posted by u/speckx

iterance · 24 days ago

Correctness is a poor way to distinguish between human-authored and AI-generated content. Even if it's right, which I doubt (can humans not make wrong statements?), it doesn't do anything to help someone who doesn't know much about what they're searching.