Hacker News Reader

Paulos in the quoted snippet is arguing against a straw-man version of the past, set up as a foil to prove some unrelated point, rather than taking it on its own terms and trying to understand it. This is a common conceit of modern writers, but it does a disservice to readers.

Roman numerals by and large were not used for calculating, but for recording calculations. Those calculations were done (as the very word “calculate” suggests) using pebbles or other tokens, on some kind of counting board.

The point of Roman numerals is to be as direct as possible a representation of the state of the counting board. They are a serialization format.

Think of it as the JSON (or s-expressions if you like) of the ancient world. You don’t run your algorithm by writing and rewriting JSON literals over and over with pen and paper. They are just a record; your computation is done using a different automatic tool.

When someone writes down the state of a graph structure as a big nested JSON literal, you don’t laugh at them for having a uselessly unwieldy written expression.

Nice quotes. The first one is how I think about programming languages as well. We've moved from binary/punchcards, to assembly, to imperative and declarative layers, to OO/functional code that can be statically analyzed, and systems designs that can be automatically verified. There's all sorts of memory management tools from manual allocation and freeing, to garbage collection and reference counting, and optionals to avoid nulls that can be statically checked. Each thing has solved entire classes of problems and we're getting more and more software solving different kinds of problems, faster.

Whiggish bullshit. Functional code and GC were invented in 1959. Some level of static typing was de rigeur in most application-development languages after assembly and before the scripting boom starting in the late 80s. In Coders At Work Frances Allen bemoaned the effect C's popularity had on automated program analysis since 1970:

> C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine.

"Progress" in CS remains fad-driven pop culture churn.

So Rust, Python, Julia etc are no more productive, safe, or easy to use than programming was in 1959?

The question is not whether any particular language you might pick today is better than any other language you might pick in 1959, but whether there is some kind of teleology or "progress" to which languages are aspiring or at least slouching.

GC (and "memory safety" more generally) was not invented to solve the problems of C after C somehow revealed them solving the problems of e.g. Fortran. C variously sidestepped and ignored the work on program analysis including GC and memory safety for various commercial, aesthetic, and incidental reasons. Similar things are the case for C++ (vs. e.g. Object Pascal / Simula), Objective-C and Swift (vs. Smalltalk and Self), JavaScript and PHP (vs. nearly everything).

