[gameprogrammer] Re: "Mission Efficiency" - Blue Collar coding

Mission Efficient Coding

In all these postings I'm seeing at least three different topics being
discussed. Often with examples from one being used as counter examples
to another. These topics are:

o Good programmers versus Bad programmers.
o Buzz Word compliance and Coding Religions versus Pragmatic Judgment.
o Abstract Data Types, as opposed to Object Oriented Design, as opposed
to Object Oriented coding, as opposed to Object Oriented programming
languages.

I'm going to cover each subject separately.

Good programmers versus Bad programmers.

There have been a number of studies on the differences between
programmers. It is well documented that good programmers produce between
10 and 100 times as much usable code during the same period of time as
"average" programmers produce. It is also well documented that good
programmers are almost as scarce as hens teeth. That means that the
average programmer, better than 90% of programmers, are bad programmers.
That is a sad but simple documented truth.

Give an idiot a chainsaw and he will cut off his foot. If you are
standing next to him he might cut off your foot too. Give the same tool
to an eager beaver, a natural born tree cutter, and you can stand back
and watch the trees fall. High level languages, structured programming,
and object oriented programming are programming chain saws. Used
reasonably the cut down problems quickly and cleanly. 

The Internet has provided a mechanism to allow good programmers to meet
each other, size each other up, and work on projects together. That is
the real secret behind the success of open source. The average
programmers get run off from the projects. The other reason is that
people who are potentially good programmers get a chance to interact
with good programmers and learn from them. 

Buzz Word compliance and Coding Religions versus Pragmatic Judgment.

The pragmatic programmer reads about a new idea and evaluates it. He
compares and contrasts it to his current ways of doing things. He may
use it, he may not. Even if he doesn't decide to use it, he learns from
it. He might see that this idea really helps him solve a certain class
of problems so he uses it for those problems, but not for every problem.

Then there is the buzz word junky. This is the person who reads a new
book and believes every line in it. He abandons his old way of doing
things and starts complying with every rule in the book. He doesn't
think about them. He doesn't contrast and compare. He just accepts. Of
course, that kind of person is also a bad programmer. This is the kind
of person who concentrates on details and ignores concepts. This is the
kind or programmer who can tell you the number of CPU cycles it takes to
do a floating point divide on 8 different processors, but does not
understand the difference between O(n) and O(n*n). These are people who
do not understand that the process is not the product. They see only the
trees, never the forest.

Abstract Data Types, as opposed to Object Oriented Design, as opposed to
Object Oriented coding, as opposed to Object Oriented programming
languages.

The part of these arguments that I hate the most is when people start
arguing about the details OO programming languages without any
understanding of what they are talking about. 

In the beginning there were data types. These are things like integers
and floating point numbers and strings. Some very smart people started
thinking about what all these data types had in common. They realized
that they all had:

o A Representation. There was some way off looking at a bunch of bits so
that they acted like an integer or a float or a string.

o An Initializer. There had to be a way to create and initialize a block
of bits to be one of these things. Whatever it was. 

o A Finalizer. An abstract data type can be a really complex thing
inside and you might want to clean up after it. It may have complex
internal structure that must be manually torn down. It my be a front for
another abstract data type that lives somewhere else, like a database
record, and need to be put away when you are done with it. 

o Operators. These are the thing like "+" and "-" that operate on a data
type. They can change the internal value of the type, or they can
combine values of a type with one or more values of the same or
different types, and create a new value of some other type. Operators
have come to be known as methods.

o Predicates. Predicates are operators like "==" and "!=" that compare
values and return either true or false. 

Later I am going to refer to this collection of ideas as either RIFOP,
or IFOP, depending on the context.

The group of people that write simulations noticed that real world
objects, like boats, and planes, and even people, could be modeled as
abstract data types. They combined the concept of the physical object
with the concept of abstract data types and the class was born.

Object Oriented design is, was, and always will be, design using
abstract data types. 

Once people were thinking in terms of abstract data types, and designing
in terms of abstract data types, they naturally wanted to code in terms
of abstract data types. And, they did. They came up with rules for doing
it in Fortran and In C, and assembly language, and even in COBOL. 

I must mention LISP. Because of its nature I'm sure there was a
perfectly usable OO extension to LISP about three days after the first
LISP programmer learned the concepts of OOP. The argument over the
details has gone on for at least 30 years... But, LISP was object
oriented before people understood object oriented programming because it
has always embodied the ideas of abstract data types.

The basics rules were simple, but they did vary from language to
language. The basic idea was that you created the representation using
the tools available in the language. In C they were structs and
typedefs. In Cobol they were records. In FORTRAN they were usually a
collection of vectors. One vector for each field of what would be a
structure in C with the specific instances being denoted by an index
into the vectors.

The IFOP parts were just subroutines or functions. In C and assembly and
other languages that support pointers  to functions you could have each
abstract data type represented by a struct with a set of pointers to
functions inside of it. That let you change the methods of an abstract
data type at run time. This is a very handy thing to be able to do. 

Inheritance was easy to implement if all the methods were pointed to
from inside the struct. Just embed the parent in the child's declaration
and be sure that the initializer for the child calls the initializer for
the parent. Of course, there is some amount of fooling around with
function pointer to get the child to inherit the parents operators and
predicates, but no big deal.

All the while we were learning to do design using abstract data types
and learning to code those designs in non-OO languages people were
inventing OO languages.  All of them offered the ability to create a
"class" or an "object" that has an internal representation (class
variables) and all the IFOP stuff as procedures. And that was good.

Then the bickering set in:

 All the OO languages support inheritance. But, none of them seem to
support it the same way. You might notice that inheritance isn't
something that you find in a discussion of abstract data types. It only
applies to classes. It is an attempt to impose a certain philosophical
view, a hierarchical view of the universe, on code. That view comes out
the the simulation branch of the development of OOP. There are a lot of
different versions of inheritance. All of them work well for some
problems. None of them work well for all problems. None of them are
necessary. But, I would hate to have to use and OO language that didn't
support some form of inheritance.

Then the confusion set in:

Some of the languages offered polymorphisms. polymorphisms is a good
thing. But, it is not an OO thing. It just happened to show up in a lot
of OO languages. A lot of people saw it for the first time in those
languages so it gets lumped in with OO. 

Then there is operator overloading. Again, it gets lumped in with OO. I
first saw it in a dialect of FORTRAN. It has been around for a long
time. But, the first time most people ran into operator overloading was
in OO languages and so it gets lumped in as an OO features. Even though
it has nothing to do with OO.

Same thing with garbage collection. Some people think of it as an OO
thing, when it isn't. 

And, to me the real big one, is that all of the major OO languages have
dropped the ability to create new classes of objects at run time. You
can't compose objects, or add new variables to a class, or add new
methods to a class at run time. You can only do that at compile time. As
an old LISP programmer that sure confused the heck out of me... Not one
of these languages supports code as a first class data type.

Summary.

So what is the current situation? We have a bunch of poor programmers
who have memorized all the details of two or three OO languages who are
following the letter of the law with no understand of the spirit of the
law running around with the coding equivalent of chain saws cutting off
each others feet while proclaiming that they are doing the right thing.

Of in the corner you have a small group of good programmers
pragmatically applying all these concepts writing well designed reliable
code using what ever they think is the appropriate tool for the job.

                Bob Pendleton
-- 
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bob@xxxxxxxxxxxxx             +
+ blog:  www.Stonewolf.net             +
+ web:   www.GameProgrammer.com        +
+--------------------------------------+

Other related posts: