The puzzle pages also give pretty strong AI vibes to me. I think it just reminds me what I've gotten from Claude when I let it decide on design.
Some of the specifics that come to mind:
- the use of emojis instead of icons
- the text content largely sounds like it's written by Claude. This is a big one and it's everywhere: the names of the games, the descriptions, the status texts, basically every single piece of text that I've read.
- the fact that text is being used for some things at all feels a bit Claude-y, like the "Today's result: pending" status or "Vibes are perfected. Well done."
- a lot of the color scheme feels AI somehow. It's interesting, because it's not like the colors are wrong or anything, they somehow just feel like "default" LLM colors
Yeah it's definitely a mix of AI and me haha. The names, color schemes, and status texts are good callouts. The emojis I actually introduced to start to have a theme across games, though I didn't put them in the org chart game. A lot of the copy was written by AI, and then I didn't like the output and changed it.
I appreciate the feedback that it felt off. That's what matters in the end. Thanks for the taking the time to share this.
Tangentially, I see a lot of people here upset that apps can react to your screenshot before it is captured. I think it is helpful to think about it as a tradeoff between freedoms:
(a) the freedom to screenshot any content on your own device
(b) the freedom to share content with others that cannot be screenshotted
It can be annoying when DRM or privacy features block a screenshot, but I think it can also benefit the platform ecosystem that you participate in as a user too. Idk!
If a type of lock was overwhelmingly used for bad reasons, and only worked when someone didn't cover their hands (analog pictures), I'd be arguing against that type of lock too.
Is it a “bad reason”? Millions of people chose to use Snapchat specifically because of how it handles screenshots. It is a feature even if you don’t like it.
Many people would find it inconvenient to find another device to take a picture with. And that manual picture would then have baked-in evidence that it was taken surreptitiously.
Locks keep honest people honest, as long as the app is up front about it and lets users make the choice, I don’t mind.
Another view of it is that’s just a creative use of the medium. An interactive button doesn’t serve any purpose in the screenshot, so why not find a better use for that space.
When I’m in Safari, taking a screenshot can turn into a totally separate operation (full page scrolling screenshot) and that’s a good feature.
Others complain about Google Maps showing a popup telling the user about location sharing upon screenshot - I think that makes a lot of sense, considering it doesn’t show up in the screenshot and dismisses easily.
I’m very harsh on user hostile choices, in fact I spend a lot of time ranting and raving about it, but I just don’t see that here.
The ability to show exactly what you had on your screen is one of the biggest uses of screenshots. The ability for apps to do this kind of thing breaks that use.
Offering something better can be valuable (sometimes) but don't alter the screenshot itself.
when naming the protocol part of a url, obviously you don't want to pick something so verbose, but that doesn't mean you gotta pick an acronym. could be hyper:// or smth. not saying it should be, just saying there are other ways that a more verbose concept can be shorted for certain contexts
These days I mainly write Rust but I did write a semi complex iOS app and enjoyed Swift. I just didn't love how slow the type checker was and how it got lost. I recall having to break things into smaller bits to help the compiler, and there were some oddities about the language.
The gap between the two languages is quite small, it just makes me wish Apple was also all-in on Rust
In the last year they’ve added improvements to the type checker to speed it up, those would have been released now.
They have further and much more significant changes that I think might have recently landed in the development version. That should make an even bigger difference. But it’s not in a released version yet.
And yes, none of us like that one part of Swift. Especially the DRASTIC difference compared to objective-C which really only checked syntax and little else.
It’s still probably my favorite language right now though I don’t get to write in it much.
I can assure you that Rust will never have a ++ operator. Not only is it semantically bizarre, it's entirely unnecessary in a language where iteration is overwhelmingly performed via iterators rather than via manually incrementing array indices.
Is that a bullet point in the Rust manifesto? :) In any case, ++ has taken another meaning outside of operator loading and such some.
The “Rust” branding, to this rando, implies corrosion, oxidation, decay, regardless of the true origin of the name. Swift is “quick”, Java is “caffeine”, Rust is something I need kerosene for.
Yes, it is pretty universally agreed upon that a ++ operator in Rust doesn’t make any sense. += 1 is barely longer, not special cased, and does not make users memorize odd precedence rules.
Right, but the whole reason C++ is named C++ is because ++ is a valid operator in C. Without the operator in Rust, making the brand of a successor based on a feature from an entirely different language doesn't make any sense.
There’s no reason to invent your own head canon, the influence was openly acknowledged when Swift was new and it continues now that the language is developed out in the open (see Swift Ownership Manifesto)
I believe Swift tends to use reference counting and copy-on-write strategies. This, like GC, is less for the programmer to think about and doesn't require the semantic checks, but sometimes the performance cost is unacceptable compared to what you'd write in Rust.
You can choose to use either refcounting or unique ownership for your types. For most use cases, refcounted (+ copy-on-write) is the best choice and is the default, but the truetype interpreter made extensive use of non-refcounted types to achieve this performance.
They have either recently added or talked about a borrow style system in the language as a way to avoid more copies and speed things up/lower memory usage/help with asynchronous programming.
And you are absolutely correct. I've seen the DT page thanks to the linked HN submission (actually comment [1]. And incorrectly associated the DT article incorrectly today. Thank you.
- i pressed "Amino Acids", and nothing updated below the toolbar. can't figure out what it does
- the "Tools" buttons looks like a segmented picker, but both seem to actually initiate a modal presentation
this tool seems interesting, but it would be worth polishing some of these ui quirks because my first impression was that it seems a bit broken (or confused me)!
but seems like a cool project otherwise, love people building and sharing explainers as they learn stuff!
might be worth trying to tweak to look less like the default ai theme
cute overall tho!