Knuth is simply defining a piecewise function here in ordinary math notation. Functional programming languages borrow heavily from math, Erlang is a functional language. The resemblance would probably be even more striking with Haskell... which only serves to undermine the message.
Erlang's great though. Glad to see some irrational exuberance for it.
I'm waiting for the sequel, Gutenberg used the same characters as in C, making him the first C programmer.
C predates Gutenberg
That's some deep theosophical kung-fu you bring there, grasshopper. But seeing as the words of the Torah existed before the creation of the world, it might just be that you are correct.
"One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." - Robert Firth
Knuth's function would be written in Haskell as thus:
f [n] = [n]
f [m, n] = [m, n, 0, 1]
f [m, n, r, 1] = [m, n, mod m n, 2]
f [m, n, r, 2] = if r == 0 then [n] else [m, n, r, 3]
f [m, n, p, 3] = [n, p, p, 1]
It needs to be implemented with variable-length lists instead of fixed-length tuples, in order to satisfy the type system.
For me what's striking about Erlang syntax is the meaning of the semi-colon and the period, as function clause separator. Most of the rest is just vanilla FP lang syntax.
To be fair that's just vanilla English orthography.
Yup, and still people get confused at Erlang's use of semi-colons and periods.
Do you think it is because other programming languages don't uses the semi-colon that way? Or that periods are usually used to access class members, but not to finish function declarations?
I think it's because most people have no idea how to use semicolons in natural languages too.
I think this is true. Anecdotally, I've looked up the usage of semicolons a few times now, and I think I know how to use them, but every time I'm about to I just rephrase what I'm saying so I don't have to. They are used so rarely in English it's hard to feel confident through exposure.
I use semicolons all the time; they are easy and useful.
The two clauses separated by a semicolon are sentences; thus the semicolon is logically and grammatically equivalent to a full stop. (As long as you normalise the capitalisation). The difference is in nuance, flow, and other soft things.
So when do you use a semicolon instead of a full stop? Whenever you want to!
The really difficult punctuation mark in English is the full colon.
Sure, which is what the rules always say, and is fairly straightforward. The hard part is actually using it because it usually looks so out of place to me. It's a chicken and egg problem, where semicolons are hard to comfortably use because they are so rare they look out of place when I try, and I assume part of the reason for their rarity is other people feel the same way.
What's a full colon? Hard/NSFW to google for that...
Just a plain colon, as an emphatic distinction from a semicolon.
I feel like the semicolon-period thing of Erlang is only really frustrating for the first day you're using it. After that, I actually found it to be a fairly natural syntax, and had little trouble switching between it and JS.
Erlang's usage of commas, semi-colons and periods is based on Prolog's use of these punctuation-marks. (Erlang was developed in Prolog and retains many similarities to it).
Just a small nitpick: your code is not recursive, you are missing 'f' on the right hand side.
Neither is Knuth's definition; it's just mapping an input to an output.
With haskell it will be less similar since Haskell doesn't use the semi-colon to separate function clauses, and the period for delimit the last one. You could argue that Haskell tuples will use the () syntax instead of {} as in Erlang.
I've mostly wrote this joke since many Erlang beginners find the semi-colon/period syntax confusing, but then there you have it on an essential book about programming
I'm pretty sure many more people find TAOCP confusing than they do Erlang :p
Can we say: "If you understand the first 20 pages of TAOCP, you understand Erlang"?
You can understand Erlang even if you're not that good at math, but you won't be able to make much of TAOCP if you aren't good at math.
One thing is for sure: just trying to read TAOCP will eventually make you better at math.
There's no such thing as "being good at math". You either put effort and practice to learn it, or you don't. Fixed va Growth Mindset, etc…
> There's no such thing as "being good at math". You either put effort and practice to learn it, or you don't.
I agree with your second sentence, and, as a mathematician and a teacher, I think that I agree with the spirit of the first, but I think that it's probably not worded as you mean. Think of the same sentence with, say, 'baseball' in place of 'math': I think that most people would agree with the second sentence, but not the first. By the same token, there's no such thing as "being inherently good" (or, for that matter, inherently bad) "at math"; but I think that it would be silly to pretend that the effort and practice don't make you good (or at least better) at it.
The thing about the beginning of Vol 1 of TAOCP is that it begins with the "mathematical preliminaries" which is among the most difficult things in the book (aside from some of the more hard-core analysis). Like, his description of heap-sort in Vol 3. is easy enough to follow, but fuck man, generating functions are hard!
Which is why my professor and classmate and I switched to Concrete Mathematics about halfway through working through chapter 1. More thorough examination of many of the topics in chapter 1, plus more material.
My advisor would always make a joke to his classes, when that book came up, that it had a dual purpose name - - that it was foundational, but also because it's hard as concrete. I used it as reference in some of my math classes but haven't given it a thorough read.
We worked through about 1/3 of the material starting one summer term (where we started on TAOCP) and finishing sometime in the fall. Definitely hard, but it also helped me finally understand a lot of math that I "knew" but hadn't yet grokked.
Any text that defines piecewise functions is going to use syntax similar to Knuth. It's much older than him or his text. Piecewise functions are not common in the normal math track though, because they're not continuous and differentiable, so they make the path to calculus more complex.
In my experience, it is we programmers who care about syntax the most. Math folks seem to be happy if you can get the gist of something.
Still, you're right, the semicolon/period thing is troubling for Erlang beginners, but that part of the syntax really does come from Prolog.
How are piece wise functions NOT covered in normal math tracks? While not strictly necessary for algebra and geometry, I can't imaging being able to grok behavior at asymptotes in calculus and analysis without being somewhat comfortable with them. They were taught in middle/early high school in Maryland school systems, if I recall.
Hence the 'platonic language ideal' that the author speaks about in the last paragraph?
Certainly, though (1) Knuth is mostly irrelevant here and (2) the causality is obfuscated.
A more precise title would be "Erlang uses math-like notation (and kudos)"