5 ms·

I think the article stretches too far away the "think like a programmer" motto by including design patterns and TDD in there. You will have trouble learning if

by kh_hk 13y ago

I think the article stretches too far away the "think like a programmer" motto by including design patterns and TDD in there. You will have trouble learning if you do not think like a programmer, as in basic CS 101. Thinking like a programmer is really near to mathematical thinking, just the basic stuff: logic, invariants and program correctness, in paper, and using pseudo-code. After a year one will be ready to throw that stuff through the window, not because it is not useful, but because it is already engraved on your brain and somehow, even if you do not use assertions at the start of your functions or do not write an invariant down for each loop, it will be there and will make your code cleaner and free of copy-pasted code.

marktangotango 13y ago
>>Thinking like a programmer is really near to mathematical thinking Some people say that but I've never understood it myself. To me, programming is nothing like mathematical thinking, especially at an intro level. It's more about giving super precise instructions to a stupid machine that has to be told every little thing. There are lots and lots of successful, competent programmer who don't know much math or logic as academic fields. Edit; maybe a more relevant discussion would be talk about what is meant by 'mathematical thinking'.
- rprospero 13y ago
  I would argue that giving many super precise instructions is exactly an example of mathematical thinking. It's like the old algebra problem of "Prove 23=6". It's blatantly obvious to everyone over the age of two, but the proof is quite long and tedious. 2*3=(1+1)*3 | Definition of 2 2*3=1*3+1*3 | Distributive property 2*3=3+1*3 | Identity of Multiplication 2*3=3+3 | Identity of Multiplication 2*3=3+(2+1) | Definition of 3 2*3=3+(1+2) | Commutativity of Addition 2*3=3+1+2 | Associativity of Addition 2*3=(3+1)+2 | Associativity of Addition 2*3=4+2 | Associativity of Addition 2*3=4+(1+1) | Definition of 2 2*3=4+1+1 | Associativity of Addition 2*3=(4+1)+1 | Associativity of Addition 2*3=5+1 | Definition of 5 2*3=6 | Definition of 6 It's the exact same set of logical skills to take a fixed set of tools and see how those tools can take you from where you are to where you want to be. It's not that programmers need Category Theory and Partial Differential Equations (however fun and useful they can be), but rather that someone who can't prove that 23=6 probably can't code.
GarvielLoken 13y ago
I guess you like math much, am i correct? Programming is in some wayslike math. Programming is in other ways more about organisation, expression and language skills. But the real truth is that people are different. Some people are mechanics in the head, they like to optimize small functions and break systems and loved the assembly c time. Some people see the world as states and attribute facts to static objects, these people love OO, its an entire paradigm that complies to their though process! Some people are rigours about how the world moves, they like Haskell and logic programming and always bring these aspects to their code base. Some people are dynamic and see the world as a continuous flow of time (not pinning attributes to things, seance a thing can change along its time line, thus brining focus on the core of things and ones purpose), they like languages like lisp where transformations of data is the center, not classes with fixed static attributes, that is contrary to their irl thought processes. These are the people who develops non-deterministic programming, because the focus is on time not space. They like macros and other efficient expressive tools because it allows you to express your solution in a better language and automate transformations. tl;dr / Summary People think differently and programming is merely a means to express yourself, ergo your view of programming will be a view of how you like to think and function, and to say that your own definition is the universal truth is arrogant, narrow-minded and wrong. http://wikisocion.org/en/index.php?title=Statics_and_dynamics http://wikisocion.org/en/index.php?title=Statics_and_dynamic...
- kh_hk 13y ago
  Maybe I am wrong, and I am confusing programming with programming for maths. Now again, on the low level, it's really easy to find maths everywhere, while on the high level, one just interacts with development libraries. As a note, maths are not a field I am really strong on, and had a hard time with them at the university. But, even when it was hard, it helped wrap my brain around programming and provided me with elemental tools. Yes, programming might be drawing pixels in a grid, or could be just throwing words at the computer until the output is what you want. I do not consider myself a proficient programmer and yet, I pity the programmers that look confused at a chunk of code in Eclipse and just add whatever a set of libraries provide to get something to work, which often ends up with larger chunks of code that basically do nothing, but are there just because (with an special guest, more chunks of commented code that are waiting for someone to delete them). I experienced this feeling the first time I programmed something for Android. And no, in this case there's no 'some people might have a different view on the issue'. There's people who code that have no clue of what is happening, and that is saddening (and I guess, stressful to them). As an exercise on what I am referring with basic tools let's see the simplest example I can think of: define a function that returns the factorial of a number. We know the answer already, but instead of doing that, let's think first, and generate the code later [∗] What defines a factorial? n! = 1 * 2 * 3 * ... * n-1 * n Any particular case? 0! = 1 Let's pick an strategy for our loop: - At each iteration, we will mantain that f = i! - For all iterations, i ≤ n The program finishes when i = n Ok, now code // Pre: n ≤ 0 // Post: returns n! int factorial(int n): int i = 0 int f = 1 // inv: f = i! and 0 ≤ i ≤ n while(i < n): i = i + 1 f = f * i return f [∗] = And that's for me the main reason this works. This is a silly example, nobody would think of invariants when you are iterating through a set of records from a database to calculate the median age of your employees, but at least it has trained you to think before cracking code. And this is just the first step on the path. It is not "the universal truth of programming", and there are many many different "states of mind" that one will need to learn in order to do something (OpenGL and state machines, SQL and declarative languages, etc). But before learning something (unless you are really talented, I guess), one must learn to learn.

