for more info see: https://en.wikipedia.org/wiki/Countable_set
Then how is there a difference between books and programs?
Now consider the following program or function:
f_epsilon(x) (return x + epsilon;) where epsilon is a number from a set S.
Then if the set S is considered countable for pragmatic reasons like representing epsilon in the form of bits etc then everyone agrees it is countable in practice.
I.e. aren't there uncountably many functions f(x) above if we allow epsilon to be drawn from an uncountable set?
Let me present a challenge to you: Pick a uniformly random number between 1 and 2. Now tell me what it is.
No 'coincidences', like getting exactly 1.34 or the square root of three. It has to be properly random.
The odds are 100% that you picked a 'normal' number that goes on forever with no pattern. A number that cannot be specified in finite space. In other words, a number that can't be computed.
We can also consider a similar function f_epsilon(x) that returns the sum of x and a uniformly random number between 1 and 2 chosen at compile time, but constant at run time.
I agree it can't be specified in finite space.
The dichotomy is the computational model, from a utilitarian perspective we consider every conceptual computer to be a huge but finite finite-state-machine. One could abstractly (and less down-to-earth usefully) define/conceive of a computer that can store arbitrary variables representing uncountable objects (like real numbers etc)
If it's countable, then your computer can now reflect the previously-computable numbers across these epsilons, and give you new numbers, but you're still only covering 0% of the reals.
If it's uncountable, covering a range, then you just moved the problem back a step. On top of that, such a computer doesn't even have to do real work. You can spend 20 seconds using grade school arithmetic to map the input range to the entire set of reals, 1:1. But mapping a range of reals into a bigger range of reals is a pretty lousy definition of "computable".
However, f(x) = x + epsilon is not a computable function when epsilon is not a computable number. So not all of the f_epsilon family of functions is computable.
It turns out no algorithm can solve the halting problem for all C programs. The explanation is that, if you had such an algorithm, you could write a C program that applies the algorithm to itself (this is a special quine), and then does the opposite of whatever the halting algorithm says the program would do (if it says the program halts, the program will just enter an infinite loop; if it says it does not halt, the program calls exit).
Now, imagine a list of all valid C programs in alphabetical order, beginning with the empty string (which, oddly enough, is a valid C program). Consider a number where the Nth digit after the decimal point is 0 if the Nth C program halts, and 1 if it does not; for example, the first digit, corresponding to the empty string, is 0, while a few digits later, the digit corresponding to "int main() {main(); return 0;}" will be 1.
Putting it all together, we know there are C programs for which we cannot compute the solution to the halting problem, and we have a number whose digits are determined by the solution to the halting problem for every C program. So that number is not computable (because we cannot compute every digit, so we cannot compute it to arbitrary precision).
This number is not computable; if it were, you could solve the halting problem.