Hacker News Reader

Comment by bruce511 | Hacker News Reader

The title needs a date (1996).

I lived in the 90s, and helped folks then, so I identify with all he wrote. But today it feels like the answers are really archaic...

In some ways we've simply solved the root issues - don't know the question to ask? (Solved). Don't know where the keys on the keyboard are (solved) and so on...

I guess its a bit like learning to drive a car in say 1910 versus 2010. In 1910 they would need to explain the gas pedal and steering wheel. In 2010 you need to teach defensive driving techniques and how to deal with road-rage.

Today it's less how to use a computer, and more how to filter other people who use it to absorb your attention.

View on HN

I'm currently teaching python to a group of people and I can tell you the answers are not that archaic. Even people that use computers in a daily basis have a hard time learning to program. For example, this week one student asked me "why is print("hello world") and not print["hello world"]" and is not easy to explain that to someone with just a few hours of coding experience.

I think the real answer is "Because the parentheses are mathematics notation for function application".

(Grabs Cajori's History of Mathematical Notations.)

Apparently the use of parentheses to indicate function application "occurs in Euler in 1734" and in D'Alembert in 1754. The commas to separate multiple arguments appear in Euler in 1753. The standardization of this notation might have been "[d]uring the early part of the nineteenth century [when] functional notations found their way into elementary textbooks" such as Legendre's Elements of Geometry in 1845.

But there's still another tricky thread about how computer programs came to be organized into "functions" even when some of them (like print()!) aren't actually functions in the mathematical sense.

I'm not clear on how subroutines or subprograms became known uniformly as "functions". (I understand the analogy to mathematical functions, but early computer programming didn't consistently use that analogy, and many programming languages referred to subroutines or procedures rather than, for example, void functions.)

> I'm not clear on how subroutines or subprograms became known uniformly as "functions".

The C "void function" concept clearly contradicts what a "function" used to mean. I suspect the trend might have started somewhere around BCPL (before 1967), which was predecessor of B, which was predecessor of C. Its manual said:

> The semantics of a routine definition is exactly as for a function definition except that the body of a routine is a block and therefore its application yields no result.

https://www.bell-labs.com/usr/dmr/www/bcpl.pdf

In these cases the programmer is more interested in the side effect than the actual result -- in fact there may not even be a meaningful one. "print" could return the input string, for example, but what difference does it make if no one is looking at it?

Or the classic "what is the difference between print(foo) and return foo", which pops up on Stack Overflow every now and then.

Reply on news.ycombinator.com