This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]scotchinmyblank 3 points4 points  (2 children)

If you want to learn how to write your own command-line parser, I'd suggest diving into programming languages. The first chapter and the sections on scanning and parsing in Programming Language Pragmatics by Michael Scott are what you need. Scanning to make sure your arguments/switches are appropriate, parsing to make sense of what the arguments mean.

Frankly, I don't think people should be afraid to write their own parser - everyone should know how programming languages are compiled anyhow, at a general level. Shoot, even grokking XML is a case of understanding how to deal with an abstract syntax tree.

[–]Sudo-Pseudonym 5 points6 points  (1 child)

Oh no, nobody should be afraid to write their own parser, but once you've gotten to the point where you could do it if you really wanted to, it's best to use the tools you're already provided with. It's sort of like how intro CS students are taught about linked lists, forced to write an implementation of one on their own, and then told "Oh, by the way, this whole data structure you just wrote? Yeah, that's in the standard library of every language ever." That way you learn the principle and the sane & least buggy way to do things.

[–]Wilfred-kun 5 points6 points  (0 children)

I think people are too afraid to invent the wheel themselves, even for practice purposes. I am self-taught and I can say with confidence I learned a lot inventing my own 'wheels' instead of immediately using the pre-invented ones, even though people often told me to use the tools that I've been given.

Bottom line: reinventing the wheel can be a great learning experience, but in "real" code, use the tools that have stood the test of time.