In order to use something contained in a module, we use the dot notation
A speculation: Later, when we read about classes, if we want to use an instance's attribute, we write, 'instance_name.attribute',
Or if we want to use a class's method outside of it, we write, 'class_name.method_name(instance_name),'
Or if we want to use an instance's method anywhere, we write, 'instance_name.method_name().'
When you are faced with a problem like this in computer science it is often a good idea to find a solution to a simple problem first and then figure out how to make the solution more general.
This is, in essence, incremental programming, where you proceed to the desired solution in small steps—get something small right, then add something new to it and get that right as well.
minimalists
This can reduce the cognitive load on the reader.
repeating pattern
A key attribute of a computer scientist is to recognize these patterns, for they can aid problem solving.
One of the key uses for comments is to record your mental chunking, and big ideas. They’re not always explicit in the code
Comments make the code intuitive.
Essentially I’m telling you once again, start small, get something small working, and then add to it.
Incremental programming - get a tiny, new piece of code working every time.
A great deal of programming is about having the computer remember things.
It is so good at doing it when compared to us humans. Let us think creatively and strategise while the computers execute our strategies, doing all the remembering and repetitive computations.
Variables also have types; again, we can ask the interpreter what they are.
I'm not confident about this. I think that variables just point to where its values are. Values are the ones that have types.
Python shell
Where we program.
the difference between formal and natural language is
Natural language:
"Please add 1 to 2."
"...I mean, please add 1 apple to a basket of 2 oranges."
Formal language:
1 + 2
The sum of the integers 1 and 2 is computed.
programming is the process of writing and gradually debugging a program until it does what you want.
It's like drawing using a pencil and an eraser: draw something new, erase errors, re-draw the erased parts and repeat.
The idea is that you should start with a program that does something and make small modifications, debugging them as you go, so that you always have a working program.
Incremental programming: get a tiny, new piece of code working every time.
Debugging is also like an experimental science.
Program:
print(1 + 2
Error message: An error occurred after the end of your code. One possible reason is that you have an unclosed parenthesis or string.
Hypothesis: If I add a parenthesis after the integer 2 and run the program, there will be no error messages, and 3 will appear at the output window.
Program:
print(1 + 2)
Output: 3
In some ways, debugging is like detective work. You are confronted with clues, and you have to infer the processes and events that led to the results you see.
The error messages that are thrown at you by the interpreter are your clues!
Specifically, it will do what you told it to do
The interpreter takes what you typed for it 'literally.'
It cannot sense your intentions. If you wished to add the integers 1 and 2, but asked the interpreter to add the strings 1 and 2, by mistake, it will do it for you without letting you know about your error.
Thus, we can describe programming as the process of breaking a large, complex task into smaller and smaller subtasks until the subtasks are simple enough to be performed with sequences of these basic instructions.
Let us say that you meet 10 strangers in a park. You want to know whether or not it is a good idea to invite them to your music concert next week.
To know that, you wish to know about their interests only to see if they could be interested in your music.
How do you do that?
You ask them about their musical interests, one person at a time. Here, you broke down the problem until you thought that 'repeatedly' asking questions around people's musical interests can help you solve your problem.
debugging
You are playing the detective and the criminal at the same time, finding faults in your actions(programming).
interpreters and compilers
A key difference between them is the following:
Let us say that there are 3 lines of code in a program that can be translated into a low-level language by an interpreter and a compiler.
If the first two lines of code print 'Hello, world!' and the third divides 1 by 0, an interpreter will print the first two lines for you and then show you a 'divide by zero' error.
On the hand, a compiler will print nothing for you but show you a 'divide by zero' error. This demonstrates an interpreter's line-by-line translation and execution.
An algorithm is a step by step list of instructions that if followed exactly will solve the problem under consideration.
Think of a programmer as a coach of sports who gives the following instructions, step-by-step, to his students during a training session with the intention of solving the problem of poor stamina:
"Perform this set of exercises in the following order: walk for 10 minutes; jog for 15 minutes; sprint for 1 minute; jog for 10 minutes; walk for 10 minutes; relax."
If instead of saying 'walk' the coach said, "take one step at a time," the students could be confused between sprinting and walking, because both involve taking one step at a time.
Notice that by asking students to take one step at a time, a lot more words were added to make the instructions lengthier.
Lastly, the order of instructions matter here: if you started sprinting without warming up(walking and jogging), your cold muscles could tear in an undesirable manner.
We would want a sequence of instructions, algorithm, to be concise, accurately worded and smartly organized.