Parsing Roman Numbers - Beautifully(books.google.com)
books.google.com
Parsing Roman Numbers - Beautifully
http://books.google.com/books?id=1AlWbXItiCYC&pg=PA122&lpg=PA122
4 comments
There is a certain universality in the "Forth philosophy" across many developer communities. (one could stretch it to include life too, but it gets a bit tired at that point)
Unix wizards believe in "Worse is Better."
Lisp and Smalltalk hackers like to have a system that is "elephants all the way down."
The Zen of Python says "There should be one-- and preferably only one --obvious way to do it."
Rails popularized "Convention over configuration."
The specific interpretations vary, but implicitly, they all deride the obvious alternative: piling on layers of heavyweight complexity to gain some perceived flexibility and modularity.
Unix wizards believe in "Worse is Better."
Lisp and Smalltalk hackers like to have a system that is "elephants all the way down."
The Zen of Python says "There should be one-- and preferably only one --obvious way to do it."
Rails popularized "Convention over configuration."
The specific interpretations vary, but implicitly, they all deride the obvious alternative: piling on layers of heavyweight complexity to gain some perceived flexibility and modularity.
The problem with parsing Roman numerals is that, unlike the decimal system, there are many permutations of digits that are illegal.
That is, you can't say, let's party like it's MIM, or even MICM, no, you have to say MCMXCIX.
The problem with printing Roman numerals is that MAXINT is 3999, (and MININT is 1). I wonder what sculptors will put on their statues two millennia from now...
That is, you can't say, let's party like it's MIM, or even MICM, no, you have to say MCMXCIX.
The problem with printing Roman numerals is that MAXINT is 3999, (and MININT is 1). I wonder what sculptors will put on their statues two millennia from now...
> The problem with parsing ...
Parsing them is easy.*
Validating them is hard.
* But ICM "could" mean 901 or 899, depending on order of evaluation. For very forgiving values of "could".
Parsing them is easy.*
Validating them is hard.
* But ICM "could" mean 901 or 899, depending on order of evaluation. For very forgiving values of "could".
"In devising an algorithm, consider exceptions last. In writing code, consider exceptions first."
Good advice
Good advice
I've been doing this wrong for as long as I've been programming (eight or nine years.) I always just try to get stuff to compile as quickly as possible, then to run, and then handle the edge cases if they come up. Needless to say, unconsidered exceptions always come back to bite me in the ass...
It's a great programming quote I'd never heard.
Side-track: The Romans used IIII for 4, not IV, etc. which was introduced by early printers (not dot-matrixes ;-) to save space, so the original system was more additive.
Looked at in this light, you can see more easily how humanity progressed from tallying, to counting on fingers -- use fingers to tally up to four, take the thumb to represent five -- to the abacus and Roman numerals.
Looked at in this light, you can see more easily how humanity progressed from tallying, to counting on fingers -- use fingers to tally up to four, take the thumb to represent five -- to the abacus and Roman numerals.
I had exactly the same thought as I started skimming this: uh oh, first decide what convention you are going to use. Or do you do that last?
The most elegant way of dealing with Roman numbers is to avoid them.
Also, the entire book that's from, _Thinking Forth_, is available on the web: http://thinking-forth.sourceforge.net/
It was one of two books that really affected how I program and even though it's about Forth (and I've never really did much Forth programming), it's worth reading.