In that case, the GCC extension is part of the input language (in a broader sense).
Still, your example clearly shows the difficulties involved in practice.
If you know the compiler (and every other tools involved in the process), then yes, there exist at least one solution (the original input). The search will eventually find it.
My point is not about checking if the given program will halt or not.
The parent comment's suggestion was: (1) for each possible input program, (1.a) compile it, and (1.b) check if the result equals the given compiled code.
Agreed, steps (1.a) and (1.b) terminate deterministically (for a given compiler).
However, the search space for this search procedure is infinite.
Similarly, it would be impossible, in general, to exhaustively test every possible input of a compiler.
I appreciate your reply. I am not sure if I really am on the Scholars side of the spectrum myself, but I surely love to know how to use my tools appropriately (Googling instead of memorizing everything is efficient). There was an article recently on HN (http://news.ycombinator.com/item?id=1906070) related to "bad" habits in Perl (What about using the safer, clearer three-parameter form of open?) : as you and other expressed it more clearly than I did, this is the Cargo Cult side of programming that bothers me. Also, I was disappointed that most of the comments seemed to fight over stylistic considerations whereas the point of the author was "Just please stop making authoritative claims", e.g. uninformed claims; but don't get me wrong, I clearly noticed that people here actually know quite well their subject, even when they choose the always-use-semi-colon side of this war.
I agree, but I would like to quote the author : "This isn’t an article where I try to convince you to write your code like I write mine."
He does not really try to force his style.
I respect his approach, because even if the article seems to be about aesthetic preferences, I think that he is concerned by the lack of curiosity and education that may be shown by some programmers. I think what the author really says is : RTFM. None of the comments here focus on the conclusion of the article, which is the most important part:
"Cozy up with some hot chocolate and the ECMAScript spec some Saturday afternoon. Practice a little. Play around with some test programs. It’s a good time.
Or don’t do that, if you don’t feel like it. It’s your life. You almost certainly have better things to do with it.
Just please stop making authoritative claims like “terminate all lines with semicolons to be safe.” It’s not any safer, or more reliable."
Annoying? Poor usability? It looks like a button, reacts on mouseovers, and would totally fit in some game's website. Besides, it is not the point here.
If you write one statement per line, the code is very clear, and there is no need for semicolons. It is after all possible, according to the syntax, and a minifier should be able to understand it, as well as your browser.
I am certainly not against coding practices or readability. With (Q)BASIC, you could also add semicolons and have multiple statements per line, but who did ? It seems that it is the same with Javascript, semicolons are separators between statements, as well as newlines : why write both ? just to be sure they are well separated ?
The original argument is not about the minifier, but about semicolons.
By the way, why would your better minifier introduce a semicolon here ? This is obviously a useless character in this example.
Also, I don't understand how adding a semicolon could help against the "stupid error" you cite. Could anyone please explain ?
That theory is so simplistic. It is based on a very selfish and static vision of a relationship : "the other must think like me", "people never change". Arguing, debating, ... with people about your respective points of view do not prevent you to like/love them.
If you always hang out with the same boring people who always are on your side, how will you learn new interesting things outside of your usual points of interest ?
".. while this approach [randomness] has actually been proven to be a disappointment .. "
I did not see any reference linking randomness and divorce rates, even as being merely correlated. Where is the "proof" ?
I would not rely on that theory in practice, because it abstracts too much of the existing complexity between people, and do not solve the real problems in relationships.
As a filtering algorithm for dating sites, it may give many false positives (you do not like that person, who still shares many of your interests), and may prevent you to meet a "perfect" girlfriend, only because she is/seems/looks radically different than you.