2,041 karma · joined July 9, 2014
Working on dev tooling @sentry. Formerly @emergetools (YC21, acq) @stripe and @kayak.
I've been toying around with multiplatform frameworks like RN and Flutter for a side project of mine but they never feel right. I'd rather use the native UI per platform and have a nice way to share business logic. KMP exists but I think for most developers wanting to build an app it's more common to build for iOS first, and then port to Android later if the app gets traction. With a little foresight of keeping shared code in a Swift Package, it seems like that's getting more and more possible which is great to see.
I've been toying with an idea of a new format that stores text naturally and captures semantics (e.g. to help with table parsing), but also preserves formatting rules so you can still achieve fairly consistent rendering. This format could be easily converted to PDF, although the opposite conversion would have the regular challenges. The main challenge is distribution of course.
First, from their perspective if they are able to solve an issue by following their script, even if it took 20 convoluted steps, everything is working normally. People are used to occasionally dealing with workarounds so it's not a big deal in their mind.
Second, it's not in their interest to report UX issues. They are measured by the number of tickets they close, so the issue that gets a lot of inbound support and they know an easy workaround for is nicely boosting their numbers. Eventually these things get fixed by product and they move on to doing the same thing with other tickets.
However I strongly doubt your point about "It's not going to replace anyone's job" and that "they also free up the human agents to do higher-value work". The reality in most places is that fewer agents are now needed to do the same work as before, so some downsizing will likely occur. Even if they are able to switch to higher-value work, some amount of work is being displaced somewhere in the chain.
And to be clear I'm not saying this is bad at all, I'm just surprised to see so many deluded by the "it won't replace jobs" take.
I see a lot of commenters asking why a GUI is necessary. When you're running several agents in parallel it becomes very handy compared to the terminal. I can easily see the status of each which I haven't found a good equivalent for when using terminal tabs. Also it handles automatically creating git worktrees for each agent which is great.
My advice is more cautionary for folks who search "Tailwind components library", see DaisyUI as the 4th result, and think "great!"
Creating helpers like `btn` makes it very difficult to understand how it works and is not very customizable. Shadcn creates an actual component for you in your codebase and is just trivial Tailwind styles to modify.
I think you're right about the editorial thinking + what do people find interesting parts. But that doesn't have to be solved by directly by AI, it's easy enough to sidestep the problem and provide a nice interface for the human-in-the-loop part. I'd imagine that would save you a ton of time by having a nice starting point depending on how much you have to rewrite for tone.
This would actually be great. So many researchers have a marketing problem with explaining and getting people excited for their work.
I always think about the invoicing use-case: digital systems should be able to easy extract data from the file while still being formatted visually for humans. It seems like the tech world would be much better off if we migrated to a better format.
I really wish the entire Swift team would spend a quarter fixing bugs and improving the compiler speed, though. So many trivial SwiftUI cases trigger the "this is too complex for the compiler" errors which are so frustrating to fix.
The only angle I can see this working for OpenAI is pushing the anti-China national security threat narrative, which I expect to see a lot more of this year (especially with this administration). While I personally hate that, I can definitely see how AI + drones are the obvious future in warfare, so I don't think it's that far-fetched to work.
The only mention I can find is: "How do we determine proper form? Firefly references the average exercise performed by credible fitness experts."
Also like others mentioned, your pricing is incredibly deceptive. Make it front and center to users, otherwise "Full Access (7-day free trial). Cancel anytime." is a hard no-install for me.
Apologies if this side-tracks the conversation, but why do we as an industry complicate the naming of such techniques? I don't remember what "string interning" is off the top of my head, but a "string lookup table" is immediately obvious. Maybe I'm wrong though and this is a commonly understood name. I guess interning captures both creating the lookup table + using the index in the related data structures. We used this technique at KAYAK to help efficiently construct the list of possible flight combinations for N x M depart/return legs.
"akshually this should try to follow more SOLID principles"
But, coming from a formal engineering background, I thought this is what it meant to be a professional software engineer. Little did I know these "principles" were just the musings of a consultant lol. Turns out most folks have good intentions and want a standardized way to write code, but for some reason it always results in code that looks like the Enterprise FizzBuzz meme repo.
It seems to be as long as you don't significantly alter the primary purpose of the app, then it's "allowed". But that's a very broad interpretation and puts native Swift apps at a huge disadvantage.
Is it possible? Yes, of course. Bazel and Buck iOS builds have existed for a long time, and many large teams use them. You can even use Gradle to build an iOS project.
Does Apple officially support any of those? No, you won't find any Apple instructions telling you how to do any of this, Apple expects iOS apps submitted to the store to be built with Xcode. You're on your own with these solutions. And setting up Bazel for an iOS project is not an easy undertaking.