by kh_hk 13y ago

marktangotango 13y ago

>>Thinking like a programmer is really near to mathematical thinking Some people say that but I've never understood it myself. To me, programming is nothing like mathematical thinking, especially at an intro level. It's more about giving super precise instructions to a stupid machine that has to be told every little thing. There are lots and lots of successful, competent programmer who don't know much math or logic as academic fields. Edit; maybe a more relevant discussion would be talk about what is meant by 'mathematical thinking'.

rprospero 13y ago
I would argue that giving many super precise instructions is exactly an example of mathematical thinking. It's like the old algebra problem of "Prove 23=6". It's blatantly obvious to everyone over the age of two, but the proof is quite long and tedious. 2*3=(1+1)*3 | Definition of 2 2*3=1*3+1*3 | Distributive property 2*3=3+1*3 | Identity of Multiplication 2*3=3+3 | Identity of Multiplication 2*3=3+(2+1) | Definition of 3 2*3=3+(1+2) | Commutativity of Addition 2*3=3+1+2 | Associativity of Addition 2*3=(3+1)+2 | Associativity of Addition 2*3=4+2 | Associativity of Addition 2*3=4+(1+1) | Definition of 2 2*3=4+1+1 | Associativity of Addition 2*3=(4+1)+1 | Associativity of Addition 2*3=5+1 | Definition of 5 2*3=6 | Definition of 6 It's the exact same set of logical skills to take a fixed set of tools and see how those tools can take you from where you are to where you want to be. It's not that programmers need Category Theory and Partial Differential Equations (however fun and useful they can be), but rather that someone who can't prove that 23=6 probably can't code.

GarvielLoken 13y ago

I guess you like math much, am i correct? Programming is in some wayslike math. Programming is in other ways more about organisation, expression and language skills. But the real truth is that people are different. Some people are mechanics in the head, they like to optimize small functions and break systems and loved the assembly c time. Some people see the world as states and attribute facts to static objects, these people love OO, its an entire paradigm that complies to their though process! Some people are rigours about how the world moves, they like Haskell and logic programming and always bring these aspects to their code base. Some people are dynamic and see the world as a continuous flow of time (not pinning attributes to things, seance a thing can change along its time line, thus brining focus on the core of things and ones purpose), they like languages like lisp where transformations of data is the center, not classes with fixed static attributes, that is contrary to their irl thought processes. These are the people who develops non-deterministic programming, because the focus is on time not space. They like macros and other efficient expressive tools because it allows you to express your solution in a better language and automate transformations. tl;dr / Summary People think differently and programming is merely a means to express yourself, ergo your view of programming will be a view of how you like to think and function, and to say that your own definition is the universal truth is arrogant, narrow-minded and wrong. http://wikisocion.org/en/index.php?title=Statics_and_dynamics http://wikisocion.org/en/index.php?title=Statics_and_dynamic...

kh_hk 13y ago
Maybe I am wrong, and I am confusing programming with programming for maths. Now again, on the low level, it's really easy to find maths everywhere, while on the high level, one just interacts with development libraries. As a note, maths are not a field I am really strong on, and had a hard time with them at the university. But, even when it was hard, it helped wrap my brain around programming and provided me with elemental tools. Yes, programming might be drawing pixels in a grid, or could be just throwing words at the computer until the output is what you want. I do not consider myself a proficient programmer and yet, I pity the programmers that look confused at a chunk of code in Eclipse and just add whatever a set of libraries provide to get something to work, which often ends up with larger chunks of code that basically do nothing, but are there just because (with an special guest, more chunks of commented code that are waiting for someone to delete them). I experienced this feeling the first time I programmed something for Android. And no, in this case there's no 'some people might have a different view on the issue'. There's people who code that have no clue of what is happening, and that is saddening (and I guess, stressful to them). As an exercise on what I am referring with basic tools let's see the simplest example I can think of: define a function that returns the factorial of a number. We know the answer already, but instead of doing that, let's think first, and generate the code later [∗] What defines a factorial? n! = 1 * 2 * 3 * ... * n-1 * n Any particular case? 0! = 1 Let's pick an strategy for our loop: - At each iteration, we will mantain that f = i! - For all iterations, i ≤ n The program finishes when i = n Ok, now code // Pre: n ≤ 0 // Post: returns n! int factorial(int n): int i = 0 int f = 1 // inv: f = i! and 0 ≤ i ≤ n while(i < n): i = i + 1 f = f * i return f [∗] = And that's for me the main reason this works. This is a silly example, nobody would think of invariants when you are iterating through a set of records from a database to calculate the median age of your employees, but at least it has trained you to think before cracking code. And this is just the first step on the path. It is not "the universal truth of programming", and there are many many different "states of mind" that one will need to learn in order to do something (OpenGL and state machines, SQL and declarative languages, etc). But before learning something (unless you are really talented, I guess), one must learn to learn.