>If "a = b + c" takes a second to execute, you have to take that into account.
But it doesn't, so you don't.
Sure understanding performance is necessary to build more complex or higher usage systems, but not understanding it does not preclude "useful programming".
>If "a = b + c" takes a second to execute, you have to take that into account.
But it doesn't, so you don't.
How do you know it doesn't? What if assigning to 'a' writes to a remote database and waits for the write to be confirmed?
More to the point, how does a new programmer know that is not the case? The average person's expectation of computation speed is shaped by the experience of using server-side web apps: you click on a button, a new page is loaded from the server taking multiple seconds to finish.
To understand that an assignment doesn't run that slow, you need to be told that. Surely explaining local memory would be part of that.
To understand that an assignment doesn't run that slow, you need to be told that.
Not really. You just try it, and notice it ran instantly. You don't really have to care how it happens to run behind the scenes, as long as you have a working model of the semantics. That's the entire point of most abstractions, to make it so that you don't have to think about all the details when you don't want/need to.
But it doesn't, so you don't.
Sure understanding performance is necessary to build more complex or higher usage systems, but not understanding it does not preclude "useful programming".