thingification

I wonder if this is a CS problem somebody solved in 1954. Does somebody have the link to that paper?

(I'm not serious about 1954 in particular, I am about hoping somebody here knows the CS literature better than me)

I think my is-this-LLM alert is triggered not by mere use of phrases / constructions beloved of popular LLMs, but by things like unmotivated magpie-ish use of those phrases.

I didn't get that reading this (I didn't read the whole piece but I had read the parts you quote before reading your comment).

Often the LLM-beloved constructions are good usage in the right contexts.

I read Alien Clay and another book by him, which it turned out is basically the same book, which I found disappointing.

I think I've been waiting since the 90s hoping somebody will figure out how to make this a real thing (or was it the early 2000s?)

As I recall it seemed to be just one guy, David Chaum, who did so much to show how so many of these things could work, but the rest of us have somehow managed to do very little with his ideas. What are we missing?

But they'll block it entirely later right, once they've whittled down the objectors?

Seems we lack a nail-on-the-head term for this "but of course you'll still be able to ..." frog-boiling. We collectively fall for it every time!

If you can instead construct a list of existing instances to grandfather in, that doesn't suffer from this problem. Of course many linting tools do this via "ignore" code comments.

That feels less arbitrary than a magic number (because it is!) and I've seen it work.

To be more concrete:

In the source code - e.g. requirements.in (in the case of pip-tools or uv's clone of that: uv pip compile + uv pip sync), one lists the names of the projects one's application depends on, with a few version constraints explained with comments (`someproject <= 5.3 # right now spamalyzer doesn't seem to work with 5.4`).

In the compiled output - i.e. the lock files (pip-tools or uv pip sync/compile use requirements.txt for this) one makes sure every version is pinned to one specific version, to form a set of versions that work together. A tool (like uv pip compile) will generate the lock files from the source code, picking versions that are declared (in PyPI metadata) should work together.

My advice: pip-tools (pip-compile + pip-sync) does this very nicely - even better, uv's clone of pip-tools (uv pip compile + uv pip sync), which runs faster. Goes nicely with:

- pyproject.toml (project config / metadata)

- plain old setuptools (works fine, doesn't change: great)

- requirements.in: the source for pip-tools (that's all pip-tools does: great! uv has a faster clone)

- pyenv to install python versions for you (that's all it does: great! again uv has a faster clone)

- virtualenv to make separate sandboxed sets of installed python libraries (that's all it does: great! again uv has a faster clone)

- maybe a few tiny bash scripts, maybe a Makefile or similar just as a way to list out some canned commands

- actually write down the commands you run in your README

PS: the point of `uv pip sync` over `uv pip install -r requirements.txt` is that the former will uninstall packages that aren't explicitly listed in requirements.txt.

uv also has a poetry-like do-everything 'managed' everything-is-glued-together framework (OK you can see my bias). Personally I don't understand the benefits of that over its nice re-implementations of existing unix-y tools, except I guess for popularizing python lockfiles - but can't we just market the idea "lock your versions"? The idea is the good part!

That might be fine in your context. People's problems are real, though. What they're almost always missing is separating the source code from the compiled output ("lock files"). Pick a tool to help with that, commit both files to your ("one's") project, problem solved.

People end up committing either one or the other, not both, but:

- You need the source code, else your project is hard to update ("why did they pick these versions exactly?" - the answer is the source code).

- You need the compiled pinned versions in the lock file, else if dependencies are complicated or fast-moving or a project goes unmaintained, installing it becomes a huge mindless boring timesink (hello machine learning, all three counts).

Whenever I see people complaining about python dependencies, most of the time it seems just that somebody lacked this concept, or didn't know how to do it with python, or are put off by too many choices? That plus that ML projects are moving quickly and may have heavy "system" dependencies (CUDA).

> I think ['The Secret War' by Brian Johnson is] an earlier version of ['Most Secret War' by R V Jones]

Most Secret War is R V Jones' memoir of his personal involvement in radar, aerial navigation, aerial surveillance etc. in British military intelligence. I read it a long time ago but I don't remember it as a dry read at all - dramatic times after all.

Brian Johnson was involved in writing and producing the BBC documentary and a book. So it's not an earlier version of the same thing. The documentary is on youtube I think - a good watch, but I'd recommend reading Jones' original book.

For the benefit of anybody thinking "with gitlab I'm safe from this": If you're saying (and perhaps you're not) that some other git hosting service

- gives you control over gc-ing their hosted remote?

- does not to your knowledge have a third-party public reflog or an events API or brute-forceable short hashes?

if so, especially the second of those seems a fragile assumption, because this is "just" the way git works (I'm not saying the consequences aren't easy to mentally gloss over). Even if gitlab lacks those things curently (but I think for example it does support short hashes), it's easy to imagine them showing up somehow retroactively.

If you're just agreeing with the grandparent post that github's naming ("private") is misleading or that the fork feature encourages this mistake: agreed.

Curious to know if any git hosting service does support gc-ing under user control.

I found the post you're replying to helpful (and it made me laugh): I've come across the abbreviation POLA many times, with its non-jokey meaning "principle of least authority". I've also come across "principle of least astonishment" (Larry Wall or some other Perl contributor maybe?) but I'd never noticed that was (presumably?) a jokey reference to principle of least authority - I guess because I came across the joke first back was I was barely a programmer and I've never seen it abbreviated.

But maybe it never was a reference to POLA proper - "principle of least privilege" is more widespread I think, outside of the object capability community. And maybe "least astonishment" came first!

You're saying there's a github API that takes as an argument a secret, and creates a git commit containing that secret? I'm very surprised. Can you provide a reference to the API call?

It uses types to get quoting right? Or it quotes everything (regardless if it's already quoted)?

Ironically, the first time I saw the former was in a Python templating library (in the early 2000s -- from distant memory I think it might have been the work of the MemsExchange team?)

You use both terraform and ansible in the same project? I always thought of them as competitors filling more or less the same role, do you find it useful to use them together? Is it that hetzner and digitalocean TF providers do a good job but provide limited functionality, and ansible fills in the gaps for you?

People deploying low-traffic side projects - to VPSes or similar that allows price capping - and who do use a database: what deployment stack do you use these days?

I assume Docker + something is most popular, but what something? Does terraform work sanely for cheap virtual hosting? Ansible? I don't want to manually install any more stuff than the minimum I can get away with!

Not sure if that's intended as irony, but of course, if somebody is taking multiple years off work, you would be less likely hear about it because by definition they're not going to join the company you work for.

I don't think long-term unemployment among people with a disability or other long-term condition is "fantasticaly rare", sadly. This is not the frequency by length of unemployment, but:

https://www.statista.com/statistics/1219257/us-employment-ra...

Behaves as I expected now!

I went here looking for more info about payperrun https://payperrun.com/%3E/welcome and clicked on the "Spotlight" section and saw 4 popups blocked - I never see popups anywhere these days and have to admit that sends me away pretty quickly.

Nice. I expected clicking on the different "filter" buttons would update of the search results right away: I didn't expect I had to repeat the search (though I can see why you'd do that)

I wonder if part of this is a function of time passing / getting older rather than purely cash vs not.

Ironically, I hear the ones that were shut down in Germany were some of the best maintained in the world and had very high "capacity factors" even when compared with other nuclear (fraction of time delivering power to the grid). It seems like the solution to poor maintenance is better maintenance? Some of the causes of recent poor French maintenance are analyzed here: https://player.fm/series/decouple/somethings-rotten-with-fre...

I assume you wouldn't seriously argue that rivers are the limiting factor to deployment of nuclear energy.

Good to see an open mind! I think most critical rationalists would say that epidemiology is a den of weakly explanatory theories.

Even though I agree, I'm not sure that's 100% epidemiology's fault by any means: it's just a very difficult subject, at least without measurement technology, computational power, and probably (machine or human) learning and theory-building that even now we don't have. But, there must be opportunities here for people making better theories.

As kevinwang has pointed out in slightly different terms: the hypothesis that seems wooly to you seems sharply pointed to others (and vice versa) because explanationless hypotheses ("changing the colour of the button will help") are easily variable (as are the colour of the xkcd jelly beans), while hypotheses that are tied strongly to an explanation are not. You can test an explanationless hypothesis, but that doesn't get you very far, at least in understanding.

As usual here I'm channeling David Deutsch's language and ideas on this, I think mostly from The Beginning of Infinity, which he delightfully and memorably explains using a different context here: https://vid.puffyan.us/watch?v=folTvNDL08A (the yt link if you're impatient: https://youtu.be/watch?v=folTvNDL08A - the part I'm talking about starts at about 9:36, but it's a very tight talk and you should start from the beginning).

Incidentally, one of these TED talks of Deutsch - not sure if this or the earlier one - TED-head Chris Anderson said was his all-time favourite.

plagiarist:

> That doesn't test noticing the button, that tests clicking the button. If the color changes it is possible that fewer people notice it but are more likely to click in a way that increases total traffic.

"Critical rationalists" would first of all say: it does test noticing the button, but tests are a shot at refuting the theory, here by showing no effect. But also, and less commonly understood: even if there is no change in your A/B - an apparently successful refutation of the "people will click more because they'll notice the colour" theory - experimental tests are also fallible, just as everything else.

> Some people just seem to have knack on being able to switch between layouts, but I just couldn't.

Did you put in serious deliberate practice time and still find that? If yes, what sort of time?

I suspect those people just did that sort of practice (even if maybe not really attending much to the fact they were doing so - I don't think that's a contradiction!)

I'm not saying that's not a thing, but if you're going to switch keyboard layout I do think that's objectively the least of your problems. Re-learning a huge list of common letter pairs, triples, etc. that appear in words in English / your native language(s) is a bigger task.

To make a hyperbolic comparison: seems a little like saying that learning cyrillic letters is a problem for learning Russian: true, but compared to learning the rest of the Russian language...

Of course if you just stick to a non-QWERTY layout and never use QWERTY, you don't have this problem. My solution to that has mostly been to use an external "mechanical" keyboard that I flash with a colemak layout. But on laptops I often type on that keyboard and use software to switch and that's worked OK for me too. Some programs use the key code instead of the letter, and that messes me up occasionally on laptop keyboards (maybe VS code, from memory?).

Colemak does keep C, X and V in the same places for this reason, but if you're a big hotkey user, that's only a small part of it.

It is useful, but it's worth knowing that most of the learning effort to get up to speed comes only after you've been through all the intermediate stages, just gradually speeding up on the final full-colemak stage. But it's a big help in not quitting early on from frustration I think. There's a few really painful changes like the changes in where R and S go, and making noticeable progress before that is a big motivator.

I just typed "leasning" instead of "learning" 3 times, all these years later, huh. I suppose because I was thinking about it!

I also switched for reasons of keeping my hands happy (as a prevention measure), not for typing speed.

I'm a bit slower than I was in QWERTY (at a guess, maybe if I race I easily get to 80 instead of 90 wpm or something, not sure). If I kept up with deliberate practice I'd end up faster than I was I think, but I don't really do that.

There are games out there that help you learn the skill of switching quickly.

As at least one other person has commented, context acts as a switch even when you can't directly "find" the switch consciously. It isn't only the keyboard. I learned colemak on one keyboard while I continued with QWERTY on another, and it wasn't a big surprise that it was hard to do the reverse for a while. What did really surprise me was that I couldn't type QWERTY in the typing drill software I was using for Colemak, and I couldn't type Colemak in the online typing test where I was used to typing QWERTY! It wasn't a subtle effect, quite a dramatic speed plummet, especially in the former case - and just switching back to my normal text editor was enough to speed up my QWERTY again 30 seconds later!

I guess if you focus practice on finding that switch, for example with those games, that's just another skill you can learn like any other. Some people certainly have got very good at that with practice.

Yes, aren't we under-focusing a bit, right now, on the goals that in the past were achieved by writing code but will in the future be achieved by LLMs themselves (and their replacements)?

For example, maybe we write some code now with the goal of helping a customer service person do their job. But we all know that plenty of people are trying to replace customer service people with LLMs, not use LLMs to write tools to help customer service people.

I see that the LLM still needs to know what's going on with the customer account, and maybe for a long time that takes the form of conventional APIs. But surely something is going to change here?

Speaking from ignorance (I've not studied attention nor transformers): This is my feeling too. I feel like the next step isn't far away: a more explicit model of the world with a mechanism to both query and "feed back on" that model, correcting mistakes.

If it's possible to get so far when that functionality seems in an important sense basically missing, imagine how far it'll go when that does happen.