Lisp from 1959 stacks up incredibly well against Python today. Fortran still autovectorizes better than most modern languages. Pascal remains better to teach structured programming, we just don't teach that much anymore (and you can tell just by grabbing a half dozen loops at random and trying to figure out how well their conditions capture their invariants). Languages don't get better over time. They do get marketing budgets unimaginable before the 90s ("thanks" largely to Sun and Java for kicking this off), and for the past 20 years or so weird personal identity arguments on top of that (probably somehow Perl's fault).

Rust maybe, python definitely no and Julia I don't know a lot.

How is Python definitely not "safe, productive and easy to use". It has faults, but these three are not them.

This is absolutely the case for programming languages. From Haskell to Rust. Programming languages shape the way we think and reason about the problem. Sometimes it does this so well, it leaves us starring into the abyss. Facing dead on the problem domain—after all sides quests have been removed. Once you can delegate away all the busy work, you can focus on bigger and better abstractions.

Both Haskell and Rust are poor examples because one has to focus more on the notation (i.e. types, declarations, etc).

Python is better.

Types in Haskell are generally used to describe the structure of the data. Defining a type in Haskell is like writing documentation and a test all in one. I can mentally offload certain concerns to the compiler, which will tell me whether or not the shape of the data in my head matches the code I'm writing. I pretty frequently use the compiler to guide my development, especially with a tool ghcid, which gives instantaneous feedback as I'm programming. It's also like a million times easier to refactor, I tweak a type signature and the compiler will basically give me a list of things I need to update. No need to hunt for and test every instance of that kind of input, the compiler just tells me where it is, and what is wrong.

You also don't have to write out type signatures 99.9% of the time after declaring a type, the compiler can infer them. People in the Haskell community tend to write out signatures for functions because it makes it easier to understand, but it's pretty rare to see a type signature in the body of a function.

That's not to say thinking in Haskell is always as natural or more natural than Python, but I'd argue that immutability and laziness more than types can require a lot more mental effort that can feel like fitting square pegs into round holes for certain problems. When it comes to types (at least Haskell vs. Python), I'd say it's much more a matter of personal taste.

That's not relevant unless you can do all of the above instinctively and without involving the higher faculties of the brain.

You had to learn 0,1,2,3, etc. at some point. The thing with notation is that it takes time to learn, but it proves profoundly useful over time. The benefit of notation integrated over your career outweighs the adoption costs.

Arabic numbers are like this (no child immediately ‘groks’ Arabic numbers), and Haskell notation is making the same case. Haskell abbreviates abstract structures so that they become fluid.

If focusing on notation is a problem, then we should all have grown up to use our fingers for counting, not Arabic numerals.

You have to remember the context in order to understand my reply. Here it is once again "It is a profoundly erroneous truism, repeated by all copy-books and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilisation advances by extending the number of important operations which we can perform without thinking about them."

First of all programming without thinking about it (i.e. instinctively) is arguably not even possible. But let's be generous and assume that it is somehow.

Are you seriously trying to argue that it's possible to program in a complex programming language which not only requires types, but almost requires encoding complex relationships in them without involving the "higher faculties of the brain"? This is such an extraordinary claim that it requires evidence to even consider it.

Imagine I'm consuming code written by someone else, without looking deeply into its implementation. Would I now be disadvantaged by careful and explicit typing? How much time is spent consuming code versus writing it, of course, is a bit situational.

In python you have to focus more on the debugging where this run-time type-error came from. Also, Haskell has type inference unlike the other two.

Python merely allows you to program quite close to a state where you focus on the problem and less on the infrastructure and syntax required to solve the problem. At least in exploratory phases and when working with smaller pieces of code.

Other languages almost always require more thinking and design upfront, even when doing exploratory programming.

> and less on the infrastructure and syntax required to solve the problem

I do not think that this is true for python any more than it is true for haskell for example.

I’m not sure. I find this in people that say JavaScript is better than TypeScript. Most people that learn TypeScript or Flow learn to love it even more than JavaScript once they get over the initial hurdles. Why? It’s more self documenting. It actually provides better auto completion. It scales much better for larger Frontend projects. Going without it is almost painful to me now. I now know a bit better a few of the big reasons why a lot of devs hate JavaScript. Because they are used to the great properties, tools, and features that come from having a well typed language. Languages seem to have big hurdles for no reason when it comes to their type systems, but those hurdles pay off.

Which one requires more focus on the notation?

    def square(x):
        return x * x

    square x = x * x

I wonder if arabic numerals really are the best system.

Too much inertia is invested in them now but I wonder if a yet easier representation exists. For example, I know that there was a brief push to use quaternions in physics.

Base 12 is likely better than base 10. Twelve is the number of phalanges on your hand that you can touch with your thumb, so if that counting system had caught on and stuck we'd likely have a better base for divisibility.

if you add tip of the finger you can easily work in base 16.

Incidentally there are 12 inches in a foot.

Don't you mean the other way around

Cool idea.

Adding Roman numerals, at least, isn’t hard. If it was I doubt Roman numerals would have ever lasted. Arabic is still, in my opinion, easier to add—from the perspective of a lifetime spent exclusively doing arithmetic in Arabic numerals—but it’s not much easier until you’ve memorized all 50 unique sums of one-digit numbers. Multiplication, though, that’s the real difference maker.

> Adding Roman numerals, at least, isn’t hard.

I find it insanely difficult - but as you note, a lifetime of arabic numerals, and a lack of skill in appropriate tools (eg. an abacus) will skew that comparison.

> ... but it’s not much easier until you’ve memorized all 50 unique sums of one-digit numbers.

This doesn't feel right.

I don't think I have memorised the sum of all pairs of 1-digit numbers - but contemplating this now, it's impossible for me to be sure. I'm not sure where multiplication kicks in for breaking down larger numbers into quotient and divider for me, let alone 'most people'.

Given the maximum value (sum) of two x 1-digit numbers is 18, a naive assumption is the permutations don't really number 50 (I get 45) - and given that roman numerals didn't have a zero, a fairer comparison would be [1-9][1-9] (36 unique combinations)

Either way, in any counting system there's presumably a similar 'memorisation' gate you have to pass for the fundamental set. With roman numerals there was historically 7 I think - I, V, X, L, C, D, M - and summing those wouldn't be anywhere near as straightforward as summing sets of single-digits, so I don't think the comparison of this requirement is as skewed against arabic numerals as you suggest.

I was going off the rough estimate that 0-9 is 10 digits and 10x10 is 100 but that reduces to 50 thanks to commutativity. I think 45 if you don’t count zeroes—I don’t know where you get 36 from.

I also use the term “memorize” pretty loosely—I remember that memorizing times tables was a thing but not so much for plus—but addition is simple enough that most people can kind of intuit what 7+4 heuristically if they’re sat down and forced to do arithmetic as small children for long enough. (Also I’ve never had the patience for memorization; I just rely on my brain to cache things that I use frequently and it ended up working for times tables. Also other things.)

But I do want to acknowledge that Arabic numerals make multiplication nearly as easy as addition, which is a staggering achievement over Roman numerals.

Though I will say, on the other hand, that the Romans weren’t that stupid and neither were their medieval successors prior to the adoption of Arabic numerals. They could add things up and we’ve discussed in a parallel thread how that algorithm works. The Roman numeral system isn’t as optimized informationally—let’s not underestimate the sheer awesomeness of seamlessly expressing numbers as large as 108730026190037365462849562635965—but that would be useless to most cultures that used Roman numerals.

I would even question one more thing. To someone who doesn’t know a numeral system to begin with, do Arabic numerals actually make addition harder? I mean, very small children (and programming languages like JavaScript if you accidentally express one number as a string) sometimes make the mistake of thinking 11+8=118, but in Roman numerals that’s just like saying XI + VIII = XIVIII, which is also wrong, but not as wrong as 118. A Roman child could easily be taught no, that’s XVIIII since V’s go before I’s, and then maybe reduce to XVIV. A child today is like, “wait wtf are places?” Roman numeral users never have to learn the concepts of places, carry, or borrow, which honestly sounds like a good trade off for a civilization that doesn’t have to do multiplication and division that easily.

I think I'd calculated combinations, but dubiously ignored where both were identical - that's where I ended up with 36.

OTOH do we memorise any of the x+1 combinations? I hope we don't, but perhaps we do. I genuinely can't say at this point. I was trying to work out how I processed sums such as 8+7 earlier, and concluded that so far I can tell, I work out the difference of one of those numbers from 10, subtract it from the other, then it's a very simple addition - ie that becomes 10+5. But I'm now unsure if that's what I do as a general rule, and am even less sure what other people may do.

Times table I vaguely recall learning by rote in formative school, but that's an awfully long time ago, and trying to self-analyse my mechanisms for multiplications is highly challenging. It feels like I try to move those back to multiples of 10 or 100, again, too.

I recall reading aeons ago that the only intuitive interface is the nipple - beyond that, everything is learned. So what makes for an intuitive or sensible mathematical representation of things is probably so arbitrary as to be pointless arguing about. It feels that the kinds of things we do, day to day, with numbers, that base-10 arabic number system is optimum, but that may simply be the lack of exposure to a better system.

As a parent of young children and former math teacher, yes, we do absolutely memorize those sums. It usually happens at an early enough age that the process of doing so evaporates early in life and becomes part of your base mental code. I spent a significant part of my teaching life teaching high school math for college students (and occasionally grade school math for college students) and there are very much people who never managed to get that memorization step completed. What's really fascinating is that it's an orthogonal skill to higher mathematics. I've seen students who needed to use a calculator to do 6+5 and yet managed to be able to solve algebraic problems. This is, I must add, uncommon, but it's less because one skill depends on the other but rather because the failure to gain the basic math skill leads to an unwillingness to try to gain the more abstract math skill.

I agree that Arabic numerals are better, but I did want to make the point that Roman numerals aren’t quite as bad as you might think having already learned Arabic numerals.

Your method for summing 8+7 is what I think I do for things like 7+4 (since I can visualize 7 as “three less than 10” and 4 as “one more than three” all in the same thought to reach 11), but for 7+8 my brain noticeably spits out 15 immediately and only a moment later does it actually do the processing you mention.

This is only tangentially related, but until now I never really thought about how I sum single digit numbers, but it's not by having memorized all combinations. I'd say I have all combinations that sum to 10 or less memorized, which adds up to 25 unique combos (plus the rule that number + 0 = number).

If I can tell it sums to more than 10, I break it up mentally into [larger number] + [smaller number] = [larger number] + ([smaller number] - remainder) + remainder, where [larger number] + ([smaller number] - remainder) = 10

You could break it down further by just memorizing what each digit less than 10 is when you add 1. Then you can do addition like 5 + 4 = 1 + 1 + 1 + ... = 2 + 1 + ... = 8 + 1 = 9. Then you'd only have to memorize 9 things (10 if you include 0). I guess this assumes that you know the order numbers go in though, whereas memorizing all of the combinations doesn't require that.

Honestly I feel like I do the same thing when I think about it, but it’s so well cached that whenever my brain sees 5+7 or 7+5, I simultaneously think “12”, forget the specific order, and imagine 5+5=10 with 2 overflow all at once and I can’t honestly tell you which concept arrives first.

And yeah, you can get by with less memorization and more counting, but eh...either you’re taught not to do that or you do enough arithmetic that your brain just caches the whole table eventually anyway.

Please explain the easy method for adding, for example MCMLXVII and LXV. I mean that seriously, I'm curious what the trick is.

Tokenize, concatenate, sort, reduce.

MCMLXVII + LXV

M CM L X V I I + L X V

M CM L X V I I L X V

M CM L L X X V V I I

V+V=X, L+L=C, C+CM=M so MMXXXII. Convert everything to decimal if you wanna check my work.

Note that converting CM to DCCCC is actually pretty unnecessary since you can just combine CM and C to make M instead of having to count up lots of C’s. A computer algorithm would be simpler by reducing CM to DCCC but adjusting for human fallibility, allowing for CM + C = M makes things a little easier.

Also note that this method scales to any number of sums, not just adding two numbers together.

I think originally Roman numerals didn't have shorthands like IV instead of IIII. In that case, to add Roman numerals, you just write the letters all together, sort them, and combine smaller digits into larger digits as necessary.

MCMLXVII+LXV = MCMLLXXVVII = MMXXXII

Addition in Roman numerals is dead simple: you do it by just bunching symbols together. The only difficulty is subtractive notation, which wasn’t really used in Ancient Rome.

  MCMLXVII + LXV
   = MCCCCCCCCCLXVII + LXV (canonicalize)
   = MCCCCCCCCCLXVIILXV    (concatenate)
   = MCCCCCCCCCLLXXVVII    (sort)
   = MCCCCCCCCCLLXXXII     (combine, VV => X)
   = MCCCCCCCCCCXXXII      (... keep combining, LL => C)
   = MMXXXII               (... C{10} => M, nothing left to combine)
   = MMXXXII               (optionally, look for ways to re-write with the subtraction rule)

I originally thought canonicalize was an important step, but it actually isn’t for humans. For humans, CCCCCCCCC requires a lot more tedious counting than CM or even DCCCC, leading to more errors than simply allowing the human to notice that CM+C=M.

I think the practical way of thinking would be:

- seeing L + L = C and converting CM to M ( basically striking L L and C )

- then V + V = X, ( striking Vs and add an X)

Then write whats left:

MMXXXII

Then try to re-write.

Amazing, the nth level effects a superior notation can have in problem solving. The same consequences of a higher-order programming language.

Thank you for the quotes. I think this essentially answers (or at least provides a hypothesis for) the question I posted about how the numerical system influenced their math.

I'm reading a book called Mathematics from the Birth of Numbers by Jan Gullberg and it covers these systems from various cultures in depth. Great book and easy to read even for the non mathematician. It reads like a cross between a history book and a technical reference. This is literally the first topic in the book.

> Our modern power of easy reckoning with decimal fractions is the almost miraculous result of the gradual discovery of a perfect notation.

Great quote. I wonder if this process will continue with adoption of duodecimal numbers.