Command line parsers look at what you typed, not what what you typed looks like

re: Command line parsers look at what you typed, not what what you typed looks like

jMarkP — Tue, 07 Jul 2009 17:27:48 GMT

I've noticed that last point in effect in natural language (where, of course, such imprecise syntax is less disastrous). People will add an adjective to the completely wrong part of the sentence, or substitute an analogous adverb for an adjective or vice-versa.

My canonical example is from The Weakest Link (in the UK at least, haven't seen the US version) where the final round is introduced as:

'I'll ask alternating questions'

What's an alternating question? Surely Anne Robinson means to say:

'I'll ask questions alternately'

As it is the asking that is going back and forth.

One gets the impression that the mental process goes along the lines of 'I need the notion of alternating somewhere in that sentence, I'll just throw it in there the first chance I get'.

re: Command line parsers look at what you typed, not what what you typed looks like

laonianren — Tue, 07 Jul 2009 17:40:18 GMT

A CSS block is typically a list of attributes and values where the order doesn't matter. Perhaps "Wwww Wwwww" had incorrectly generalized this to CSS statements. Since each of the elements of the statement (".Name", "SPAN" and "{ color: red; }") is syntactically distinct, it's not completely insane.

re: Command line parsers look at what you typed, not what what you typed looks like

Mark — Tue, 07 Jul 2009 18:15:41 GMT

laonianren: "I'm going to use CSS selectors as my example, because the command line programs used in my original examples are internal Microsoft tools".

re: Command line parsers look at what you typed, not what what you typed looks like

Mark — Tue, 07 Jul 2009 18:22:01 GMT

jMarkP: Nope, you're just insisting on the transitive version of "alternate", instead of the intransitive.

re: Command line parsers look at what you typed, not what what you typed looks like

Boris — Tue, 07 Jul 2009 18:24:30 GMT

@jMarkP,

I see no problem with "alternating questions" (I'm in the US and the phrase is the same here). The questions are alternating between the two players (think alternating current). The singular "alternating question" would make no sense to me, but in plural it's just fine. Would you fin it equally incorrect to say "the questions will alternate"?

re: Command line parsers look at what you typed, not what what you typed looks like

DWalker59 — Tue, 07 Jul 2009 18:41:24 GMT

Alternating questions... kind of like blinking HTML tags...

re: Command line parsers look at what you typed, not what what you typed looks like

DEngh — Tue, 07 Jul 2009 19:59:02 GMT

laonianren: That makes sense once you're in the block. But the original questioner didn't understand even that, so was asking for the magic phrase that would just make things work.

It is insane. The original questioner was doing the equivalent of using a random name to attract someone's attention and didn't understand that. If you want to talk to Fred, you typically don't use Wilbur's name to call out to them.

re: Command line parsers look at what you typed, not what what you typed looks like

Nick Tompson — Tue, 07 Jul 2009 20:17:35 GMT

Nice confusing title there, "not what what you typed"

;)

re: Command line parsers look at what you typed, not what what you typed looks like

Brian — Tue, 07 Jul 2009 20:24:40 GMT

Funny thing about CSS is the 3 versions are all equally valid and mean slightly different things:

SPAN.Name = a SPAN element named Name

SPAN .Name = an element named Name contained inside a SPAN element

.Name SPAN = a SPAN element contained inside an element named Name

This was one of the more difficult things for me to grok when learning CSS.

re: Command line parsers look at what you typed, not what what you typed looks like

Daniel Colascione — Tue, 07 Jul 2009 22:22:40 GMT

Ah, the computer world's "Klaatu. .. Verada. ... Necktie...Nectar...Nickel..." :-)

re: Command line parsers look at what you typed, not what what you typed looks like

Joseph Koss — Tue, 07 Jul 2009 22:24:06 GMT

Could the issue be Babelfish?

A language translator might reverse words that have translatable meaning, or add a space after a period.

re: Command line parsers look at what you typed, not what what you typed looks like

Karellen — Tue, 07 Jul 2009 22:56:21 GMT

@Brian: No, ".Name" does not match elements named "Name". Rather, it matches elements whose "class" attribute, when parsed as a space-separated list of words, contains the item "Name".

(I'm assuming that when you say 'named Name' you mean 'with id "Name"'.)

re: Command line parsers look at what you typed, not what what you typed looks like

James Schend — Tue, 07 Jul 2009 23:25:07 GMT

Raymond, you have to love how people completely focus on the examples even after you telling them specifically it *wasn't* CSS the original emails were about.

Would be nice if people responded to the *point* of the article instead of picking apart the example.

re: Command line parsers look at what you typed, not what what you typed looks like

Kris — Tue, 07 Jul 2009 23:44:59 GMT

@Brian: The second selector should be "SPAN. Name", not "SPAN .Name".

Actually, I don't think this is a valid selector. I wasn't sure and actually needed to double-check in the CSS specification, which says that for an empty string, the selector matches nothing. (At least it seems to say that, though in the relevant portion:http://www.w3.org/TR/CSS21/selector.html#x16 the antecedent of "it" is unclear.)

@James Schend: Even if the article isn't about the examples, they are still interesting and worthy of discussion. If no one replies to the point of the article, perhaps no one has anything to contribute concerning it. Not everyone has things to add regarding the topic of grammar errors people make.

re: Command line parsers look at what you typed, not what what you typed looks like

Wolf Logan — Wed, 08 Jul 2009 00:44:22 GMT

@Kris: "Not everyone has things to add regarding the topic of grammar errors people make."

On the Internet? Are you kidding me?

re: Command line parsers look at what you typed, not what what you typed looks like

David Brooks — Wed, 08 Jul 2009 01:12:41 GMT

Again, I'm missing the main point of the article here, but:

"A command line parser knows what it wants and accepts no substitutes."

True, but one could imagine a command line parser that accepts curly quotes as synonyms for straight quotes, so long as other syntactic ambiguities aren't introduced. I've known other script-driven languages that make that concession. One could insist, or not, that curly-open is matched by curly-closed. Just because the best-known parsers are stuck on ASCII, doesn't mean they have to.

The quoted sentence would still be literally true, though.

[I even called out PowerShell in the linked article as a parser which accepts curly quotes. But that's because the parser specifically says that curly quotes can be used to quote arguments. The parser knows what it wants and accepts no substitutes - you can't use French angle quotes to enclose arguments. -Raymond]

re: Command line parsers look at what you typed, not what what you typed looks like

Brian — Wed, 08 Jul 2009 01:36:46 GMT

@Karellen: you're right that was ambiguous. I never use id in CSS, I just create a unique class if I want something to be "named"

re: Command line parsers look at what you typed, not what what you typed looks like

James Schend — Wed, 08 Jul 2009 01:49:08 GMT

Kris, if I wanted a detailed discussion of CSS I'm sure I could find one on some other blog, and it would actually be on-topic! Here, I'd much rather see people discuss Raymond's point, which isn't happening because the comments are full of CSS nitpicking.

Oh well, I give up, do your CSS nitpicking.

re: Command line parsers look at what you typed, not what what you typed looks like

db48x — Wed, 08 Jul 2009 01:58:01 GMT

I'm not really surprised. Apparently a large percentage of people simply can't learn to program (and let's face it, both the command line and css selectors are pretty much programming).

http://www.cs.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf

re: Command line parsers look at what you typed, not what what you typed looks like

steveg — Wed, 08 Jul 2009 02:38:14 GMT

Much like the CSS person in the post I work with a guy who just doesn't get SQL; you can show/tell him... and he completely stuffs it up. Fortunately he's "merely" stuffing up SELECT statements. The day he discovers DELETE and UPDATE...

re: Command line parsers look at what you typed, not what what you typed looks like

Anonymous Coward — Wed, 08 Jul 2009 02:42:23 GMT

I think the last user may have been confused with cooking a stew. Just throw it all in there, it'll all be the same after you eat it.

Also, Kris is wrong.

re: Command line parsers look at what you typed, not what what you typed looks like

Anonymous Coward — Wed, 08 Jul 2009 03:15:14 GMT

Db48x, I wouldn't put too much trust in the paper if I were you. It may be interesting, but it suffers from a small sample size, poor controls, omission of the one test that would have been most interesting, overinterpretation and general sloppiness.

The results also don't look like what we get here in Anonyland, and also seem more indicative of a subgroup of students that's either stupid or intellectually lazy, rather than lacking in programming aptitude per se.

re: Command line parsers look at what you typed, not what what you typed looks like

Squire — Wed, 08 Jul 2009 03:47:37 GMT

A snippet from a post from more than 10 years ago in comp.lang.javascript. I lost the name of the author, but saved the message:

"When I read such posts, I immediately see the primary problem in better than 90% of cases -- the poster doesn't realize the compiler won't tolerate sloppy syntax. There is nothing in their background to prepare them for an entity that, confronted with 10,000 lines of code, insists on a comma instead of a semicolon in one of those lines, and refuses to accept any of it as a result. This is an experience for which years of television viewing, however intense and dedicated, is not the proper training."

I think it is relevant to the point Raymond is making.

re: Command line parsers look at what you typed, not what what you typed looks like

Jonathan — Wed, 08 Jul 2009 09:53:24 GMT

Well, at least Mr. Xxxxx and Mr. Wwwww had the courtesy to include in their mail actual code samples - what they have now (<SPAN CLASS="Name">) and what they've actually tried (SPAN. Name, etc). I can certainly imagine people saying "I tried that, but it doesn't work." without including the actual attempted code.

Or, Raymond may have added that for clarity purposes, saving the issue of missing samples for another post.

re: Command line parsers look at what you typed, not what what you typed looks like

Drak — Wed, 08 Jul 2009 11:24:19 GMT

@Boris: I think the problem with alternating questions is that the questions themselves are not doing anything (or capable of such). It's Anne who's doing the alternating. In the case of alternating current the current itself is alternating.

More on topic: When someone says they've done what I said and it still doesn't work, I ask them: 'Are you 100% sure you did what I asked? 99.9% is NOT enough.' And, lo and behold, they check again and discover extra spaces or wrong characters etc.

re: Command line parsers look at what you typed, not what what you typed looks like

steven — Wed, 08 Jul 2009 13:36:24 GMT

"And, lo and behold, they check again and discover extra spaces or wrong characters etc."

They will check again and not discover those. People tend to simply not notice this, especially as they don't perceive it as a problem in the first place. They will blatantly tell you they are 100% sure that they did what you told them to.

re: Command line parsers look at what you typed, not what what you typed looks like

Drak — Wed, 08 Jul 2009 16:37:29 GMT

@steven:

Nah, they check, very carefully. They know by now that if they don't I will come down to their floor and point out the error, and they will feel very silly :D

re: Command line parsers look at what you typed, not what what you typed looks like

Mark — Wed, 08 Jul 2009 17:27:23 GMT

Drak: day and night alternate; ice ages and interglacials alternate; questions to player 1 and questions to player 2 alternate.

alternate, v.

2. v.i. Of two (occas. more than two) things: succeed each other by turns. E18.

re: Command line parsers look at what you typed, not what what you typed looks like

mikeb — Thu, 09 Jul 2009 00:52:38 GMT

This reminds me of the very odd syntax of 'sc' commands that take options. for example:

sc query type= service

If you type that command like so:

sc query type=service

which would be fine with pretty much any other command line program, sc.exe chokes. Instead of parsing "type=service" as 3 tokens, it parses it as a single token. The option's keyword is "type=", not "type".

re: Command line parsers look at what you typed, not what what you typed looks like

Drak — Thu, 09 Jul 2009 09:07:47 GMT

@Mark:

I'd agree with you except that the question asked of player 1 the first time will not be the question asked of player 1 the second time. So I feel that in this case the questions are not the things alternating. Otherwise I could possibly say that a petrol station has alternating customers, which I hope you will agree sounds sort of silly.

re: Command line parsers look at what you typed, not what what you typed looks like

Mark — Thu, 09 Jul 2009 12:43:43 GMT

Supposedly, good Star Trek movies and bad Star Trek movies alternate, but they're not the same movie each time. They alternate by popularity; the questions alternate by player.

A petrol station would have alternating customers only if there was one pump, and some clear pattern to the customers.

Is there somewhere other than Raymond's blog we can battle this out? Youtube comments, perhaps?

re: Command line parsers look at what you typed, not what what you typed looks like

dash vs dash vs dash — Sat, 11 Jul 2009 01:30:03 GMT

Which is this different dashes should I use as a parameter prefix when specifying options to a console command?

U+002D

U+00AD

U+2011

U+2012

U+2013

U+2014

U+2010

U+2015

U+2212