> 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.)
Amazingly, I knew exactly what she meant. It's also entirely aside from the point of the article, and either interpretation still works toward making her underlying point.
Oh my god, yes. I had to re-read that paragraph three times, and then open the xkcd to confirm what the author really meant. This absolutely killed the flow of the article for me.
The real flaw is that we've overloaded "no" to mean "zero" as well as the opposite of "yes". Without that ambiguity, the sentence would be fine (even if a comma were still technically correct).
Good grammar? "Real programmers" is a colloquialism, and being concerned about good grammar is an indication that the subject is formal or technical writing, in which such constructions should be avoided. "Real programmers" is borrowed from "real men" and that expression is a colloquial synonym for "douche bag", according to this reference:
My only knowledge on modeling languages is: TLA+ exists, I've seen Lamport's introductory videos/course, I've followed along to the course examples.
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.
(Just for the sake of nitpicking: the term is "liveness")
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 quite like this approach to system spec languages. It feels a bit more modern than the rather unwieldy TLA+. Can someone explain how a spec language can exist without sets as a first class datatype though? (admittedly I only had time for a cursory glance at Fault).
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"
Nice that this is now real! I followed along with Marianne Writes a Programming Language [0] which I thoroughly enjoyed, and it's cool to see this come to fruition.
Useless title for HN.[1] A compiler tells me that it’s some language that can be compiled. “Break” tells me that either the compiler is mature and the author is daring someone to fuzz it, or that the compiler is not mature and hence it’s easy to find something that “breaks” while using it (it’s the latter).
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.
A particularly low value contribution. The title is a copy of the article's title and pretty accurately captures its content. This is being difficult for the sake of being difficult.
While I'd never heard of the language or compiler before, so unless you want a title that covers the blog post, I don't know how you want to get rid of your objections.
The article perfectly explains why the author wants you to break the compiler. It's so it can be improved and to do that user feedback (by breaking the compiler) is needed.
[+] [-] ggambetta|3 years ago|reply
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 :(
[+] [-] lo_zamoyski|3 years ago|reply
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.)
[+] [-] Joker_vD|3 years ago|reply
[+] [-] junon|3 years ago|reply
[+] [-] skwheel|3 years ago|reply
[+] [-] oneeyedpigeon|3 years ago|reply
[+] [-] avgcorrection|3 years ago|reply
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).
[+] [-] photochemsyn|3 years ago|reply
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?
[+] [-] laserbeam|3 years ago|reply
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.
[+] [-] lou1306|3 years ago|reply
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
[+] [-] remon|3 years ago|reply
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"
[+] [-] camgunz|3 years ago|reply
[0]: https://bellmar.medium.com/marianne-writes-a-programming-lan...
[+] [-] ChicagoDave|3 years ago|reply
I get it, but it’s not how I decipher and construct models.
[+] [-] avgcorrection|3 years ago|reply
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.
[+] [-] remon|3 years ago|reply
[+] [-] benj111|3 years ago|reply
[+] [-] cinntaile|3 years ago|reply
[+] [-] aprilnya|3 years ago|reply