sheept

On mobile, this website seems to prevent you from pinch zooming in, which makes it slightly inconvenient to quickly zoom into the photos of the trees.

I think it is occasionally used with "the," i.e. "the conscious" (referring to the conscious part of your body, for example). Adjectives sometimes become nouns this way, like "the poor"

This article[0] investigated the payload. It's a RAT, so it's capable of executing whatever shell commands it receives, instead of just stealing credentials.

[0]: https://safedep.io/axios-npm-supply-chain-compromise/

I wonder if GitHub would rule it a copyright violation if the source code was rewritten by an agent, i.e. copy my answers but change a few words. Legally, if the original source code is copyrighted then an agent rewriting it likely doesn't lose that copyright, but I wonder if GitHub would go through the effort of determining whether it was a derived work.

It could probably store the code in the Cache API and serve it from a service worker so that it works offline and doesn't require evaling JavaScript

That's because browsers are the most battle tested sandbox out there. It's not worth developing another sandbox if they already have Safari webview.

CJK text is typically rendered as 2 columns per character, but in general this is dependent on the terminal emulator

Why? I don't see this pedantry for headlines for other countries like China did this, the UK does that. I think it's well understood that it's referring to the government, not a generalization of its people.

It's not really paranoia if it's happening a lot. They wrote a blog post calling several major Chinese AI companies out for distillation.[0] Perhaps it is ironic, but it's within their rights to protect their business, like how they prohibit using Claude Code to make your own Claude Code.[1]

[0]: https://www.anthropic.com/news/detecting-and-preventing-dist... [1]: https://news.ycombinator.com/item?id=46578701

As a reviewer, I do care. Sure, people should be reviewing Claude-generated code, but they aren't scrutinizing it.

Claude-generated code is sufficient—it works, it's decent quality—but it still isn't the same as human written code. It's just minor things, like redundant comments that waste context down the road, tests that don't test what they claim to test, or React components that reimplement everything from scratch because Claude isn't aware of existing component libraries' documentation.

But more importantly, I expect humans to be able to stand by their code, and at times defend against my review. But today's agents continue to sycophantically treat review comments like prompts. I once jokingly commented on a line using a \u escape sequence to encode an em dash, how LLMs would do anything to sneak them in, and the LLM proceeded to replace all — with --. Plus, agents do not benefit from general coding advice in reviews.

Ultimately, at least with today's Claude, I would change my review style for a human vs an agent.

One feasible scenario could be that they are working on/experimenting with ads, and it was put behind a feature flag, but for whatever reason it was inadvertently ignored

Creating 3D scenes with CSS has always been possible[0], but like this project, it's required JavaScript for interactivity.

But there's a lot more CSS features now. While in the past, Turing completeness in CSS required humans to click on checkboxes, now CSS can emulate an entire CPU without JavaScript or requiring user interaction.[1] So I wonder if DOOM could be purely CSS too, in real time.

[0]: https://keithclark.co.uk/labs/css-fps/ [1]: https://lyra.horse/x86css/

Not in Claude Code, where asking it to print the XML used for tool calling makes it accidentally trigger the tool call

If you look at the code above, the temperature and weather are selected independently randomly. That alone is not indicative of AI-generated code; a human could write something similar for demo/learning purposes.

> LLMs return malformed JSON more often than you'd expect, especially with nested arrays and complex schemas. One bad bracket and your pipeline crashes.

This might be one reason why Claude Code uses XML for tool calling: repeating the tag name in the closing bracket helps it keep track of where it is during inference, so it is less error prone.

Not only that, but LLMs do a disservice to themselves by writing inconcise code, decorating lines with redundant comments, which wastes their context the next time they work with it

"Ours" and "theirs" make sense in most cases (since "ours" refers to the HEAD you're merging into).

Rebases are the sole exception (in typical use) because ours/theirs is reversed, since you're merging HEAD into the other branch. Personally, I prefer merge commits over rebases if possible; they make PRs harder for others to review by breaking the "see changes since last review" feature. Git generally works better without rebases and squash commits.

doesn't it? Next to the conflict markers, it'll display HEAD, the ref name, or the short commit hash.

All software has bloat, but npm packages and web apps are notorious for it. Do you think it could be inherent to the language?

JavaScript seems to be unique in that you want your code to work in browsers of the past and future—so a lot of bloat could come from compatibility, as mentioned in the article—and it's a language for UIs, so a lot of bloat in apps and frameworks could come from support for accessibility, internationalization, mobile, etc.

You can't completely prevent the browser from sending the request—after all, it needs to figure out whether to block the website from reading the response.

However, browsers will first send a preflight request for non-simple requests before sending the actual request. If the DDOS were effective because the search operation was expensive, then the blog could put search behind a non-simple request, or require a valid CSRF token before performing the search.

I wonder this means there could be a faster npm install tool that pulls from a registry of small utility packages that can be replaced with modern JS features, to skip installing them.

Because formatters are increasingly popular, I think it'd be interesting to see a language that refuses to compile if the code is improperly formatted, and ships with a more tolerant formatter whose behavior can change from version to version. This way, the language can worry less about backwards compatibility or syntax edge cases, at the cost of taking away flexibility from its users.

> I would love to see a language try to implement a rule where only an indented line is considered part of the previous expression.

Elm does this (so maybe Haskell too). For example

    x = "hello "
     ++ "world"

    y = "hello "
    ++ "world" -- problem

Not only that, but they helped push for new web APIs and language features for server runtimes, like URLPattern

I bet that for the second random number in the same session, it is significantly less likely for an LLM to repeat its first number compared to two random draws. LLMs seem to mimic the human tendency to consider 7 as the most random, and I feel like repeating a random number would be perceived as not random.

It depends on the minifier (SVG optimizers do this too), but yes, they may reduce the precision of colors. I checked and esbuild will turn lab() into a hex color if possible.

UTF-32 allows for constant time character accesses, which means that mystr[i] isn't O(n). Most other languages can only provide constant time access for code units.

Would it work to run a bundler over your code, so all (static) imports are inlined and tree shaken?

Since align is only deprecated and not removed, and Markdown is a superset of HTML (at least for CommonMark and GFM), it would be valid markdown to just use <div align=center> to center text (not like there's such a thing as invalid Markdown)

Scratch supports Korean, but Scratch benefits from using JSON instead of bytes or code points to serialize programs, which allows the user to change their display language (similar to how hard tabs let users set indentation size).

There's probably a lot of reasons why non English programmers stick with English keywords, beyond just language/tooling support. Learning new keywords is already part of learning a programming language, and much of the documentation and resources available for languages and libraries are only in English. ASCII-only strings are still ubiquitous in software, like URLs and usernames. And in international teams, English is the go-to lingua franca.

Could this change with LLMs? Maybe, but most code in its training data is in English, so LLMs likely work most effectively in English.