If we depend on less then we are capping what we can build to only what we can write and manually integrate. This is dis-empowering.

I'd argue quite the opposite. You can build a lot more than you think, you just need to be encouraged.

if you depend on more, you are capping what you can build to only what you can manage to get working and integrate, plus you also lose control over the code; for me personally, it's a lot easier to write a complicated algorithm, than it is to figure out a complex build system for a random library in the wild (with few exceptions like miniaudio); and it's especially worth it, because when i understand the problem, i can usually define a way better api for my usecase than any library writer can

In an alternate reality maybe Creative went from Audio cards to MP3 players to Smartphones and GPUs

They tried, sort of, in 2002 they acquired 3DLabs. Wish they kept making MP3 players though, but that market collapsed in on itself with the rise of smartphones. A shame, for a few years I had both a smartphone (Galaxy A) and an MP3 player (ipod touch, but I miss my mini/nano) separately. I really wouldn't mind a dedicated music player again.

LLM generated variable names would be nice!

More people who are not traditionally programmers are now writing code with AI assistance (great!) but this crowd seems unlikely to pick up Clojure, Haskell, OCaml etc... so I agree this is a development in favor of mainstream languages.

Imo there's been a big disconnect between people who view code as work product vs those who view it as a liability/maintenance burden. AI is going to cause an explosion in the production of code, I'm not sure it's going to have the same effect on long term maintenance and I don't think rewriting the whole thing with ai again is a solution.

Any they don’t understand it. So they get something that kinda half works and then they’re screwed.

Not sure.

Even for small projects the optimisation criteria is different if the human's role in the equation shifts from authoring to primarily a reviewing based one.

Is this AirDrop but cross-platform?

Addressed in the FAQ:

> How is Blip different to nearby sharing like AirDrop? Apple’s “AirDrop” and Google’s “Nearby Share” can be really handy. However, they aren’t compatible with each other and require devices to be physically next to each other. They are also unreliable when transferring large files, and will often lose your progress.

> Blip doesn’t need devices to be nearby, so it’s much more reliable. Blip works wherever your internet connected devices are in the world, and works regardless of what kind of device you own. You can transfer from Android to Mac, Windows to iPhone, iPad to Android—you name it!

No.

AirDrop is for people who are physically nearby.

This allows to send files between any computers anywhere.

The other person must be a known contact but it doesn't have to be on the same local network like in AirDrop.

There’s a new AirDrop feature that also transfers over the internet: https://allthings.how/how-airdrop-over-internet-works-on-iph...

> To start AirDrop over the Internet, initiate the AirDrop as you normally would

...

this is hardly the same thing?

The designer of the type must manually ensure exhaustive checking but then consumers will be forced to do exhaustive matching.

It's not that bad in practice.

I love this sentiment:

> There should be one-- and preferably only one --obvious way to do it.

But I often don't think the Pythonic way is a very good way to do it. And this leaves you a bit stuck!

If you write out `requirements.txt` by hand, do you also need to resolve deps and transitive deps by hand?

This is what pushed me to use Poetry.

I write my high level dependencies by hand in a "requirements.in" for applications, and in "pyproject.toml" for libraries.

A simple "requirements.in" I did over this weekend was a single dependency:

    miniboss >=0.4, <0.5

And used pip-compile to pin all transitive dependencies:

    pip-compile -o requirements.txt requirements.in

This generated a "requirements.txt" with 14 dependencies with pinned versions:

    attrs==25.3.0
    ...13 more dependencies
    

It's then only a matter of running "pip install -r requirements.txt" in the venv for my "application" (wrapper scripts for Docker).

I've largely settled on this scheme for work and person projects because it's simple (only dev dependency is pip-tools or uv), and it doesn't tie me to a particular Python project management tool (pipenv, pdm, poetry, etc.).

You do not write requirements by hand. You write requirements.in and uv pip-compile to requirements.txt

Does `pip-compile` solve deps and transitive deps?

I thought it only locks down hashes?

Yes it does. And it will fail if there is a combination that is not resolvable.

Does ML have do notation?

In ML do you need to write `List.map` where in Haskell you can write `map` and it infers the type?

UV looks very promising but I can assure you, if everyone adopted it tomorrow we would see a long tail of scenarios that UV does not work well for.

I would love to see that happen and see how astral responds. I would love to see uv get built into Python 4

I am perfectly content for a 90% solution, we should not let the perfect be the enemy of the good.