> you cannot pass it a list of records where all contain the x field of int but some also contain an irrelevant y field and others contain an irrelevant z field.
Yes you can - that's just a existential type. I'm not sure what the syntax would be, but it could be somthing like:
List (exists a : {x=int, ...'a})
(In practice (ie if your language doesn't support existential types) you might need to jump through hoops like:
List ((forall a : {x=int, ...'a} -> b) -> b)
or whatever the language-appropriate equivalent is, but in that case your list will have been created with the same hoops, so it's a minor annoyance rather than a serious problem.)
The 'units' command line tool has been part of Unix since Bell Labs, and GNU Units came along in 1997.
Personally I used basic high school geometry knowledge of "what's the area of a sphere", and you could also have just asked WolframAlpha, which also predates LLMs.
Yet a formula that actually calculates the probability of impact is nowhere to be found in your response. You don’t consider mass, density, velocity, orbits, or anything else for that matter.
The formula is an excercise for the reader, even if my audience was a 14 year old learning about this for the first time. As is figuring out why "mass" and "density" are unimportant.
Might be a valuable lesson in "reading the question carefully" for them, though, as the scenario was: "That’s pretty close when your neighbor just exploded", which is why orbital mechanics can be disregarded in this instance.
> This is a sentence that includes the word "Lopadotemachoselachogaleokranioleipsanodrimhypotrimmatosilphiokarabomelitokatakechymenokichlepikossyphophattoperisteralektryonoptekephalliokigklopeleiolagoiosiraiobaphetraganopterygon" in it.
> How should it be wrapped semantically?
This is a psychological case to demonstrate how semantic wrapping does not by itself solve the "hard vs soft" wrapping question. If the answer is that the word should remain as a single word, then you are using soft wraps (or no wraps at all). If the answer is that the word should be split into 80 character chunks, then you're using hard wraps.
I have no idea what the semantics of that word are, which is information that is required in order to properly semantically wrap it. (Inherently, since conveying such semantics is one of the major pointer of semantic wrapping.)
However, you included embedded control characters (C2 AD aka 'SOFT HYPHEN'; below replaced with '-') that encode less semantic information than is necessary for proper semantic wrapping, but not none:
The fact that you included soft hyphens rather concedes the point that hard and soft[0] wrapping is incorrect[1].
0: Or rather, non-semantic, which is what we're actually arguing over. Technically, semantic wrapping is a subset of hard wrapping, but it's a specific subset that isn't what is expressed by just saying "hard wrapping". Kind of like how birds aren't what anyone means when they just say "dinosaurs".
1: Granted, to be fair, a lot of the time we just don't care. But (contra your original comment) we never need to resort to non-semantic wrapping; we just sometimes (often) decide to be lazy because it doesn't matter.
I think this a valid approach to semantic wrapping, but I don't think this is the only one, and specifically I think it has significant flaws: (1) We've lost grepability unless I write rather complex regexes to handle the possible places where hard line breaks may have been added. (2) We've lost diffability in the sense that if I correct a typo in the word, that correction can cascade through the word and cause multiple lines to show up as changed in the diff when semantically only one part of one word has changed.
Instead, I would prefer a soft semantic wrap: if a single semantic unit (be that a word, a clause, or whatever else) extends beyond, say, 80 characters, we keep it on the same line and let the editor/file viewer handle wrapping. This means that we maintain grepability over words and semantically-connected phrases, and we maintain diffability by avoiding the hard-wrap cascade. To me, this is a much more useful version of semantic wrapping, because it only wraps when there is a semantic clause, and not on any arbitrary semantic break.
My goal here isn't to convince you that this version is better than your version of semantic wrapping, only that wrapping based on semantics is an orthogonal concept to hard and soft wrapping, and that even if we choose to take a semantic wrapping approach, we still need to decide what to do with particularly long lines.
(Although I will add to this: I had a colleague who was a deep fan of semantic wrapping, and I just never really got it. I used it for a couple of years, but I've never run into issues with simply soft-wrapping everything. When inserting new clauses or changing text in the middle of a line, every diff tool that I've used has been able to accurately identify which portion of a given paragraph has changed and highlight it. Meanwhile, as a writer and reader, I need to put more effort into reading prose that is written in an odd, stylised format that is very different from the intended paragraph structure. I can see the argument that I've accepted semantic line breaks in code or configuration files, so I should be able to handle it in markdown, but I just find it harder to read and more irritating to write. But assuming someone does want to use semantic line breaks, I still believe that that's an orthogonal choice to deciding between hard and soft wrapping.)
> if a single semantic unit (be that a word, a clause, or whatever else) extends beyond, say, 80 characters, we keep it on the same line and let the editor/file viewer handle wrapping.
...the editor can't do that because it doesn't understand the semantics.
> that wrapping based on semantics is an orthogonal concept to hard and soft wrapping
Yes, that's why I've been saying "hard and/or soft [but in either case nonsemantic] wrapping".
> > > With semantic wrapping you put each sentence (or similar) on a new line [...] But if that sentence runs over e.g. 80 characters, [then...]
... You don't need to fall back on non-semantic wrapping, you can just just keep breaking it up into smaller and smaller semantically-meaningful pieces.
(You have to do that 'hard'-ly because the editor doesn't understand the semantics, but that's not "decid[ing] whether you're going to hard wrap or soft wrap", it's being forced to hard wrap as a implementation detail because that's what results in correct wrapping.)
It might not be worth the effort to do that, but you're never forced not to (given not-pathologically-short line length limits like 20 characters).
Hmm, I think we have different definitions of a semantic line wrap. To me, semantic line breaks means that line breaks are used to separate clauses and sentences, such that at least every sentence is on its own line, and every line break represents a semantic clause or sentence gap.
To you, I get the impression that semantic wraps are about ensuring that every wrap/line break happens at a semantically valid place, where semantically valid could be a semantically valid clause, but also a semantically valid intra-word line break.
In that sense, I can see how your strategy would produce the same effects as hard wrapping, albeit with different choices about where to put the wraps. But I think then, like I said, you end up running into the same difficulties that you do with conventional hard wrapping, at least in pathological cases.
> such that at least every sentence is on its own line
Yes, with the obvious possible exception of trivial/degenerate cases like "i++; j--;" in C or "This is a cat. That is a dog." in English.
> and every line break represents a semantic clause or sentence gap.
Specifically, it represents a maximally coarse semantic gap, drilling as shallowly down into subclauses as possible/practical.
> wrap/line break [can happen at ...] also a semantically valid intra-word line break.
Preferably only if that word would already be alone on its overly-long line. Eg:
# bad, breaks subordinate clause before superordinate
That sounds supercalifragilistic-
expialidocious.
# semantically valid, but ugly (a pathological case)
That sounds
supercalifragilisticexpialidocious.
# vertically larger, but probably fine
# (unless you're feeling incunabulum-y[0])
That sounds
supercalifragilistic-
expialidocious.
> you end up running into the same difficulties that you do with conventional hard wrapping, at least in pathological cases.
I've yet to see any evidence that really pathological cases exist. (As opposed to "I'm lazy and can't be arsed" cases, which I'm fairly explicitly not disputing.)
I want to highlight the fact that the quote from Vitalik’s article is the first sentence of the second paragraph. Credit is prominently given, not buried in any way.
I hope to write code that warrants a description at least twice as scathing as this one. But, you know, on purpose; when I'm intentionally fucking with someone. (I don't know of Martin ever trying to claim that Clean Code was actually a parody or practical joke, though I'll admit I can't rule it out.)
> The key detail here is that the bumps grow exponentially smaller
Pedantically, it's that the bumps grow exponentially narrower.
IIUC, a simpler (but more nitpickable) version would be f'(n+1/y) = [the fraction of n-state Turing machines that halt within y steps] (for positive integers n, and 0 elsewhere); then f is the integral of f'. The value of f(x) can be approximated arbitrarily well by running every floor(x)-state Turing machine for a large finite number of steps[2], but f'(x) is equal to Chaitin's constant[0] for n-state Turing machines over a strictly-positive-length[1] subinterval of [n,n+1).
A much simpler version is f'(x) = {-1 if x<0; +1 if x>0; Chaitin's constant if x=0}. f(x) = abs(x).
Basically, this isn't even a parlor trick. It's a nothing burger, disguised as something by means of a parlor trick.
> Pedantically, it's that the bumps grow exponentially narrower.
Has to be smaller in both directions, right? It has to be vertically smaller to allow f to be computable, but horizontally smaller to keep f' large.
> IIUC, a simpler (but more nitpickable) version would be...
Here I think your f as defined is identically zero, and so you don't get f' by differentiating.
> A much simpler version is f'(x) = {-1 if x<0; +1 if x>0; Chaitin's constant if x=0}. f(x) = abs(x).
Similarly, differentiating abs(x) doesn't get you that function.
But I see where you're coming from, and I agree this doesn't tell us anything profound about computability. That said, it is a cute result that differentiable functions are flexible enough to admit this kind of construction, and that's straightforward but not obviously trivial, as your attempts somewhat ironically show. I think Myhill's proof is pretty close to a minimal working example and trying to fix your examples would result in something that looked very similar.
Myhill uses a parlor trick to make his version continuously differentiable. It's a pretty good parlor trick, but it doesn't have much to do with computability.
Yes you can - that's just a existential type. I'm not sure what the syntax would be, but it could be somthing like:
(In practice (ie if your language doesn't support existential types) you might need to jump through hoops like: or whatever the language-appropriate equivalent is, but in that case your list will have been created with the same hoops, so it's a minor annoyance rather than a serious problem.)