Graham speculates there’s a ranking of the languages in which programmers too comfortable in one of the languages “don’t get” the usefulness of the features in languages above it. So BASIC-addicts might not appreciate what they can do with recursion or structured programming (i.e. by abolishing go-to statements); C-addicts might not appreciate what they can do with functions as first class objects, and Python-addicts might not appreciate what they can do with Lisp macros.
If “enlightening people about better programming languages” ever becomes a higher priority than “enlightening people about superior status of X language users”, I think a good strategy would be to explain those possible insights in a simplest possible form, without asking people to learn the guru’s favorite programming language first.
For example, to show people the benefits of the recursion, I would have to find a nice example where recursion is the best way to solve the given problem; but also the problem should not feel like an artificial problem created merely for the sake of demonstrating usefulness of recursion.
I can use recursion to calculate the factorial of N… but I can use a for-cycle to achieve the same effect (without risking stack overflow). Actually, if my math happens to be limited to 64-bit integers, I could just use a precomputed table of the first few results, because the factorials of greater numbers would overflow anyway. This is why using factorial as an example of usefulness of recursion is not very convincing. A good example would be e.g. recursively parsing and then evaluating a mathematical expression. -- The idea is that even if some concept is powerful, your demonstration of it may be wrong. But providing no demonstration, or very esoteric demonstration, is also wrong.
Alternatively, we could hold annual competitions between proponents of different programming languages. For example they would have to program a Minesweeper game, and would be rated by (a) the speed of finishing the product, and (b) the elegance of their code.
At this point, proponents of the X language may object that coding Minesweeper is not the fair way of comparing languages, because their language is better for some other tasks. But this argument cuts both ways. If my goal is to write a Minesweeper game, then perhaps Paul Graham’s (or anyone else’s) opinion about the best programming language is not relevant to me, here and now. Perhaps call me again when my ambitions change. Or tell me in advance what kinds of projects should I do in the X language, and what kinds of projects will rather easily work in any language.
If “enlightening people about better programming languages” ever becomes a higher priority than “enlightening people about superior status of X language users”, I think a good strategy would be to explain those possible insights in a simplest possible form, without asking people to learn the guru’s favorite programming language first.
For example, to show people the benefits of the recursion, I would have to find a nice example where recursion is the best way to solve the given problem; but also the problem should not feel like an artificial problem created merely for the sake of demonstrating usefulness of recursion.
I can use recursion to calculate the factorial of N… but I can use a for-cycle to achieve the same effect (without risking stack overflow). Actually, if my math happens to be limited to 64-bit integers, I could just use a precomputed table of the first few results, because the factorials of greater numbers would overflow anyway. This is why using factorial as an example of usefulness of recursion is not very convincing. A good example would be e.g. recursively parsing and then evaluating a mathematical expression. -- The idea is that even if some concept is powerful, your demonstration of it may be wrong. But providing no demonstration, or very esoteric demonstration, is also wrong.
Alternatively, we could hold annual competitions between proponents of different programming languages. For example they would have to program a Minesweeper game, and would be rated by (a) the speed of finishing the product, and (b) the elegance of their code.
At this point, proponents of the X language may object that coding Minesweeper is not the fair way of comparing languages, because their language is better for some other tasks. But this argument cuts both ways. If my goal is to write a Minesweeper game, then perhaps Paul Graham’s (or anyone else’s) opinion about the best programming language is not relevant to me, here and now. Perhaps call me again when my ambitions change. Or tell me in advance what kinds of projects should I do in the X language, and what kinds of projects will rather easily work in any language.
This.