procedure vs object
While talking to clement a few days back, i was surprised to hear him rail against procedural programming. Where what he really meant was:
event driven programming on objects is often more closely related to how the world actually operates.
This is true to a certain extent: the world is full of events that happen somewhat chaotically and are not mediated by a decision tree. Or at least not directly. An event happens: alarm clock goes off. You, the object, react: wake up. Your dresser ignores the alarm.
In effect, you don’t know to pay attention to an event until you learn that it is significant.
Events are happening all the time, but we tune most of them out. Procedural programs, to the extent that they do not operate in an event-driven model, are specialized tools that are good for perhaps one kind of task.
But wait, we’ve gotten off topic: The difference between object oriented programming and procedural programming that clement noted is not actually one of how they work: they all, at some point, run procedures or methods or what have you. The real difference is in how you structure and vocalize the operation of your program.
Which means: procedural programming as defined in the initial conversation is just: what an object does. object oriented programming, as defined by the same conversation is not necessarily concerned with how a task gets done as much as how to describe the entire system.
The argument isn’t about procedural or object oriented programming, but what you learn: architecture and design of applications (oop) or how to think about procedures of programs (procedural).
The argument against the intro to creative programming is that the focus is on low level programming skills and not high level system design. For artists, what is the point of programming? What should they focus on and what can they toss out?
