Good point. I suppose watching the number go up is useful information in itself.
I have been using CC with DeepSeek 4.1 Flash lately, and it's nice to see how the sausage is being made (even if it's partly illusory, as CoT always is.)
What's interesting about the replies to this comment how readily people provide post-hoc justifications for language features that often have no essential rhyme or reason. The same is true for the prepositions which accompany verbs, which tend to vary by language, but for which every language's speaker will gladly offer you "rules" or "explanations" for when they fit. It's great evidence that we can be very good at something with no communicable understanding of what it is we actually know.
> people provide post-hoc justifications for language features that often have no essential rhyme or reason.
Nah. English articles make sense, they're just usually unnecessary, and languages can often do without the information they add (or they reduce ambiguity in other ways.) English articles certainly reduce the context necessary to understand an isolated sentence.
In Spanish, for example, knowing the subject of the conversation or even knowing what's going on in the surroundings of the speaker might be necessary to understand a subjunctive. In English, hearing a definite article will tell you that you've missed something if you don't know what it refers to; hearing an indefinite one will assure you that you haven't. Hearing an article at all will assure you that the noun isn't being verbed (if it's not obvious.) It's impossible to tell what some Spanish sentences mean in isolation, because you don't know who would do, could do, should do, or was doing the thing. Means nothing in normal conversation. Koreans are like "how do you even know how old they were?" Quechua are like "how do you even know how they found out?"
There's a good reason for everything in language, because if we don't need it, it will just get dropped. The obvious purpose of a thing might not be the reason that it is necessary, though. It may plug an ambiguity hole left by other parts of the language. It may be necessary socially/religiously. It may just reduce to a tolerable level the amount of thinking one has to do before beginning to speak.
> It's great evidence that we can be very good at something with no communicable understanding of what it is we actually know.
Definitely true, but this is a bad example. English adjective order is the really good example that people usually cite. We don't even know that we're doing it. Also all of our weird grammatical tones, and our strong word/phrase -initial stress. Shifting that stuff changes meanings completely, everybody understands, nobody notices. Except people coming from tonal languages, trying their best not to sound like robots or broken tape recorders.
The "I don't know" noise, "[note]mmm[higher note]MMM[middle note]mmm," and the other weird sing songy grunts we do that are words. Our crazy vowels. The fact that the word "tests" is a voiced click and two hisses.
And that's not even getting into politeness - and the difference between modulating politeness and indexing politeness. English speakers modulate. Speakers of many Asian languages index. We change forms of address as a way to express how we currently feel about someone, whereas when a Korean person starts dropping honorifics, it almost means they don't even think you're human.
I'd add an example I basically never see discussed about English (in common discussions, it is otherwise very well studied in phonetic linguistics, and mentioned in dictionaries) - weak and strong forms - how sentence stress is indicated by shifting vowels around. For example, the word "the" is pronounced as either ðə or ði, two quite different vowels, depending solely on whether it has topic-level stress ("the question is" vs "this is the question"). Similarly, "a" is either ə or eɪ, again depending on topical stress.
I believe this is quite uncommon in European languages (a system where the same word is pronounced with different sounds based on the topic level stress assigned to it, not on basic prosody/word sequence/etc). Apparently Dutch has a similar system.
To play devil's advocate a bit: running software isn't free. If you're paying for an online service, the hosting cost to the company does scale per-seat. It's easy to say that the company only paid the cost of development once (and even then, more users = more development demand), but you're not a user of a single unit of developed software.
For streaming services, I think the development-hosting needle swings way towards hosting. Streaming video is the vast majority of their costs and efforts, so scaling prices per-user is the only sensible option. The "software" of those services is bad and interchangeable, and not what anyone wants or is paying for in the first place.
Taking Netflix as example - it has been going downhill steadily, they have a habit of canceling good shows after one or two seasons etc. It is no wonder users get annoyed when they have to pay more over time, and get less for their money. Increasing prices is never going to be popular even when it is justified, but users are more likely to tolerate if the price increase comes with better features or at minimum, no drop in features/quality.
Another egregious thing these subscriptions do is all kinds of dark patterns. Making it super easy to subscribe but super hard to cancel, not informing before charging (how hard can it be to send an email "upcoming charge next week"), showing ads in supposedly "ad-free" services etc. All this just add to the frustration which leads users to cancel.
That may be the case but they are getting so aggressive that I am constantly having to reconfirm devices within my own home. Luckily I just run my own server now but we have HBO for free with my cell plan so that’s the ones subscription we still have. I have to do email 2FA probably every 4th or 5th time we open it because it’s on “too many devices.”
To play devil's advocate against your DA argument: the guy you're replying to already knows the costs of 6 seats. He said he built his own software to replace it.
He knows better than you do what he had to replace, because he did exactly that.
I don't see what bearing the point you're trying to make has on the above comment. The question is not "how much it costs", the question is whether or not it's reasonable for a company to institute per-seat pricing. I think it is, if you're using that company's hosted service, since the hosting burden for them does scale per-seat.
A very valid take on spec writing. It sometimes feels like the research on formal verification is like the drunkard searching under the lamppost, in that the target is often a domain which is itself well-suited to a particular kind of computer science being done on it.
However, I think there is a middle ground between the "naturally verifiable" and the difficult cases. Certain domains, like banking apps, can want correctness guarantees about UI behaviour. A closed-off app can be very normative, so in theory specs like "the user did this action and confirmed it" can be made meaningful. But tying specs to UI is a tricky thing, and it's clearly volatile in a way function boundaries are not - apps go through redesigns, styles and elements move, etc. The abstraction of a UI as a state machine isn't hard to imagine, but actually hooking a spec into the program is a problem unto itself, and the common response is to simply ignore these problematic domains and do something easier like a backend spec that doesn't have to deal with the questions that aren't PL-shaped.
> This is the work of the UK govt, not corporate lobbyists.
This is not an exclusive or. Corporate lobbyists from social media have a real incentive for pushing age verification and attestation. They benefit from public outcry and popular movements for age restrictions online, while also presenting age verification as the only solutions to the problems causing that outcry (which is to say, largely moderation problems on their own websites).
Age verification will be a significant loss for social media companies. It's going to push plenty of people away, and it provides no information that they don't already know to a reasonably high degree of certainty.
And I think the problems with social media for children have little to do with moderation. It's more about the typical ails that even 'good' social media would entail: FOMO, image crafting, amplification/streamlining all typical stuff that happens at all schools - bullying, rumor milling, and so on. To say nothing of the general effect of people becoming zombies to their phones rather than actually interacting in person as much.
The media buzz around the ills of social media are certainly tied to moderation, as well as other problems with the governance of those sites: people are really worried about the kind of offensive content that is easily accessible to, and recommended to, children. There is some recognition that the harmful suggestion algorithms are at fault, but the fact that such content is hosted at all is also a moderation problem.
>Age verification will be a significant loss for social media companies. It's going to push plenty of people away, and it provides no information that they don't already know to a reasonably high degree of certainty.
It may push some people away (though with the centralisation of the internet, I think this is easy to overstate), but the social media companies probably aren't that worried. Their bigger threat is actual legislation and punishment. Age-gating prevents the government from coming down on them for bad moderation, since they can just block users from accessing anything that might need to be moderated otherwise.
The possibility that age verification will actually give them more data or let them track you more easily is a nice little plus, but this is more stick than carrot.
'Harmful content' is one small aspect of it. Overwhelming majorities are concerned about addiction, bullying, mental health, academic focus, real life interactions, and so on. None of those are fixed by moderation or by any sort of regulatory constraints that can be reasonably imposed on social media.
My interpretation of the parable is really just that management consultants are paid to tell you what you already know and give you the conclusions you want to hear - hence why their "solution" is non-specific and the retrospective analysis vindicates what upper management already wanted.
It's also a criticism of management-heavy offices who have lost touch with reality, but consultants are a byword for such things, so I guess the title is succinct at the cost of accuracy.
>why would the formal verification be any more correct than the program it is verifying?
It is quite believable that it's easier to describe what a program should result in versus actually programming it to produce that result - especially in the most common settings targeted by verification, which is to say imperative, stateful programs or algortihms with a high degree of non-obvious optimisations. The simplest example is a sorting algorithm, which normally has a trivial spec but a non-trivial state at each step.
Interestingly, some specs are actually programs themselves, as has also been true for many on-paper specs which are actually reference implementations. Research using programs-as-specs is still pretty valuable, since in some domains a simpler program is actually the right and useful way to talk about a messier one.
> It is quite believable that it's easier to describe what a program should result in versus actually programming it to produce that result
This is obvious for the central cases of a program. It becomes less and less true when going toward the edge cases, especially for a wide array of input.
Complex specs becoming programs is IMHO the direct effect of that (defining what we want is just that burdensome, and special cases we haven't though of will still have a coherent definition in the spec), and we fall back to the base "is this spec even correct" issue the parent points out.
The trick is to start with the smallest possible implementation of a spec and proving it correct. You then add a more advanced and faster implementation and prove that the 2nd implementation implements the 1st. Etc. etc.
It's called refinement and it's a great way to prove really complex software correct. You basically have a formally proven correct chain of software from simple to advanced. CompCert is an example of how to do this.
You know, the last time someone brought up formal verification of sorting I said what the trivial spec was, and then someone else pointed out why it's actually completely wrong.
So for pedagogical purposes, can you tell us what you think the trivial spec is?
Trivial one: `forall i, j. 0 <= i < j < |sorted| -> sorted[i] <= sorted[j]`, which can be satisfied by copying a single element from `input` or by `sorted` being empty.
It can be fixed (feedback welcome) by adding: `forall i, j. 0 <= i < |sorted| -> |indexof_id(sorted, input[i])| = 1`, with `indexof_id` using equality by identity, which is crucial in practice.
Note that the amended definition implies quadratic runtime, which is the crucial difference between a specification and an efficient implementation.
and a bounds checking bug unique to your formal spec because you only check inputs up to the length of the output
// first 0 elements of input must occur in output
SORT(1,2,3,4,5,5,6) = empty list
// first 6 elements of input must occur in output
SORT(1,2,3,4,5,5,6) = 1,2,3,4,5,7
My second condition would reject the additional element, as it would not be found in the input. have to be duplicated to However, I was lazy about the `|input| = |output|` constraints. With those constraints it would not be possible to omit elements from the input in the output.
but I do take the view that ( 1, 2, 3, 4, 5, 5, 6 ) is a list of seven values (perhaps the number of dollars in the pockets of seven distinct unique people) and when sorted the output should also have seven items that correspond to the seven input items.
You need a way to differentiate the two 5s, that isn't present. If you had a list like:
L = [(5,foo), (2,bar), (2,baz),...]
And did a:
SORT(L, key=first) # or however it'd be specified
Then the duplicate 2s would be fine, because they're no longer duplicates, only duplicate keys. But it would still fail if (2,baz) showed up twice in the source and destination even though we've asked for SORT, not UNIQSORT.
But that's not in the specification given above. That specification is entirely wrong to specify SORT. It requires no duplicates survive the sorting process.
What is the "same one"? Define item in "I" formally.
Are we talking about Values? Then inigyou is correct.
Memory locations? Then it is trivially true, but that does not prevent me from writing 0 into every memory location.
Value + Memory location? Then it does not work for arrays since we are modifying the memory locations by moving the values between them.
The abstract notion of manipulable things in a indexable order? You need to show how that correlates to reality in a way where you can not put in a hole even larger than this one you are trying to close.
To loop back, this very discussion shows how non-trivial it really is and how much thought actually needs to be put into handling even "trivial" problems. Almost everybody who talks about how we can replace these complex implementations with simpler, understandable specifications has little to no experience with the difficulties of actually creating correct specifications. Anybody who would bring up sorting as "trivial" either has no idea what they are talking about or is so far ahead that they have weird ideas as to what constitutes as "trivial". In both cases, their opinion is highly divorced from practical reality.
That is not to say that it is not worthwhile or even that the specifications are "more complex". It is quite possible the specification is still simpler despite the difficulty, but it is also likely the complex implementation was already totally incomprehensible and a simplified specification is also incomprehensible, it is now just formally incomprehensible.
The specification was extremely clear on this point. 5 is in the input, so 5 must be in the output exactly once. And 5 is in the input, so 5 must be in the output exactly once. It doesn't say anything about "tracking a permutation chain". Any output containing exactly two 5s violates the spec. You need a different spec because this one is clearly not what you intended, which is the point.
You have that /s tag, but this is actually the problem with pastel8739's spec as written.
>> 1. Every item in I is present exactly once in S
This actually does require inigyou's example to be the result of calling SORT when you cannot distinguish repeated items from each other.
SORT([1,1]) => [1,1]
The item 1 (which one? doesn't matter, they both do but we only need one to fail the post-condition to invalidate the result) in the source list has a count of 2 in the destination list, so this is an invalid result by the supplied spec.
pastel8739's spec also doesn't exclude the possibility of inserting new values (so long as they aren't duplicates of items in the source list).
However, that specification is not trivial. Almost nobody correctly articulates property 1 when first encountering the problem if they do not already know the answer or are already aware it is a trick question (and even then most software developers still fail).
Furthermore, that also sidesteps the problem of formally specifying what a permutation is. Unless you have a grab bag of already proven powerful theorems, the author is most likely also going to make a error doing that as well even if we start at a proof abstraction level comparable to normal programming.
Reality is that trivial problems admit trivially wrong specifications exceedingly easily. There is little reason to assume that much more complicated problems that are hard to even articulate will magically support obviously correct specifications that are simpler and more understandable than the code.
Note this doesn't make it useless, just not watertight. Proving that the output of a sort algorithm is a sorted list is genuinely useful and catches a lot of potential bugs. If your sort algorithm is "return []" you'll certainly notice that while writing the proof and fix it. It'll also be caught easily by any unit test.
It wouldn't catch all bugs - merge sort recursing on the same half of the list both times would return one item N times, which is sorted, and is a plausible enough mistake to make.
I think this works, but I could be proven wrong yet again.
You might also want to prove that the comparison implements a strict total order, but that would be part of the comparison's spec, not the sorting function's. There is another possibility for a mistake there: if you don't use exactly the same test, you might prove that your < implements a strict total order by its definition, while also proving it doesn't according to the sort function spec and thus allowing the sort to return anything.
Huh? Sorting does not have a trivial specification. In fact, it is usually used as the first example of how easy it is to make specification errors because it seems trivial, but is actually not.
The trivial sorting spec is actually very useful, it's just not complete. While knowing that your sorting program meets the complete spec proves it works correctly, if you wrote it intending to be a sort algorithm, and you have proven it meets the trivial spec, and you have a few unit tests, that's still very good-but-not-foolproof evidence it's correct.
In some discussion about Arabic rendering on another website[0], it was pointed out that the Basmala is its own codepoint in part because it is (or was?) a legal requirement on Pakistani documents and comes from an Urdu character-set. It's possible that, as a character effectively originating from and used by Urdu speakers, Apple defaults it to Nastaliq regardless of your font settings.
Or, it could be that out of all system fonts on MacOS, only Noto Nastaliq Urdu has a glyph for the bismillah, and thus the system uses it as a fallback...
Is this a knowing joke? Switzerland's largest (very much in both senses) coin is 5Fr, around 6 USD. Not a token amount by any means, though it wouldn't even cover most public transport journeys in cities.
reply