sheept

It is an en dash, not an em dash, since it's about as wide as an n.

Some software substitutes a double hyphen -- with an en dash rather than em, and use the triple hyphen --- for the em dash. Perhaps Hacker News' title formatter is one of them.

That's interesting. I think the bikes-facing-left bias probably comes from how humans use bikes: the kickstand is on the left, so people likely hold and approach bikes from its left.

Looking online, the kickstand is apparently on the left to avoid the gears. Based on the other comment about bike photography, it's interesting the same design choice makes humans and cameras/LLMs see bikes from different sides.

I find it mildly interesting how your comment repeats itself but with different phrasing

Machine learning used to be used as a buzzword alongside AI, though nowadays after the release of ChatGPT it seems they've settled on AI.

Why would it be at odds with accessibility? The text contrast is excellent in each section, and the light/dark segments clearly define the border between sections. Forced dark mode can be difficult to read for users with astigmatism, but the font size is large, and the actual documentation sites[0] do have a light/dark switch.

[0]: https://elixir.hexdocs.pm/1.20.2/

Designs can't be easily split into a pure light or dark mode, though. Before light/dark modes were popularized, it was common to have some parts be "dark" and other parts be "light," depending on the design (for example, would the iOS 5 game center be "dark mode"?). Elixir's website uses a mix of light and dark to delineate sections.

One consequence of software recently supporting light and dark schemes is that UI designs end up committing to all white or all dark, rather than tastefully choosing a color scheme that best frames its content in context.

Linguistically it's particularly interesting since it marks the habitual aspect, and standard English has no grammatical equivalent.[0]

[0]: https://ygdp.yale.edu/phenomena/invariant-be#who-says-this

It only works if you give it a screenshot, but it wouldn't work to block AI scrapers or fetch tools, and I think if printed out, it wouldn't work reliably if you took a photo, especially from afar

My guess is that it takes time to research what universal behavior users expect from a component based on examples in existing software. It's universal, so it has to work with everyone: mouse, keyboard, touch; large monitors and tiny phones; screen readers; and users with motor difficulties. And existing components may not have even thought of all of these cases.

For example, they've recently introduced the Interest Invoker API for tooltips on hover. Tooltips are ubiquitous, but they still haven't settled on what the trigger is for non-mouse users. Long press for touch is far less discoverable than mouse hover, for example.

Maybe it's a good thing they didn't rush this design three decades ago, when virtually all users were on desktop.

Isn't that alternate reality the current reality?

For whatever reason, developers and some users expect an app to look the same across all platforms, while also looking distinct from other apps—otherwise, the app looks indistinguishable from a low effort one. This involves creating a design system and departing from each operating system's native widgets.

The severity depends on where you are, even within a country, but in many places you can't authentically "function as an adult in the world" without a phone, unless you want to roleplay an adult from the previous century.

In some places, payment requires a phone. Tracking unreliable public transit requires a phone. Getting rideshare requires a phone.

The issue probably isn't the phone but letting them outside in the first place.

Python is 0-indexed. In OP's example, the start parameter makes i start at 1.

Their C++17 example prints starting from 0. Probably a mistake.

If you look at the linked page for C++20[0], other types can be put in the initializer statement, so it's unlikely the loop auto-increments.

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p06...

Even em dashes have been discouraged by some writers [0] before LLMs because they're easy to overuse.

[0]: https://slate.com/human-interest/2011/05/em-dashes-why-write...

Vanilla JavaScript makes sense for personal projects, but if you're working on a team, I wouldn't trust other team members to not create their own frameworks that may not be as well documented.

Especially nowadays with LLMs, the team would benefit more from the LLM innately knowing a widely used library/framework than having to spend context each session teaching the agent your custom setup through context files and skills.

Why not store them as integers? Representing dates is a UI responsibility

Why do you need both Biome and Eslint/Prettier?

Personally I'm a bigger fan of base 6[0], which have many of the benefits of base 12, but the digits of simple fractions like 1/5 and 1/7 render more nicely in base 6 than base 12.

[0]: https://www.seximal.net/ is one advocate

I'd've thought modern weeks have biblical origins rather than being based on quarter moon phases.

I would assume that "Esperanto written in pure ASCII" is referring to x-sistemo, which avoids the diacritics

Aren't LLMs trained on and optimized for human code? In general, anything that is concise is more effective as context for the LLM, whether it be your CLAUDE.md or code, since LLMs are meant to model human language.

My hypothesis is that Claude is inclined to write so many comments as a way of doing additional thinking

Does this respect llms.txt and robots.txt, or have you found it more effective if agents see what humans see?

It depends, but for larger projects, you might have tooling for TypeScript that relies on its API, which isn't available in TS 7.0.

Any page can silently trigger an additional multi-gigabyte download for Chrome users by just calling this API:

    await LanguageModel.create()

Since the model is installed once per browser, LanguageModel.availability() could probably also be used for fingerprinting.

It's relatively easy to write many words, but it takes more skill to express the same message with fewer words, like how video compression needs more time for fewer bytes and same quality. As Pascal once wrote, "If I had had more time, I would have written a shorter letter."

In Elm 0.19, they removed the ability for third party packages to provide native bindings for JavaScript APIs that the language or its official packages didn't yet support.[0] The only alternative proposed by Evan is to use ports, which are about as ergonomic as calling a function in a web worker.

[0]: https://discourse.elm-lang.org/t/native-code-in-0-19/826

When I worked on an Elm app in 2020, my users reported compatibility issues with various browser extensions (e.g. Grammarly, 1Password). I personally would prioritize making my apps usable for my users over making the DX usable for myself, so I stopped using Elm for future projects.

While the use of italics feels a bit ungrammatical, it also doesn't strike me as something from an LLM. An LLM would've tried bolding it if it could, and it wouldn't have written a comment this concise.

Another reason why this is problematic is that their proposed standards follow Google's priorities for its own products, particularly Google Meet.[0][1]

[0]: https://developer.chrome.com/docs/web-platform/element-captu...

[1]: https://developer.chrome.com/docs/web-platform/document-pict...

At the very least, Firefox's position on the similar <geolocation> element is positive.[0] I would assume their position for other permissions elements would be the same.

[0]: https://github.com/mozilla/standards-positions/issues/1288