> I [...] fit a hyperbolic model to each one independently
^ That's your problem right there.
Assuming a hyperbolic model would definitely result in some exuberant predictions but that's no reason to think it's correct.
The blog post contains no justification for that model (besides well it's a "function that hits infinity"). I can model the growth of my bank account the same way but that doesn't make it so. Unfortunately.
Indeed. At various points you could have presumably done an identical analysis with journal articles and climate change, string theory, functional programming… terms & reached structurally the same conclusion.
The coming Singularity: When human institutions will cease being able to coherently react to monads!
If I understand the author correctly, he chose the hyperbolic model specifically because the story of "the singularity" _requires_ a function that hits infinity.
He's looking for a model that works for the story in the media and runs with it.
Your criticism seems to be criticizing the story, not the author's attempt to take it "seriously"
For example: you generate a file (code, dataset, document, AI output) and later need to prove it already existed at a certain time.
TimeProofs lets you create a small proof file you can keep. Anyone can later verify the timestamp without seeing the original content.
To me that's "what it does" whereas I'm wondering when it would be useful.
In other words, I can't think of a use case in industry or academia or daily life or whatever, where someone needs to prove that a file existed at a specific time
Fair question.
It’s useful when you need to prove priority or existence without revealing the content.
Examples: – You wrote something (code, research, idea) and want proof it existed before publication or disclosure.
– You generated AI output and want to prove it wasn’t altered later.
– You exchanged a document (contract draft, design, dataset) and want a neutral timestamp without involving a third party or storing the data.
– You want evidence before a dispute, not after one starts.
It’s not for everyday files — it’s for moments where “this existed at this time” might later matter.
This keeps it grounded, avoids hype, and sounds like a real human explaining a niche tool.
> don't want to have virtual environments and learn what the difference between pip, poetry and uv is
Oh come on, it's easy:
Does the project have a setup.py? if so, first run several other commands before you can run it. python -m venv .venv && source .venv/bin/activate && pip install -e .
else does it have a requirements.txt? if so python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt
else does it have a pyproject.toml? if so poetry install and then prefix all commands with poetry run ...
else does it have a pipfile? pipenv install and then prefix all commands with pipenv run ...
else does it have an environment.yml? if so conda env create -f environment.yml and then look inside the file and conda activate <environment_name>
else does it have a uv.ock? then uv sync (or uv pip install -e .) and then prefix commands with uv run.
If you've checked out a repo or unpacked a tarball without documentation, sure.
If you got it from PyPI or the documentation indicates you can do so, then you just use your tooling of choice.
Also, the pip+venv approach works fine with pyproject.toml, which was designed for interoperability. Poetry is oriented towards your own development, not working with someone else's project.
Speaking of which, a project that has a pipfile, environment.yml, uv.lock etc. and doesn't have pyproject.toml is not being seriously distributed. If this is something internal to your team, then you should already know what to do anyway.
It is not "no true scotsman" to point out that tons of projects are put on GitHub etc. without caring about whether others will actually be able to download and "install" and use the code locally, and that it's unreasonable to expect ecosystems to handle those cases by magic. To the extent that a Python ecosystem exists and people understand development within that ecosystem, the expectations for packaging are clear and documented and standard.
Acting as if these projects using whatever custom tool (and its associated config, by which the tool can be inferred), where that tool often isn't even advertised as an end-user package installer, are legitimate distributions is dishonest; and acting as if it reflects poorly on Python that this is possible, far more so. Nothing prevents anyone from creating a competitor to npm or Cargo etc.
The only problem the author points out is that he doesn't like the Cantril Ladder question.
I get it if you feel like that question falls short of representing your own personal concept of happiness, but that question is the standard in positive psychology research for measuring self reported subjective well being, and hardly enough to say the report is "beset with methodological problems".
They give several well-considered criticisms of the question - it leads people to focus on socioecomonic status, it doesn't correlate with other measure like whether they report experiencing joy recently, etc. It's not much of a defense to simply say "well, it's the standard".
My criticism is about how the dramatic language differs from the banal content of the article.
Titling it "The World Happiness Report Is a Sham" and calling it "beset with methodological problems", I would expect some more serious scientific malpractices, like data fabrication, calculation errors, sampling problems, p-hacking, etc., not "I think there are some problems with this variable".
Disagree. Whether I'm entirely fabricating data that claims A by writing numbers into an Excel sheet, or whether I'm doing a survey that measures B and then claim it means A, isn't materially different in outcome. The outcomes are just as bad, and that's what people care about. Maybe you as a researcher care that the former is more immoral, but to everyone else it doesn't matter.
I think there's a difference in outcomes between fabricating data, and getting data that still remains validly gathered, but measures something subtly different.
And I think the general public can make meaning of that
difference and have a stake in both – in the same way that the general public knows that stock market values and economic security are different things, even though people still have a lot riding on retirement plans based on stock investments.
Is joy related to happiness, or are they two separate concepts? That depends on your cultural background and the languages you speak.
The World Happiness Report can be traced back to the UN General Assembly Resolution 65/309, which was proposed by Bhutan. Therefore the intended definition of happiness in this context is similar to the one in Bhutan's Gross National Happiness index.
The more practical problem is that the samples used in the Gallup World Poll are for largely unavoidable reasons small and not representative of entire country demographics; in particular respondents can skew richer and more educated than their national average in poorer countries.
> """
I'm strongly in favor of blocking post-install scripts by default. :+1:
This is a change that will have a painful adjustment period for our users, but I believe in ~1 year everyone will look back and be thankful we made it. It's nuts that a [pnpm|yarn|npm] install can run arbitrary code in the first place.
"""
There is actually a good reason not mentioned, not to name tools by their purpose:
- the purpose will change
Your "silicon-valley-bank-integrator" tool will eventually need to be updated to do something else.
Or your "login-page-config-service" tool may eventually do more than just logins.
Using gibberish or mythological names gives a nice memorable name that doesn't lead (or mislead) you to believe it does a particular thing which may or may not be correct anymore.
Also, being too precise and succinct about what the tool does ends up in a race for the name in competing implementations.
Project names should be unique enough to allow them becoming their Id,
- It allows to find the project.
- It allows the project to change, extend it's scope or narrow it.
Having an Id is really important, making that Id related to the project's original intention is nice, but secondary. (as long as it doesn't change enough that it becomes misleading).
"purpose will change" argument actually proves the opposite point. When a tool's scope expands beyond its name, the descriptive name tells you something went wrong. But even if so, if you have to rename "login-page-config-service" to "auth-config-service" it is not really a big deal, renaming will be much cheaper if you're renaming to descriptive names. Most importantly though, I wouldn't optimize to avoid renaming (happens once, maybe twice in a project's lifetime) by making discovery hard (happens every single time someone encounters the tool).
> renaming will be much cheaper if you're renaming to descriptive names
Idk, renaming things that shipped is a PITA.
Say you wanted to rename `fish` to `a-decent-shell`.
- Packages in all distros would need to be renamed.
- Configuration for all systems using/having fish would need to change.
- Scripts would need to change, from the shebang to the contents if necessary.
- Users would need to understand that they now need to search documentation using the new name.
- Documentation would need to be migrated to new domains, sed-replaced, and reviewed.
All this migration would require some synchronized, multi-step process across multiple distros and deployments.
> Say you wanted to rename `fish` to `a-decent-shell`
You just made my argument. Renaming is hard precisely because you shipped with the wrong name. That's why you should get it right from the start.
Every cost you listed [distro packages, configs, scripts, docs, domain] exists whether you rename to something descriptive OR another random word. The migration pain is identical. "Fish" → "decent-shell" costs the same as "fish" → "zephyr." My argument was that this renaming won't be necessary if you started by picking up the proper name at the first place, and it's very unlikely to have the need to rename it. We shouldn't be optimizing to avoid renaming. That's trading a rare maintenance event for permanent cognitive overhead.
> Renaming is hard precisely because you shipped with the wrong name. That's why you should get it right from the start.
No, it's just because the goddamn string Id appears in way too many places and you can't sed-replace the entire world at once. It doesn't matter if the string was cute, fancy, or you found it to be a good name.
A good reason to use arbitrary code names before assigning a more helpful name upon release of something deemed to now be generally usable, beyond developers with caveats.
I like this approach. Use a cute, fun, memorable name internally for stuff getting off the ground. Once it becomes user facing, the internal name becomes a fun note on Wikipedia and the world sees the actual calculated name.
> If you need a sequential ID, just use an integer
Are monotonic/sequential ULIDs as easily enumerated as integers? It's the ease of enumerability that keeps a lot of folks away from using sequential integers as IDs
Sorry, I'm not familiar with the ULID spec. You seem to be, hence my asking. Are you saying monotonic/sequential ULIDs are just (or just as easily enumerated as) Base32-encoded integers?
Oh and yeah, I guess I do think lots of script / AI kiddies would be discouraged by, or fail to see an opportunity when presented with, something that does not look like the numbers they saw in school.
That is a good point. Injection rates were higher with older population. I would say that younger immune systems are more robust, potentially leading to exaggerated inflammatory responses to spike protein, which could heighten neuro-inflammation and cognitive impacts.
^ That's your problem right there.
Assuming a hyperbolic model would definitely result in some exuberant predictions but that's no reason to think it's correct.
The blog post contains no justification for that model (besides well it's a "function that hits infinity"). I can model the growth of my bank account the same way but that doesn't make it so. Unfortunately.
reply