4 ms·

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 archa

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.

alexmolas 3y ago
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.
- schoen 3y ago
  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.)
  - kubanczyk 3y ago
    > 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 https://www.bell-labs.com/usr/dmr/www/bcpl.pdf
    - rzzzt 3y ago
      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?
- Pinus 3y ago
  Or the classic "what is the difference between print(foo) and return foo", which pops up on Stack Overflow every now and then.
- deleted 3y ago
  [deleted]

alexmolas 3y ago

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.

schoen 3y ago
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.)
- kubanczyk 3y ago
  > 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 https://www.bell-labs.com/usr/dmr/www/bcpl.pdf
  - rzzzt 3y ago
    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?
Pinus 3y ago
Or the classic "what is the difference between print(foo) and return foo", which pops up on Stack Overflow every now and then.
deleted 3y ago
[deleted]