sheept

I guess that makes sense. Since most non-privacy-focused Android distributions don't let users turn off the internet permission, keeping the permission secure likely ceased to be a priority.

The full list of bypasses is likely much larger because it doesn't fall in the scope of bug bounties.

It's pretty interesting that while both languages still receive new features, Java seems to stay ahead of JavaScript:

- Java has long had a modern replacement for Date, while JavaScript's recently standardized Temporal API still isn't supported in Safari.

- Java has switch expressions, while JavaScript, despite its Scheme influence, does not.

- And now Java is getting value objects, while JavaScript's equivalent tuples & records proposal has been withdrawn.[0]

JavaScript was not developed as a fork of Java, but much of its basic syntax still resembles Java, so I think it's fair to compare them.

[0]: https://github.com/tc39/proposal-record-tuple

The main drawback with the page's unstyled design is that the page is not mobile friendly.

Publishing web pages by manually editing HTML files is still very common today; any GitHub Pages blog does this.

One of the strengths of TypeScript besides its expressiveness is that it's compatible with the massive npm ecosystem. Most packages only ship untyped JavaScript with type declarations defining the interface,[0] so realistically you'd still need a JavaScript engine if you use any packages.

But if you're starting from scratch and know you won't be using any npm packages, you might as well use AssemblyScript.[2]

[0]: Publishing packages in TypeScript is explicitly discouraged by Node[1]. TypeScript isn't backwards compatible even in minor releases, and its compiler settings aren't portable for packages.

[1]: https://github.com/nodejs/node/blob/main/doc/api/typescript....

[2]: https://www.assemblyscript.org/

It'd be nice if there was a live demo without needing to clone the repo. Though I suppose I could just try it out with a bookmarklet:

    javascript:import('https://esm.sh/writemark-editor').then(() => document.body.append(document.createElement('writemark-editor')))

I'm surprised it doesn't use proper HTML by default. I wasn't able to tab focus on the Administrator button on the login screen, and it turns out it's because the entire UI is div spam.

I personally rely on this behavior of LLMs. For example, for reviewing prose, I might ask the LLM to find five issues. If there are obvious issues I missed, then it'll find them. But if all the issues it lists are minor or hallucinated, then I can have some confidence there weren't any glaring issues.

I do the same for LLM code review comments: some changes are out of scope or could be moved to a separate PR; some edge cases don't happen in practice and should just fail noisily instead of writing more code to maintain. When these are the only issues it's raising, then I know it's done.

> - dash: compounds word-parts (Sarbanes-Oxley)

That's a hyphen, and (to be pedantic) style guides usually do not consider it a dash.

There's also the 2-em dash in some style guides for redacting words, and since care needs to be taken to avoid a line wrap between the em dashes, Unicode has a character for it: ⸺

Finally,

> - em dash: adjoining thought (Hey, so — <declaration>)

This use is sometimes discouraged by style guides, and in many cases, it can be replaced with a colon, comma, or semicolon.

In general, even before AI, the em dash is often considered overused.[0] My guess is that the em dash is perceived as sounding educated, so novice writers who learn about it end up using it recklessly, and LLMs could've picked up this habit from them.

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

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?