From: "William Chops Westfield"
> I had a revelation recently...
>
> For years (decades, actually) I've been a sort of low-level
> programmer, writing first primarily in assmebler and more
> recently in C.  I've occasionally forayed into more modern
> languages (first smalltalk, more recently Java...)  But I
> just didn't get the point.  OOP looked OK, but I didn't see
> the compelling advantage that would justify everyone being
> so excited about it.


Good subject, finally one topic that I don't feel like a complete newbie.

Well, the excitement phase of OOP was a while back. For commercial 
applications OOP is mainstream, which doesn't mean that everybody knows how 
to do it properly. Something interesting is already happening as of right 
now. There are several "legacy" systems that were innitially conceived using 
OOD and OOP, and people are finding that they are also difficult to 
maintain, and maintenability was one of the holy graals of OOP.

> Then, I finally decided it was time to venture into host-side
> software; something for windows or macs, rather than an embedded
> board somewhere.  I couldn't believe how much crap you had to go
> through just to setup basic constructs like windows with buttons.
>
> Thus, the revelation...  Objects are not so much a basic programming
> construct as a technique for interfacing to shared code (libraries)
> in a way that is much more convenient than traditional methods for
> cases where the data structures involved are large and/or complex.
> And library-style shared data structures as well as their definitions,
> which traditional languages do even worse.  You can define and use
> a standardized "window" in java in a way that would be quite complex
> in C, with little effort...

This is what people found out after the first years of OOP. For the 
extremely purists, OOP is meant to reduce coupling and increase cohesion, 
and that's how the first systems were made. Theoretically if you follow 
those principles your program will be very flexible and easy to mantain in 
the future. That turned out not to be true.
The way libraries are built in modern languages nowadays are based on design 
patterns (see gang of four), which departed from being exclusively academic 
a few years ago to become mainstream. For example, iterators are present in 
almost all of the modern languages (java, C#, smalltalk, ruby, etc).
Now a new paradigm is trying to make mainstream, aspect oriented 
programming. It tries to fill some gaps left by the OOP paradigm. Let's see 
how it develops.

> That objects can also be massaged to look like a vaguely useful
> basic computer construct bodes well for the concept, I guess.

Yes, when you shift your mentality from a procedural stantpoint and think 
about how objects in real life interact, it starts to make sense. Then when 
you start using patterns, you have to step down and break a few "OOP rules".


> Alas, as James is discovering, this means that becoming a
> proficient Java or C++ programmer is more a matter of being familiar
> with the vast array of standard and available pre-defined classes
> and such than knowing the details of the syntax and theory of the
> language itself, or anything as simple as a mere CPU or
> microcontroller.  Being used to embedded and C, one tends to forget
> that that's been important in many languages for all time.
> (Even now, "C programmer" frequently means "Posix programmer")

That's true, but often times you have to design your own library, and how 
you design, instead of how you implement, is very important. In a parallel 
with electronics, you may know all the datasheets and microcontroller 
instructions from the top of your head, but what really counts is how you 
put all of them together.


Cheers

Padu 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist