I like the distinction between imperative and declarative styles, but I still use imperative chat sessions to work through what the declarative plan should look like. I feel like this approach loses that.
loaned from German, where it's originally a way to say buttocks, literally "sitting flesh". If you have more Sitzfleisch you can sit for longer. Both in the literal sense (a bigger butt makes sitting more comfortable) and in the figurative sense (having the mental ability to sit for longer, get more desk work done)
I think there is an IT bit of humor from about 1 decade+ back where the people who's proposals won out in meeting were the ones that could keep from needing to go to the bathroom longer.
There's also a less flattering reading of the word, where Sitzfleisch means having a "flat ass" (from sitting too much, e. g. Sitzfleischparade describing a group of flat-arsed people, or something like Sitzfleischmaxxer, and so on).
Brazilian portuguese has cu de ferro, which literally translates to iron ass, something one must of course have in order to apply themselves to scholarly activities.
Wow, what a great comparison. LLMs are great at reasoning but absolute dogshit at simple arithmetic. If there's a raw calculation involved I always tell it to use python to add it all up.
If your goal is to implement an absurd comment you can use this one next time: instruct your LLM to implement Conway’s Game of Life to implement an abacus.
Because, you know, humans are notoriously poor at implementing the x86-64 instruction set in their minds. This is why God had to create Guido van Rossum.
Arguably Mathematica would be a better fit, but there are those who frequent this corner of the Internet who rather not have to read anything that might cause them to think about Stephen Wolfram.
This is interesting. I’ve been building a project on top of sprites for the past few months, but I’ve often thought about moving off because it didn’t feel like fly was devoting enough attention to it. The changelog is sparse and their developer discord is kinda dead. So it’s good to hear they’ll be prioritizing it going forward
If any fly people read this, could you please add the ability to create custom_api connectors to the api? Sprites are so close to being great for arbitrary secrets proxying. Right now you have to provision everything manually
By the harness I believe he means the entire end-user product experience, not specifically the harness code. I’ve mostly stuck with codex because their Mac app is better and I’ve gotten used to running automations through it. The more workflows they can build around this (design tools, collaboration, etc), the better chance of lock-in.
> If you own the user touchpoint, then you have meaningful lock-in, and the best way to own the user touchpoint is to be the canvas for everything they need to do. This, by extension, means that the frontier labs are on a collision course with software companies: it’s software that owns the user touchpoint, and it’s in the frontier labs’ long-term interest to not simply be a commodity input into software but to simply replace software outright.
They've gone too far on enforcing uniformity of icons and abusing liquid glass, but I disagree that arbitrary shapes were better. All the random icon shapes looked cool in isolation, but were harder to scan at a glance. The uniform squircle is a useful constraint.
I wouldn't mind if they allowed something similar to that audio hijack icon, where you require the rounded rect as the guiding frame but are allowed to have some elements protruding out of it. But completely arbitrary shapes are too jarring imo.
Early on, when UI/UX was emerging as a discipline, user reaction times and accuracy were measured across a large number of participants. There are many stories during the development of the Lisa and Mac of unexpected user behavior and results.
We shouldn’t be guessing if uniformity helps distinguish between apps or not. We could very easily test it.
But UI/UX has long distanced itself from science, for whatever reason. Maybe because users are so proficient these days that almost anything works. We used to required training on how to use a mouse, menus and windows.
It’s been probably a decade since I’ve heard anyone mention Fitt’s law, for instance, and Liquid Glass atrocities are direct a consequence of disregarding all that was learned in this field.
I'm pretty sure Nielsen already tested it, if I had to guess they probably found that different icon shapes are broadly better but that gets ignored because "it's cheaper to use some shitty vector squiggle in a round rect", just like the research that found "icons are better when there is text" is widely ignored too because internationalization costs money.
I mostly lament the simplification of app icons as an artistic loss, not as a usability loss. Shameless plug, but I made a project based on the idea of icons as pure art with no utility https://www.benedelste.in/post/__001
I can see both sides. Artistic constraints can suck, but on the other hand, for every app with a truly beautiful icon design, like the ones listed in the "It Doesn’t Have to Be Like This" section, how many apps have truly awful icon designs? The dock is prime visual real estate, and as a user, I'd like some kind of constraint that makes it less likely some crazy art style is going to be imposed on my desktop just because I need an app there.
“Build vs buy” assumes that there are only two parties. If it’s easier to build internally, then it’s easier for a 3rd party competitor to enter the market and bid the price down. I think the "zone of viability" is real, it just narrows and shifts downward.
The author hints at this in a footnote:
> It does, however, pencil out to use a different product instead. In this particular case, it’s easy: use Linear instead of Jira.
I agree. I followed this article for a repo I'm working on, and I had a very hard time inferring how, specifically, they implemented "providers" and enforced import layers. A sample repo would've been nice.
