This means the opposite of what she means, which is
> No, “real programmers” write code in Assembly.
because of the missing comma.
Insisting on good spelling and grammar is not about being annoying, it's about not accidentally writing the opposite of what you want to convey :(
True, but in this case, you were able to infer the intended meaning from context, which is what reading is: interpreting text, which involves assigning meanings to symbols and resolving ambiguities to render the whole as intelligible as possible. Since nothing can be drawn out of the text per se, this means you are the one bringing all the meaning to the text. Whatever the author is conveying is, in one way or another, latent in the context that's already in your mind. Even fiction is composed of elements already in your mind.
(Which is why a lack of experience can be an obstacle to effective reading.)
Yes, but each ambiguity in a given piece of text makes it harder to infer the intended meaning, in a way that's not linear with the number of ambiguities (or at least doesn't feel so). A missed comma here, an extra comma there, couple typos, and suddenly the text switches from understandable, if slightly tiresome to read, to entirely unintelligible sequence of glyphs that requires approaching it as a puzzle to have a chance at understanding what it says. The threshold for this switch is different for everyone, so it's in everyone's interest to keep your grammar and spelling correct.
They mean the same thing.
> No “real programmers” write code in Assembly.
Scare quotes for sarcasm/inflection.
Would be better and more idiomatic as a singular noun.
> No, “real programmers” write code in Assembly.
The pause here just marks an interjection/response to something else. But it means the same thing (scare quotes and all).
What? No, they don't. The first one means "There are no real programmers who write code in assembly", in other words "Real programmers don't write code in assembly", while the second one means "Real programmers write code in assembly". It is very literally the exact opposite.
https://www.urbandictionary.com/define.php?term=real%20men
This is clear if we ask, 'what's the opposite of a real programmer?' - perhaps an imaginary programmer?
No, that's not the misinterpretation that gp (ggambetta) was trying explain with the missing commas causing parsing confusion.
The "real programmers" isn't the main confusion. It's the missing commas.
The author was trying to convey (with some sarcasm) how some programmers have a sense of superiority when they can program in the lower abstraction layer underneath the higher-level programming language others are using. E.g. You code in Javascript?!? Meh, real programmers code in C. You code in C?!? Real programmers code in assembly. etc.
It's only after some readers get to the 4th sentence ("butterflies") that the common joke is revealed and they backtrack to the previous sentences to realize they're missing commas that would have made the joke easier-to-read : It’s really an age old dilemma in computers: “real programmers” write code in C. No [,] “real programmers” write code in Assembly. No [,] “real programmers” write code in binary. No, wait, “real programmers” use butterflies.
Analogous to this XKCD joke about "purity" : https://xkcd.com/435/
The distraction of readers trying to parse the missing commas -- detracted from the author's intended rhetorical effect.
Would I break someone’s program? I have no reason to care about their program based on this title.
[1] Of course there’s the “no ediotoralizing” rule. Even though it’s submitted by the original author.
This is in the power of the submitter since the submitter is the author of this piece.
I’ll get right on that.
At a glance, I like that this looks more approachable to write, and I like that. Can it still be used to prove properties like liveliness? The fact that Fault seems to use bounded loops seems counter-intuitive to proving those "x eventually happens" conditions. As I understand (from a distance) you can model those in TLA+.
PS. The question regards the design of Fault, not the current state of implementation.
Short answer is no (seemingly). From the docs it seems Fault only supports assertions. Finding an assertion violation is a reachability problem and is immediately usable to prove safety problems, not liveness.
But, long answer is "kind of"!
That a counterexample to a liveness property ("x eventually happens") generally is a lasso-shaped execution (so a prefix + a cycle) where x never happens. With that in mind, you can reduce liveness checking to reachability: the only problem is, you have to add state-tracking to your model and assert "the system never closes a cycle when x never happens".
This is explained in detail, e.g., in Armin Biere, Cyrille Artho, and Viktor Schuppan. 2002. Liveness Checking as Safety Checking. Electron. Notes Theor. Comput. Sci. 66, 2 (2002), 160–177. DOI:https://doi.org/10.1016/S1571-0661(04)80410-9
I appreciate the nitpick, I'm new to this :).
Also had a quick look at the codebase and was positively surpised by it being Golang. Oh and just in case the author has a peek at this thread; the only source file I opened had this interesting typo :D "NewProcesser() *Processor"
[0]: https://bellmar.medium.com/marianne-writes-a-programming-lan...
I get it, but it’s not how I decipher and construct models.
