I can't remember who suggested it, but I'm sold on the idea that if you're committing your drafts to version control, then you should break your lines at syntactic points: at the end of a short sentence, or at the ends of the component phrases of a longer sentence. This should typically lead to a cleaner and more readily comprehensible version history.
Of course, this assumes that you're writing in Markdown or ASCIIDoc or something else that will get processed into the final displayed form. But even with plain text, you could always run it through fmt or something similar.
Personally, I just change the diff engine to use difftastic, which can handle diff's on a syntactic level. Works great.
You could also just change git's diff settings to highlight word-based changes if you don't want to use external tools. I believe you can even use regex to redefine a word to match sentences.
> I'm sold on the idea that if you're committing your drafts to version control, then you should break your lines at syntactic points: at the end of a short sentence, or at the ends of the component phrases of a longer sentence. This should typically lead to a cleaner and more readily comprehensible version history.
What you're describing is called "track changes" in word processors.
I'd say an alternative to using Git or JJ or whatever is use a version control that exists to serve non-code. That is to say, use Track Changes! :D
Word, Google Docs, Scrivener (this is my favorite), etc. have no problem telling you "hey you changed this draft by inserting a paragraph and changing this other word's verb ending, while also replacing this one with a synonym."
Yeah, if you use Git, which was designed for tracking changes to a far more limited kind of language, you're going to run into incompatibilities. So track changes with a version control created for tracking changes to human language.
If you have to "rethink" your app in order to serve a new purpose, it's a red flag that you're trying to square a circle.
Better to use a tool that was created for your purpose.
Maybe I just haven’t discovered the track changes feature in word processors enough, but I find it lacking: no explicit grouping of changes (the git commit), no clear timeline of changes, no tagging / naming of versions etc.
Not saying that a line-by-line diff is that much better. Neither is great imo.
I mean, whatever works for you. Go for it. It wasn't my intention to be prescriptive.
I don't like word processors. They're heavy and don't cleanly separate style from structure. And they use more or less obscure file formats.
I like text editors -- vim especially -- and plain text (or plain text with a thin layer of lightweight markup, like Markdown). And semantic linewrapping plus git is good enough for my purposes.
It may not be for yours, and that's OK. We are allowed to be different.
The comment you're responding to is obnoxious, but authoring in Google Docs and exporting to HTML+CSS would be viable and is 10x more accessible than the simultaneously over- and underengineered toolchains and work practices that the professional web developer class has turned out, and doesn't produce output substantially worse than the now-widespread practice of sending mangled/minified payloads to UAs, which in the worst cases involves turning content into opaque blobs that you have to squirt through a JS runtime to get anything meaningful on screen.
The state of the art in Web publishing is such a mess that paid practitioners have, seemingly without realizing it, quietly eliminated the main reason why anyone should even have an expert handle the "lowering" from concept to HTML+CSS instead of using a quasi-WYSIWYG tool or some other crummy sitebuilder and working with whatever shoddy markup they give you.
berkshirehathaway.com (<https://berkshirehathaway.com/>) makes the rounds every now and then, and people ooh and aah over it in the comments, but you can tell they never really get it because then they just turn around and dump their next Vercel-hosted monstrosity on the world.
Won't be surprised if he's one of those that think "radiation" is some kind of harmful beams instead of also what the computer screen emits and we detect it to interact with it.
This is true, but you could also say the same about the phrases "English accent" and "Scottish accent" -- a Scouse accent sounds nothing like RP, and a Highland lilt is very different from the accent in the Gorbals.
And the Appalachian accents of Justified sound very different to the Mid-Atlantic accent of Frasier Crane -- yet to me, as an outsider, there is still an indefinable "Americanness" common to them all.
> there is still an indefinable "Americanness" common to them all
I believe it is more of self fulfilling prophecy imo. Some quality you treat as American AFTER you learn it is an american accent rather than something you see as american before (or regardless of whether) you even know if it is american
Markdown editors specifically? I think the general idea is people are paying dozens of dollars a month for all kinds of crap that used to be one-time purchase. And some people, fed up, are pushing back.
Original rules (host knows where car is and always opens a door with a goat):
- 1/3 of the time your original choice is the car, and you should stick
- 2/3 of the time your original choice is a goat, and you should switch
Alternative rules (host doesn't know where car is, and may open either the door with the car or a door with a goat)
- 1/3 of the time your original choice is the car, the host opens a door with a goat, and you should stick
- 1/3 of the time your original choice is a goat, the host opens a door with a goat, and you should switch
- 1/3 of the time your original choice is a goat, the host opens the door with the car, and you're going to lose whether you stick or switch
So even under the new rules, you still only win 1/3 of the time by consistently sticking. You're just no longer guaranteed that you can win in any given game.
Well yes, if you throw out half of the instances where your original choice was wrong, then the chance your original choice was correct will inevitably go up.
> the logic of Monty Hall Doors does not make sense to me
For me, the core is that you have a 1 in 3 chance of getting it right on your first guess, and nothing can change that. So if you always stick with your original guess, you will win one third of the time.
No no. The thing is, the Monty Hall guy is responding to YOUR choice. So if he has to open a door where you fail, it's a response to what he knows of your choice, so HE knows what YOU chose and is not only revealing the remaining losing choice but also the winning choice. Call it a coin flip except for he always has to call tails.
Therefore your choice can either be cadillac or goat, he cannot choose cadillac and has to show a goat, so the remaining option you DIDN'T highlight is that much more likely to be cadillac because it could've been either, but he doesn't get to pick randomly, he had to show which one was NOT the winning one.
Hence the result. And since it started out as one pick of three, he responds to you and then you respond to the added information by switching and that's where the 66% odds come from: two moves each responding to each other.
Your explanation isn't wrong, but it's never quite resonated with me because it feels almost like a magic trick than something that follows intuition. Like seeing a magician perform a trick, it doesn't quite convey to me the "why" as much as the "what", and even though I know there's no actual magic, I still feel like I'm left having to figure out what happened on my own.
The idea that finally made it click for me is that Monty has to choose one of the doors to open, and because he knows which door has which thing behind it, he'll never pick the door with the winning prize. That means the fact that he didn't pick the other door is potentially meaningful; unless I picked the right door on my first try, it's guaranteed to be the one he didn't open, because he never opens the right door on his own. His choice communicates meaningful information to me because it's not random, and that part while seemingly obvious gets left implicit in almost every attempt to explain this that I've seen.
Another intuitive way to explain it would be to imagine that the step of opening one door is removed, and instead you're given the option of either sticking with your original door or swapping to all of the other doors and winning if it's any of them. It's much more obvious that it would be a better strategy to swap, and then if you add back the step where he happens to open all of the other doors that aren't what you picked or the right one, it shouldn't change the odds if you're picking all of the other doors. This clarifies why the 100 door case makes it an even better strategy to switch than the 3 door case; you're picking 99 doors and betting that it's behind one. The way people usually describe that formulation still often doesn't seem to explicitly talk about why the sleight of hand that opening 98 of the doors is a red herring though; people always seem to state it as if it's self-evident, and I feel like that misses the whole point of why this is unintuitive in the first place in favor of explaining in a way that clarifies little and only makes sense if you already understand in the first place.
Of course, this assumes that you're writing in Markdown or ASCIIDoc or something else that will get processed into the final displayed form. But even with plain text, you could always run it through fmt or something similar.
reply