
Procedural programming is like a recipe- you program a sequence of instructions and while there can be if/then, loop and other logic constructs, it still runs like a "choose your own adventure" book. Since you have an imperfect view of the world and how requirements will evolve and you're providing what are essentially sequential instructions, it's brittle and unforgiving to unanticipated requirements.
OO is less about writing instructions and more about creating a representation of the world (or at least the aspects you care about) as objects and having them interact with each other to achieve things. Because you're modeling the entities involved and having them interact rather than imposing a prescriptive set of instructions from above, it's cleaner and more resilient to unanticipated requirements.
Granted it's overkill to use OO for simple tasks when a script will suffice. But if you're building a system that involves interaction of different entities and will need to be adapted & maintained it will almost certainly be more productive to use an OO approach. Btw, I found this book provides the most concise and useful primer on OO I've seen: http://www.amazon.com/Object-Technology-Managers-David-Taylo...
sean
"ENVY/Manager augments this model by providing configuration management and version control facilities. All code is stored in a central database rather than in files associated with a particular image. Developers are continuously connected to this database; therefore changes are immediately visible to all developers."
https://www.google.com/books/edition/Mastering_ENVY_Develope...
~
1992 Product Review: Object Technology’s ENVY Developer
http://archive.esug.org/HistoricalDocuments/TheSmalltalkRepo...
They simply assert "twiddling a run-time variable for debugging in your staging environment can propagate straight into a bug on production".
As-if straight into production without re-testing.
> Source control? What's that?
"ENVY/Manager augments this model by providing configuration management and version control facilities. All code is stored in a central database rather than in files associated with a particular image. Developers are continuously connected to this database; therefore changes are immediately visible to all developers."
https://www.google.com/books/edition/Mastering_ENVY_Develope...
~
1992 Product Review: Object Technology’s ENVY Developer
http://archive.esug.org/HistoricalDocuments/TheSmalltalkRepo...
This reminded me of the book "Business Engineering with Object Technology" by David A Taylor. In one chapter he goes about identifying "objects" in a manufacturing business and goes down to the level of modeling employees and the machines that they'd be using on the production line. I've never found the need to model things that granular, but it's definitely an interesting concept of "reifying" _everything_.
I worked through ~20% of "Learn Python the Hard Way", then later, the intro CS 101 of Udacity which has a Python intro, as I wanted to be able to do more then vlookups and complex workarounds for Excel sheets.
My new career is in marketing automation, so I did some tutorials online, and bought a SQL book to pull PL/SQL queries for data segmentation. I also picked up HTML/CSS, but don't have any reason to really use Jscript. I can read it, and trouble shoot in some landing page uses, but I don't need it.
Learning to code was always a supplemental goal for career growth, and I find it fun. I was that IRC guy who loved scripting simple tasks like a music player/displayer, k/b wars, etc.
However, when I'm actually diving into learning actual code, I don't enjoy it. I don't think I'm built for it, just as I don't grok statistics, yet my sibling is a actuarial scientist, but he gets confused about things that come naturally to me.
Being in Marketing Automation, its more relevant for me to do "continued" (outside of work) education not in coding, but in platform research (Eloqua, HubSpot, Marketo), more SQL/data management (I am reading "Object Technology: a Manager Guide), and certifications in these platforms.