Informal History Discussion

Discussion moved over from InformalHistoryOfProgrammingIdeas in order to keep that page neater.

EditHint for brave gnomes: ConvertThreadModeToDocumentMode.

Discussions

One important aspect of the "history of programming ideas" is the subject of GroundBreakingLanguages (programming languages, that is).It is an important milestone in the evolution of a programming idea when programming languages that directly support that idea begin to appear. The purpose of the GroundBreakingLanguages page is to try to document which languages were the first ones to introduce what important ideas (and to give credit to the inventors of those languages).

Comments the refactoring guy didn't know where to put

As programming ideas go, "object" and "object-oriented" are now considered important by most software people, perhaps especially on Wiki. The two men who certainly invented the first term, and quite possibly invented the second, are the Norwegians KristenNygaard and OleJohanDahl. Their original work on Simula67 hardly seems to have been described on Wiki at all until I referred to it in passing in AlanKayOnObjects, now refactored into HeDidntInventTheTerm.

The ScandinavianSchool of objects has been forgotten longer than any other. "Come to Oslo, are you receiving me?" -- RichardDrake

Nygaard and Dahl received the 2001 TuringAward from ACM, the most prestigious prize in Computer Science, kind of Nobel, For ideas fundamental to the emergence of object oriented programming, through their design of the programming languages Simula I and Simula 67.

If you think there are imbalances in software history as seen by the software world in general, please say so on ClaimedInnovations or anywhere else on Wiki.

When OO was less mainstream, I liked to explain that object stuff wasn't as scary and risky as people might think because...

Object oriented programs are all modular: Who would make a Smalltalk or C++ method that isn't internally cohesive and with low coupling to other methods? Who would make a method that's hundreds of lines long? Who would scatter accesses to global variables across many methods in different classes? No decent OO programmer would consider doing these things, and yet by conforming to these rules we find that all OO programs are modular.
Modular programs are structured: Who, when writing modular (or OO) programs, would reduce coupling, increase cohesion, write functions of a reasonable length, and then... have multiple entry points to a function. ...or put in a big mess of GOTO statements. (Who would even bother, if the functions are short?) ...have lots of different exit points? (IE: Lots of "return" statements in the middle of complex functions.)

No, take any randomly selected Smalltalk program and measure it with modular and structured programming metrics. You'll find that it's very extremely modular and structured -- in spite of its programmers not having set out to accomplish this goal.

