dathanb82

That’s like saying that the code in a repo belongs to the whole team once a PR is merged, so it doesn’t make sense to track its provenance back to its original authors.

Sort of? The kotlin standard library yes, but it’s pretty rare to write an app with only the standard library. It feels like you’re dismissing the Java interop as a secondary benefit, but for most uses of Kotlin it’s probably more important to project success than the language itself. So I think it’s accurate that without the JVM Kotlin would be essentially dead.

Pretty sure it’s the other way around: Kotlin was implemented on the JVM and that’s its primary target, and got a native implementation later for folks that don’t want to run a JVM.

I mean, he left Palantir over a decade ago and now he’s supposedly retired (again) - I bet he’s pretty chill about it these days.

If "inference is cheap," why is OpenAI spending a ton getting Broadcom to design custom AI chips that make inference cheaper? Reports suggest their custom silicon isn't all that good for training, it's all to make inference more efficient. That shouldn't be necessary if inference is already quite cheap.

Two other similarities: they both rely on burning huge amounts of electricity, and have driven up costs of GPUs around the world.

This is a good take. The most effective combination of AI and skilled practitioner is using AI to amplify the abilities of the skilled practitioner. And in particular, max benefit comes from exploiting comparative advantage. AIs are really good at boilerplate -- in many cases better than humans because humans will optimize the process by doing copy/paste and often inject errors in the process -- whereas humans are better at abstract and critical reasoning. There's a very real and valuable use case for AI, but it's not replacing humans, it's taking the things that humans don't like doing (and that a computer can do well already) off the human's plate, so humans can focus more exclusively on the things that they do better than the AI. And at least with the current architecture of AI models, there will _always_ be higher-level reasoning that humans do better than the machine.

I’ve also heard it being called “comprehension debt,” which I like a little more because I think it’s more precise: the specific debt being accrued is exactly a lack of comprehension of the code.

Vimwiki?

Unless you have a “every commit must build” rule, why would you review commits independently? The entire PR is the change set - what’s problematic about reviewing it as such?

Skills are part of the repo, and CLIs are installed locally. In both cases it's up to you to keep them updated. MCP servers can be exposed and consumed over HTTPS, which means the MCP server owner can keep them updated for you.

Better sandboxing. Accessing an MCP server doesn't require you to give an agent permissions on your local machine.

MCP servers can expose tools, resources, and prompts. If you're using a skill, you can "install" it from a remote source by exposing it on the MCP server as a "prompt". That helps solve the "keep it updated" problem for skills - it gets updated by interrogating the MCP server again.

Or if your agentic workflow needs some data file to run, you can tell the agent to grab that from the MCP server as a resource. And since it's not a static file, the content can update dynamically -- you could read stocks or the latest state of a JIRA ticket or etc. It's like an AI-first, dynamic content filesystem.

Oh man, Turbo Pascal was my first "real" programming language -- it was all various flavors of BASIC before, and mostly toy projects. The developer experience with Turbo Pascal (by which I guess I mostly mean Turbo Vision) was honestly pretty great

The use of XML as a data serialization format was always a bad choice. It was designed as a document _markup_ language (it’s in the name), which is exactly the way it’s being used for Claude, and is actually a good use case.

And do what? Leave the ducting, pipes, and electrical lines exposed for the one time in 20 years you need to do something with them?

In addition to being much more attractive than exposed infrastructure, drywall and the insulation that gets put behind it help make your house much more energy efficient.

As you might expect from the description -- largely passed on via contaminated water -- the guinea worm is mostly present in areas of extreme poverty. Even if such a treatment were feasible, it would be inaccessible to most of the relevant population.

It’s probably even more pronounced, since it’s unlikely that someone is going to _average_ 180bpm for their entire workout, especially as they get older.

The auto-attach flag isn’t a huge deal, since it’s a one-liner that can be statically documented and the fix works in all cases. The bigger issue is the JDK / runtime team’s stance that libraries should not be able to dynamically attach agents, and that the auto-attach flag might be removed in the future. You can still enable mockito’s agent with the —javaagent flag, but you have to provide the path to the mockito jar, and getting that path right is highly build-system-dependent and not something the mockito team can document in a way that minimizes the entry threshold for newcomers.

Just shy of $600K in 2022, based on data from IRS and BLS: https://smartasset.com/data-studies/what-it-takes-to-be-in-t...

It's available (usually as an optional feature) in lots of languages where dependencies are linked statically. The most standard terminology I'm aware of for it is "dead code elimination"

In Javascript, webpack (as well as other module bundlers) supports it, though they call their dead code elimination mechanism "tree shaking".

Lets you define queries over some data set declaratively, and instead of recomputing the query over the entire data set every time you want an updated answer, it uses Differential Dataflow <https://github.com/frankmcsherry/differential-dataflow> to efficiently(^1) calculate the new results by updating the results of the previous query execution in response to new updates to the data set.

^1: I'm not an expert on Differential Dataflow, so I don't know what "efficiently" means in this context, other than "should be faster than running the query from scratch."

Every time I see a "X: a [new/better/best/modern/postmodern/blazingly fast] Y" post on HN, I just know it's going to be written in Rust

"I wouldn't use a gun that sounded like that" - me to my wife just about every time we watch an action movie

Unless the purpose of the game is educational, I don't think it's incumbent on them to educate their players about anything. Just like I don't expect everyone who sells something at the Renaissance Faire to use medieval furnaces for their blacksmithing or to eschew lathes for turning wood bowls. It's not their responsibility.

At a basic level, yeah. It gets hairy when you dive into timeout handling and dealing with errors in reconciliation, across multiple gateways.

tl;dr: there is no easy part

> They also moved all of my recurring charges to my new card (somehow.)

If you're curious about how this works, read up on "Visa Account Updater".

The most impressive part to me is how much snappier it is than Photoshop running locally on my machine.

But also > You can paste source code directly into your Markdown document without any changes, and it will appear as expected in the rendered HTML. That’s my doing.

In that sentence, it kinda does sound like they're trying to take credit for it.

I can't remember the last time the speed at which I could physically produce code was the bottleneck in a project. It's all about design and thinking through and documenting the edge cases, and coming up with new edge cases and going back to the design. By the time we know what we're going to write, writing the code isn't the bottleneck, and even if it takes twice as long, that's fine, especially since I generally end up designing a more usable interface as a result of using it (in my tests) as it's being built.

I was prepared to be upset that this article is an almost word-for-word copy of the "overview" page on the arc42 website (https://arc42.org/overview). But then I saw that the author is one of the arc42 maintainers. Now I need to find another target for my righteous indignation.

But RNA / DNA isn't sufficient for life, right? How are proteins synthesized from that string of nucleotides without ribosomes? And nucelotides randomly reshuffling certainly doesn't explain how ribosomes would be created.

It's theorized that under the right conditions amino acids will bond to become proteins without needing the mediation of a ribosome. So it's certainly possible that with enough primordial soup you could get proteins. But that doesn't explain how the nucleotide string ends up getting treated as a reusable blueprint for proteins.

That seems like a pretty big gap.