Informal History Discussion

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

EditHint for brave gnomes: ConvertThreadModeToDocumentMode.

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...

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.

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.

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).

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.

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

View edit of December 15, 2010 or FindPage with title or text search