(Unless it's a very poorly written OO program ;-)

{As a RelationalWeenie, I find that OO often resurrects the spaghetti-like nature of pre-relational databases. In some ways, OO is Goto-like in its structuring compared to relational.}

Who would (such and such)...?

A BadProgrammer, and I have succeeded several of them.

[Note that the above reasoning was asking rhetorical questions. The fact that only a BadProgrammer would make such mistakes is implied and intended. The point is that the AverageProgrammer can write modular, structured code more easily with objects than they could before objects. Naturally, anyone can write a bad program in any language. -- TheEditor]

(Of course now everyone accepts objects as a good thing because they can see that everyone else says that objects are a good thing. I don't meet a lot of people with a real strength at thinking for themselves. ;-)

Some of us accept objects as a good thing because we've written "pre-OO" code and OO code, and prefer the way that things turn out with OO. -- KrisJohnson

Well, I would like to see this alleged bad non-OO code with my own eyes. Most of such examples presented to me before turn out to be bad design, bad specific languages, in bad need of a good relational database, or a specific niche where OO may indeed shine. I collect such examples. We can post and analyse it on or near OoEmpiricalEvidence.

Let me reinforce Kris' comment above. I have also written both procedural code (assembly and C) and object oriented code (C++). I initially fought the change in programming style required, but I am firmly convinced that using an object oriented style has made me a much improved programmer. -- WayneMack

CeeIsNotThePinnacleOfProcedural. Not a good language to compare with OO in my opinion.

Ditto. I ignored the whole Object Revolution back in the 1980s, to my great sorrow. At the time I thought it was all just a part of the methodology wars going around - you know, Yourdon versus Booch versus whoever. Object oriented design looked to be a component of the software development philosophy battle that was leaving behind a field of battered losers but not producing a clear winner. However, when I found out that OOD was the Real Deal® that rocked my world pretty hard. -- MartySchrader

Re: The point is that the AverageProgrammer can write modular, structured code more easily with objects than they could before objects.

I take issue with that claim. But perhaps this all belongs under BenefitsOfOo.

Since this is an Informal History, there are a couple of points that tend to get left out of the typical discussion that I'd like to mention. It's probably going to look like a typical "there's nothing new under the sun" or "hohum, we were doing that years ago" kind of "gripe", but that's not the intention; it's simply a part of computer history that many younger folk may not be aware of.

Object Oriented techniques: Many of the concepts of encapsulation, data hiding, formalized public contracts, polymorphism, etc. were initially used in loadable device drivers. The {Open, Close, Read, Write, Control} methods implemented by drivers in Unix are perhaps the ultimate example of this. However, I remember using many of the same techniques of "package the methods with the data (and don't let anyone outside know about the internals)" back in '79 - '80 ... and I learned from a bunch of guys who were doing it before that.

Many of us "simulated" what would become C++ objects with C structs by holding function pointers in the struct itself and calling "methods" on the "object" using them. This allowed the behaviour to be tailored or changed at runtime in a way similar to "virtual" interface signature declarations.

Message (Event) interfaces: This is basically just a means of moving interrupt service routines and data stream queuing up to the application level. A lot of people who never wrote a driver or an ISR were (justifiably) amazed at the flexibility and power of decoupling layers or subsystems by this means - but it was still pretty much "old hat" to many folks who had "grown up" along with the computer itself.

Many very powerful systems were put together on the basis of small processing "blocks", with well-defined behaviour and interfaces, which were chained together by intermediate "messages" and which ultimately had emergent capability greater than the original intent (or perhaps expectation would be more accurate).

Functional Programming: This is very similar in concept to the "mini-language" technique (SubLanguage). I've frequently found that an understanding of how processors work internally; how operating systems are typically organized; and how compilers do their jobs, has enabled me to implement solutions with less actual code by designing a language to represent a virtual machine with "instructions" which represent atoms of solution in the problem space. This follows right along with the second point about chaining small chunks of solution together to make a big solution, it's just slightly more formalized.

In fact, it's probably important to note that one of the tenets of computer programming, as I learned it, is that programs don't solve problems. The program is a representation of a solution already known (or recently discovered; or a guess at what might be a solution) within a particular problem domain - i.e., we can't write a program to automate a solution we haven't got! The more generic we make our implementation of the solution, the more likely it is to apply to other problems from the same or similar domains. We always started by identifying the appropriate data and then defining the operations needed to manipulate it because that was the only way to successfully modularize.

At any rate, the point of most of this is that a lot of these techniques were "invented" by pragmatic people trying to work around issues of memory space, processing speed, constant "reimplementation", etc. Many (if not most) of them weren't in the academic arena disseminating the results. Thus much of what was considered "best practice" ended up being passed around by apprenticeship, observation, word-of-mouth, impromptu conference "sessions", or sometimes bulletin boards (old-fashioned newsgroups). I think it's important to capture this type of anecdotal history because many tricks and ideas which are broadly useful would otherwise get lost in the mists.

As a simple example, try this one for picking out pieces of a mask (originally found in a parity calculation routine):

  int lowestBitSet( int n )
  {
return (n & -n);
  }

By taking a mask of desired "operations" to be performed, extracting the bits one at a time, calculating the log2 (makes an index), and then calling a function pointer stored in an array at that index, you get very flexible capability defined in an extremely dense fashion.

Anyway, it'll be interesting to see if this stays here, gets moved, or generates any kind of response...

-- KaiBouse?

"... we can't write a program to automate a solution we haven't got!"

This is true and insightful for most situations. However, you may be interested in MetaHeuristics, which are a counter-example.

CategoryHistory

Just a question, speaking of implementing objects in C - where is C in the InformalHistory?? Clearly it is worthy of note.