This author will really love [LitRPG] then.
Stop defacing quotes with brackets
201–206 of 206 posts
Re: Stop defacing quotes with brackets
#202Earlier quoted context omitted.
> I find there is more chance for confusion, especially by a non-native reader, when a pronoun (or any proform) appears before its antecedent. It depends on the native language. Spanish is flexible to a fault, so "a huge orange cat", "an orange huge cat", and even "a cat orange huge" are easy to understand... but correctly translating "un enorme gato naranja" to English is the hard part.
You're talking about ordering among adjectives, which is unrelated to pronouns. > The Elements of Eloquence: How to Turn the Perfect English Phrase by Mark Forsyth. "Adjectives absolutely have to be in this order: opinion-size-age-shape-colour-origin-material-purpose Noun. So you can have a lovely little old rectangular green French silver whittling knife. But if you mess with that order in the slightest you’ll sound…
You're right, my confusion even makes your point stronger.
Re: Stop defacing quotes with brackets
#203Earlier quoted context omitted.
> If you're just going to use it once, or if all usages have `[it=foobar]`, I don't think you'd do it. If you never pulled out code into its own separate function just in order to name some lines of code, you should give it a try. You can avoid a lot of comments and/or confusion by just structuring your code in a way that allows you to name lines of code as concepts and abstractions. No need for it to happen more tha…
I agree with using descriptive identifier names and using function names to express intent of lines of code. But I don't understand your point in bringing it up here. > "It is not worth doing," she said, [it=foobar] baz(it) = "$it is not worth doing" baz("foobar") `it` is neither a descriptive identifier, nor did I see a suggestion for what the function `baz` could be called to make it descriptive.
It wasn't referring to the specific identifier "it" here, but more in general as I took your point to mainly be about "if there's a benefit to using other values for X in other contexts", meaning that putting things into variables only serves the functionality of reuse in different contexts, not also to name passages of code.
Re: Stop defacing quotes with brackets
#204I'm not being insecure for correcting someone's language. Language is important and so is its correct usage.
Dare I say the one who doesn't want to be educated is the insecure one, because he can't stand being reminded of requiring education.
Re: Stop defacing quotes with brackets
#205Earlier quoted context omitted.
In the US, you would use an article before "hospital": either "a" or "the".
To elaborate, it appears that American English treats "hospital" as a place. So you go to the hospital, just like you go to the airport, or the subway station. On the other hand, Commonwealth English treats "hospital" as something more like a state. You go to hospital just like you go to work.
I'm probably wrong, but if I as to describe the rule in American English it would be "to the [place]" and "to [activity]". "Work" is an activity, just like practice, rehearsal, school, class, etc. but "hospital" is not.
Re: Stop defacing quotes with brackets
#206Earlier quoted context omitted.
Compression removes redundancy. It's literally the definition of compression! And reduced redundancy is always bad when reliable transmission is a priority over small size.
If your news wire starts mangling data, you need to resend it, not guess. And I bet you can get more reliability out of compressing and then adding error correction bits.
Bit of a late reply, but resending it is a form of redundancy, and so is adding error correction bits. It is cheaper to do these things (they require less bandwidth) when you start with a limited character set.