Why Programming Is a Good Medium for Expressing Poorly Understood Ideas (1967)
web.media.mit.edu
web.media.mit.edu
One thing I have found programming helpful for in the thought process, though, is to uncover things that one thinks one has already thought through fully, but where there are gaps of detail one has leapt across without even noticing. Programming tends to reveal those.
Agree. As a hobbyist coder I try where possible to do some conceptual thinking by writing out in English my high-level solution approach, and then start coding, fully expecting to uncover some details I hadn't anticipated in advance. I try to avoid diving right in with a hack. But sometimes I find it useful to start with a quick-and-dirty implementation, especially if I'm learning a new tool or language.
This phrase only applies when the "idea" is CC related.
For all other subjects - and their intersection with CC - programming is secondary.
Whenever I got the time to first sketch the idea I become much more assertive when coding it.
I've been in meetings that lasted for days and which were all ultimately invalidated by actually writing matching code which immediately made all the issues in the lines of thought glaring and obvious.
I did not understood why in the Monty Hall problem [1] do i have 2/3 chance of winning if i do change the door instead of 1/2 that my intuition tells me until i wrote it as two functions.
function change() {return random(3) != random(3);} // 2/3 chance
function not_change() {return random(3) == random(3);} // 1/3 chance
Then i also saw that i do get that 1/2 chance of winning if i choose between changing the door and not at random.
function random_change() {if (random(2) == 1) {return change();} else {return not_change();}} // (1/3)/2 + (2/3)/2 = 1/2 chance
This was so much more convincing than math and theory and even explanations with cards and drawings because i could run it in a loop a 1000 times and see the results be close to the prediction.
Much like you can understand the math of a lever and see levers working, but precalculating that x can lift y with a z long lever, and then building it, reinforces the logic you used in precalculation and binds the abstract to the real.
I am with Arnold on that.
> Arnold was an outspoken critic of the trend towards high levels of abstraction in mathematics during the middle of the last century. He had very strong opinions on how this approach—which was most popularly implemented by the Bourbaki school in France—initially had a negative impact on French mathematical education, and then later on that of other countries as well.
Instead they would think of adjusting the axioms and work out a useful probability theory.
For example, most children check 1+2 experimentally before accepting the theory.
So, clearly, understanding the proof isn't required. It is a great deal more work than many other methods of understanding the problem, so why prescribe it as the best way?
You might be comfortable with it, but not everyone has the time nor inclination to become mathy enough to live life through your lens.
Mathematics: An Experimental Science - https://www.math.upenn.edu/~wilf/website/Mathematics_AnExper... (PDF)
> A computer is used by a pure mathematician in much the same way that a telescope is used by a theoretical astronomer. It shows us "what’s out there."
> From such explorations there can grow understanding, and conjectures, and roads to proofs, and phenomena that would not have been imaginable in the pre-computer era. This role of computation within pure mathematics seems destined only to expand over the near future and to be imbued into our students along with Euclid’s axioms and other staples of mathematical education.
Also:
Turtle Geometry: The Computer as a Medium for Exploring Mathematics - https://mitpress.mit.edu/books/turtle-geometry
That was an amazing read. It certainly made me rethink my position. Thanks!
I majored in math in undergrad, and one of the required courses was about communicating mathematical ideas. One of my bigger projects in that course was to explain the Monty Hall problem so it could be understood by the general public, and I got a good grade by putting together a lesson plan that included this type of simulation.
Now set N to 3, and consider that, by opening a door without the prize, that's exactly what Monty's offering you.
This is materially the same as being given a choice between opening one door randomly, or being able to open every other door. Because the conditions of opening doors prior to the final choice is that the door you initially picked can’t be opened at this phase, and neither can the winning door.
When the host opens the door and why need to be repeated several times and with lots of emphasis before asking the question. These ordinarily minor details are extraordinarily relevant, and the language used should express that.
In the time and place of the problem's first widely-distributed posing (Parade Magazine, 1990) it might reasonably be assumed that many people seeing it there were somewhat familiar with the game show it is loosely based on.
Even without that background, one might reasonably deduce that the second door opening never reveals the prize, as there would be no point, in that case, in asking whether the contestant wants to change her pick.
That is a somewhat meta argument, in that it involves understanding human intent and what makes for a good puzzle, and it means that it is not just a math/logic/probability challenge, but it is nevertheless a good puzzle. There's no law that says a puzzle must explicitly state every fact of the matter.
I was going to make a lengthy logical argument, but I started to wonder if maybe I was reasoning incorrectly as I tried to prune the redundant cases, so instead I took two minutes to write this Python program to enumerate all 27 equally probable possibilities; if you pipe its output to sort | uniq -c you will see that I am correct:
xs = [(you, monty, car) for you in range(3)
for monty in range(3)
for car in range(3)]
print(xs)
for you, monty, car in xs:
if monty == car:
print("Monty revealed the car, too bad")
elif you == car:
print("You win only if you do not switch")
else:
print("You win if you switch")How embarrassing that it took me two minutes to get the wrong answer and two hours to realize it — just long enough that I couldn't delete my confident assertions above :) This probably forms some kind of evidence about the quality of evidence you can get out of computer experiments without careful thinking :)
An example: rotation and balancing of binary trees - does battling the inevitable core dumps during implementation really enhance any understanding of the principle of the algorithm?
I see people using python to teach/learn something like array iteration and do
for i in range(len(my_list)):
print(my_list[i])
Python is a great language for learning about iteration:
for item in my_list:
print(item)
C is good for teaching about array indexing in the loop and exposing how the loop variable is reused:
for ( int i = 0; i < myArraySize; i += 1 ) {
printf("%d\n", myArray[i]);
}
An extreme example of that is MySQL's InnoDB. It was written by 4 math PhDs who focused on rigor and correctness, which is why InnoDB is one of the most outstanding codebases in Open Source. The Internet basically runs on InnoDB.
Having said that, programming experience will make you more logical over time, which can help with analysis.
Can you explain what you mean by this statement?
It can especially if it is your first time learning about AVL, red black trees, etc. The process of implementing, debugging, etc can help you understand the algorithm and its underlying principles. Even more it shows you the practical merits and limitations. There have been times when I thought I understood an algorithm or data structure until I had to code it and then realized I didn't really understand it.
But generally speaking, you don't need programming to understand "big-level" stuff in CS no more than you need a pen and paper to understand mathematics. Church and Turing didn't program and they helped create computer science.
A recent example I went through as an exercise was writing a regular expression engine. I understood the desired behavior and the theory of finite automata (or thought I did) but in programming it I was forced again and again to review the concepts and proofs in a very detailed and rigorous fashion.
One last thing I would add is that I agree that language- or machine- specific details can get in the way of high-level understanding; this may be inevitable to a certain extent but choosing a language that fits the abstraction level of the problem helps a lot.
In that sense, the poorly understood ideas have to be expressed more precisely, when writing a program. The program itself, however, is not necessarily a good medium to express the most interesting ideas, because they can drown in technical details.
If you have a working (tested) program, you might not have a mathematical proof that it works, but you have certain sense that what you're doing is not entirely logically implausible. It is a form of verification (although without complete guarantee of correctness).
(Another way to look at it is that the testing you did determines what kind of sentence you proved to be true. So instead of assigning the type to the program in advance, you deduce it the other way around - we observe how the program works and that gives us its type.)