Split Paths: Basics of Object orientated programming

I have a small analogy to talk about.
A long time ago, I started playing the guitar, and
I never really went to a guitar teacher.
Retroactively, a couple years after I started playing,
I realized that I just couldn't get any better,
and I wasn't really that good.
I decided to go to a guitar teacher, and
that he
told me on the first lesson that
the reason why I can't get better
is because the way I'm holding the pick
is really messing up my
flexibility in the hand.
That was so devastating; to be honest, I don't think I ever
really recuperated from then.  I'll never be
a professional guitar player.
Why am I saying this right now?  We're at
a crosspath between
working in this world of object oriented programming
where it is the direction
of the future of programming
as far as we can see, or working the old way.
Why OOP?
You can work and choose to take
that path, but you could choose to work in the more simple path.
It's really a choice that you need to make.
The reason I made that guitar analogy
is because if you choose the
more simple path,
you could always try and move into the object
oriented world.
There's no reason not to.
But then when you move into the object oriented
world, it will be a bit harder to move into it after having learned the other way.,
If you choose from the beginning to start
leaning in that direction, it's
going to be much easier than later on to integrate
ideas that are object oriented.
With that said,
it's definitely your choice and
one of those things which is kind of like
the good and bad is that if you choose
the easier path right now
it's going to get harder programming as time goes
on,
as you build more sophisticated applications.
If you choose the path of working with
object oriented programming
it's an approach of programming
that obviously has been endorsed by
Flash and by many other languages.
Although it
has a lot of overhead,
a lot more to type, a lot more things to think about,
but by adding these complexities
it kind of takes the world of programming
into a world that's much more familiar to users,
which, what is more familiar to us than objects?
If it's a phone, if it's the noise that's
in the background that I wish wasn't there,
if it's this bottle of water that I have here.
All these are objects that I could relate to
more easily than just lines and lines of code, obviously.
So why am I saying
all that?
If we work in an environment where we're thinking
about objects, we're thinking about grouping things up,
even though setting these groupings and getting
used to these groupings might be a little bit more hard,
if we get used to working with groups
and get used to working with objects and things
that are kind of like tangible in our heads,
as we evolve as programmers, as we add more
code, as we get more sophisticated, it's going to
be so much easier working.