Object-Oriented Cult: A Slightly Skeptical View on the Object-Oriented Programming

Don't force objects on what is essentially not an "objectifable" problem

cargo cult programming: n. A style of (incompetent) programming dominated by ritual inclusion of code or program structures that serve no real purpose. A cargo cult programmer will usually explain the extra code as a way of working around some bug encountered in the past, but usually neither the bug nor the reason the code apparently avoided the bug was ever fully understood (compare shotgun debugging, voodoo programming). The term `cargo cult' is a reference to aboriginal religions that grew up in the South Pacific after World War II. The practices of these cults center on building elaborate mockups of airplanes and military style landing strips in the hope of bringing the return of the god-like airplanes that brought such marvelous cargo during the war. Hackish usage probably derives from Richard Feynman's characterization of certain practices as "cargo cult science" in his book "Surely You're Joking, Mr. Feynman!" (W. W. Norton & Co, New York 1985, ISBN 0-393-01921-7). Jargon 4.2 Both communism and OOP rely on the concept of classes. Both generate a lot of fanaticism and overuse this notion. That might be not an accident :-). Slashdot A data structure is a structure, not an object. Only if you exclusively use the methods to manipulate the structure (via function pointers if you're using C) and each method is implemented as co-routine, then you have an object. Such an approach is typically an overkill. OO zealots make mistake typical for other zealots by insisting that it must be used for everywhere and reject other useful approaches. This is religious zealotry. And please remember that Dark Ages lasted several hundred years.



Is OO a topic artificially promoted for mercantile gains by

"a hoard of practically illiterate and corrupt researchers

publishing crap papers in junk conferences." ?

Object-oriented design is the roman numerals of computing.

— Rob Pike

We have persistant(sic) objects, they’re called files.

— Ken Thompson

The object-oriented model makes it easy to build up programs by accretion.

What this often means, in practice, is that it provides a structured way to write spaghetti code.

— Paul Graham

“design patterns” are concepts used by people who can’t learn by any method except memorization,

so in place of actual programming ability, they memorize “patterns” and throw each one

in sequence at a problem until it works

~ Dark_Shikari

I often wonder why object oriented programming (OO) is so popular, despite being a failure as a programming paradigm. It is still advertised as the best thing since sliced bread, despite the fact that is rarely used in Web programming, which is the most dynamically developing application area (and many of those programs are based on LAMP stack with PHP as "P" in it and that means no OO at all). Is it becoming something that is talked about a lot, but rarely practiced? Just a topic artificially promoted for mercantile gains by "a hoard of practically illiterate and corrupt researchers publishing crap papers in junk conferences." ? Or is it a "for profit" cult?

To me it looks more like more dangerous development -- a variant of computer science Lysenkoism (and I can attest that the current level of degradation of computer science definitely reminds me the level of degradation of social sciences under Stalin; it's now more about fashion then research with cloud computing as the latest hot fashion.

For many project OO is just an overkill: a programmer who uses it in such cases looks like the proverbial general who sent a tank division to capture unarmed natives village. Many projects do not support the idea of many instances of the same object, which is the key in the concept of classes (which came from simulation programming languages such as Simula-67). Class with a single instance is not a class; it is a perversion ;-). As Joe Armstrong, the creator of Erlang, aptly observed:

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

If a parent and child could arbitrarily switch places, then the problem clearly is not suitable for "objectification". Often it is better to work with tags then with hierarchies. Unix file system can serve as a good model of object hierarchy. But it is often easier to work with tags then with paths. For example the document tagged as #Company and #Procedures can be put in Folder Documents/Staff and still be found. Tags have no order or hierarchy. If you read books considered to be "OO classic" the distinct impression that one gets is that "king is naked". And the authors are weak and semi-illiterate in computer science demagogs promoting particular dogma for material gains (conferences, books, higher position within computer science departments, etc). BTW the level of corruption of academic researchers in XX and XXI centuries is unprecedented and there are a lot of example when academic departments in major universities promote junk science. Just look at economics department and neo-classical economics.

But if we assume that OO is a variant of Lysenkoism in computer science, then the absurdity of dogma does not matter and does not diminish the number of adherents. As universities are captured it has huge staying power despite of this. It is essentially the same trick, that on much larger scale played in US universities with neoclassical economics.

In the end, productivity and quality of the resulting code are the only true merits of any programming methodology. They are two critically important metrics that programming methodologies need to be judged upon. As Paul Graham noted the length of the program can serve as a useful (although far from perfect) metric for how much work is to write it and how many bugs it will contains after debugging is finished. Not the length in characters, of course, but the length in distinct syntactic elements (tokens) -- basically, the number of lexical elements or, if you wish, the number of leafs in the parse tree.

It may not be quite true that the shortest program requires the least effort to write, but in general length of program in lexical tokens correlates well with the complexity and the effort. OO approach fails dismally in this metric as for the program in the same language which permits structuring the program in both non-OO (procedural) and OO fashion (C++, Perl, etc) program structured in OO fashion is typically longer.

Being extremely verbose (Java might be a king of verbosity among widely adopted languages; really the scion of Cobol ;-) is only one problem that negatively affects both the creation and, especially, maintenance of large programs. but it is an important problem. Java is definitely so verbose that this factor alone push it down one level below, say, PL/1. And it's sad that PL/1 which was created in early 60th, is still competitive and superior to the language created more then 50 years later. Attempts to raise Java level using elaborate "frameworks" with complex sets of classes introduced other problems: bad performance and difficulties in debugging.

OO is a fuzzy concept, that has both good and bad sides. First of all it is often implemented in an incomplete, crippled way (C++, Java) which undermines its usefulness. To enjoy advantages of OO programming the language should provide allocation all the variables in the heap, ensure the availability of coroutines, correct implementation of exception handling, and garbage collection. As such it is an expensive proposition (execution-wise).

Also we should clearly state that OO-model does incorporate several good ideas:

The idea of equivalence between procedures and data structures. Some "OO" languages does not even include separate notion of data structures relying on one general mechanism. This is probably a mistake, but you get the idea. This idea of equivalence is a very elegant, very innovative at the time concept that initially appeared in simulation languages and came into general purpose programming languages via influence of Simula 67. Hierarchical partitioning of variables namespace into trees with "inheritance" as a pretty neat method of accessing lower level data from higher level abstractions. Somehow it reminds me Unix filesystem structuring. This is what makes creation of large, complex systems simpler. Or just possible. Without namespaces large program development requires iron variable naming discipline that in the past only IBM was capable of. But this not the only way to implement namespaces. Non hierarchal namespaces are also very useful (common block in Fortran, external variable and structures in PL/1)

Usage of the heap instead of stack for allocation of variables. In general purpose language this concept was first implemented in PL/1 on early 60th. So this is 50 years old technique and before PL/1 by LISP. Still dominance of C which was a system programming language (and should be viewed as severely cut dialect of PL/1 with addition of B-style pointers) badly affected the acceptability of this idea, essentially slowing its wide adoption for approximately 12 years (Java was created in 1995, while C was created around 1973n late 60th . Java was the first widely used language with heap allocation of variables. Limitations of early hardware also played an important role.



C was created mainly due to experience with PL/1 as system programming language used in Multics as both Thompson and Richie were part of Multics development team for several years. So it was designed as the system programming language. But later due to availability of open source compliers it's domain of applicability was extended to application development despite absence of automatic storage allocation and subscripts checks which lead to buffer overflow vulnerabilities. The latter became a huge security problem from which we are still suffering to this day. Better and safer languages for application development were possible since probably 1990 due to tremendous progress in hardware and C++ was an attempt to rectify some flaws of C as application development language borrowing some ideas from Simula67.



Later Java introduced the allocation variables in heap and garbage collection into mainstream. Which probably explains why Java, despite being so badly designed language, managed to overtake Cobol. Later scripting language made is idea standard de-facto.

Naturalness of grouping of related procedures operating on the same data under "one roof". This was also pioneered by PL/1 with multi-entry procedures. This idea is also related to the general equivalence of procedures and data structures which we mentioned before. It is just another side of the same coin. The idea of constructor is essentially the idea of initializing of such dynamically allocated data structure on which such multi-entry procedure operates. As simple as that. All this fluff about classes as abstractions of objects with the set of operations on them is just a smoke screen which hide the simplicity of the idea.

Extension of the idea of type to structures and providing a mechanism of creating a new instance of the structure with automatic population of necessary elements via special initializing procedure called constructor. Simula-67 was the inspiration here, but even before Simula-67 PL/1 invented the concept of creating similar structure from the base with the like operator. Of course in OO this idea got a new sauce and new terminology, but compiler-writer wise this is the same idea. Still it seems to me that JavaScript prototype-based approach is superior and in this sense only Javascript and its derivatives deserve the name of true object oriented languages. See Prototype Based Object-Oriented Programming

"The great thing about Object Oriented code is that it can make small,

simple problems look like large, complex ones."

Top 50 Funny Computer Quotes

Unix conceptual model -- "everything is a string" and "everything is a file" is incompatible with OO model, which want to segregate different objects as much as possible. OO is essentially return to a new level to OS/360 mentality where there were dozens of different types of files supported by the OS. If this is a future I do not want to be a part of it :-)

Often encoding complex data structure as a string with delimiters lead to more clear and modifiable code then using multitude of methods accessing some binary structure (and object is a data structure that conists of data forlds and references to methods that work to those data felds) . Binary structures are IBM way to design programs and the fiasco of OS/360 had shown that this a road to nowhere. Rightnow public relations are on completely different stage and that was a clear failure in 1960 can be sold as the complete success in 2000.

Funny that one of the most influential book on software engineering The Mythical Man-Month is actually about a dismal failure of IBM with the design of operating system for the revolutionary hardware of System 360 line of computers. And while term did not exist at the time, the way IBM designed the filesystem can be called object oriented.

Another objection along the same lines is the level of overcomplexity of the language that OO creates in comparison with simpler approaches to the structuring of the program namespace "at large" like modules (modules were actually a really brilliant invention.) If you look at the popular objected oriented languages like Python 3.x is clear that generation of new types is the process that had run amok. It makes language very complex saturated with thousand of types and million of methods that no human can ever muster; and conversion between types a nightmare.

In a way OO type system acts like a bureaucratic organization: each department within it wants to increase ifs size and influence at the expense of others and those turf wars consume much of the energy of the organization.

Derived types have their uses. But there are far from universal way of structuring the problem and often they are not the nbest way. But as soon as user defined types were introduced they became kind of object of worship the superstition that supposedly can cure all ill of this world (or at least all ills of software engineering).

As any cult it instantly attracted a special category of ruthless and power hungry people who became the priests of this new cult. That's probably the most dismal side effect of OO cult. Everythng now is viewed throw the prism of the "class struggle," so to speak. that neas to phenomenon which can be called the OO trap: tremendous among of time wasted on unnecessary redesigning and polishing of OO classis

As any cult it instantly attracted a special category of ruthless and power hungry people who became the priests of this new cult. That's probably the most dismal side effect of OO cult. Everythng now is viewed throw the prism of the "class struggle," so to speak. that neas to phenomenon which can be called the OO trap: tremendous among of time wasted on unnecessary redesigning and polishing of OO classis

Creation of a set of classes in OO projects often degenerates for "the art for the sake of art.": all efforts are spent on polishing and generalizing the set of classes while the mail project task remains neglected. This became a compulsive idea and the person became hooked to it.

Waisting time on never ending polishing and redesigning of OO classis is an epidemic among OO programmers, and often pushes a project in which they particulate into real jeopardy. The unstoppable desire to create the masterpiece out of the set of classes is so prevalent among OO programmers that it needs to be confronted with management actions, if as a project manager you care about the project schedule.

For some reason, "good enough" solution are improved, improved and improved, at the expense of the key objectives of the particular programming project. Desire to make them more universal and more flexible that is warranted for particular goal proved to be irresistible for majority of programmers. Most of those super-polished classes are never reused.

But changes to them due to polishing and generalization of function require minor changes in programs which uses those (now more elegant, more universal and more powerful) classes and this cycle never ends. Also with time the classes hierarchy gradually became deeper and less and less efficient.

Often the analogy with objects pushes programmers way too far and they lose the contact with reality: they stop viewing OO as just a sometimes useful abet questionable abstraction/paradigm of software development and a good way to structure program namespace, but became what Eric Hoffer called "true believers" who hate all alternative approaches to structuring computer programs and namespace. Hatred is the most accessible and comprehensive of all the unifying agents.

What true believers does no admit that in many cases OO programs are longer then their non OO counterparts and that alone make them more error prone. Moreover enforcing object oriented model on problem that do no lend themselves to this approach is an invitation to the disaster. I saw (and translated from one programming language to another) many Unix utilities in which authors attempted to write them in OO-style. They were mostly junk. Only few were written in really creative style which when you delve into the source ode you exclaim: this guy really is a master who thought deep.

No language guarantee the creation of good, reliable programs. Especially is such a complex environment as modern Unix or Windows, which are excessively complex operating systems (with Windows being bizarre complex, far beyond redemption) Programming talent is essentially "language independent" and gifted programmers can adapt and overcome shortcoming of any language, while mediocre programmer are able to create a mess in any language.

At best claims of OO about better reliability of programs are definitely exaggerated, at best; at worst they are fake and should be viewed as a marketing trick. OO makes programs more verbose and the number of bugs linearly depends on the number of codelines in the program.

Also as programming after, say, 2000 is mainly driven by fashion, the warts of any particular approach become understood only a decade or more after the "boom" in particular technology has ended and experience accumulates. Only then can see OO technology without rose-colored glasses.

Writing this article in, say, 1996, would be impossible (and impractical).



"The true faith compels us to believe there is one holy Catholic Apostolic Church and this we firmly believe and plainly confess. And outside of her there is no salvation or remission from sins." - Boniface VII, Pope (1294-1303) “The quality of ideas seems to play a minor role in mass movement leadership. What counts is the arrogant gesture, the complete disregard of the opinion of others, the singlehanded defiance of the world.” ― Eric Hoffer, The True Believer: Thoughts on the Nature of Mass Movements

Object-oriented programming (OOP) is often treated like a new Christianity and religious zeal of converts often borders with stupidity. And it definitely attracts numerous charlatans which propose magic cures like various object methodologies and, what is worse, write books about them ;-).

All-in-all my impression is that for almost 30 years of its existence OO failed to improve programming productivity in comparison with alternative approaches, such as scripting languages (with some of them incorporating OO "just in case" to ride the fashion as you should never upset religious zealots ;-).

If so this is more of a religious dogma, much like previously were "structured programming" and verification bonanza (with Edger Dijkstra as the first high priest of a modern computer science techno cult aka "church of computer scientology" ;-). And it is true that there are more corrupted academic fields then computer science, such as economics.

But still this is a really terrifying in a sense that it replicates Lysenkoism mentality on a new level with it's sycophants and self-reproducing cult mentality. And the level of groupthink, this cult mentality is a real problem. As Prince Kropotkin used to say about prison guards in Alexandrov Central (one of most strict regime prisons in Tsar Russia) where he served his prison term "People are better then institutions".

Like in any cult, high priests do not believe one bit in the nonsense they spread. For them it is just as the way for getting prestige and money. Just ask yourselves a question: in what place there were more sincere communists in, say, 1970th: in the Politburo of CPSU of the USSR or any small Montmartre cafe. Like in all such cases, failure does not discourage rank and file members of the cult. Paradoxically it just increases the cult cohesion and zeal.

And as of 2014 OO adepts are still brainwashing CS students despite the failure of OO provide advertised benefits for the last 25 years (Release 2.0 of C++ came in 1989). And they will continue just because this is very profitable economically. They do not care about negative externalities (an economic term that is fully applicable in this case) connected with such a behavior. Just give me a Mercedes (or tenured position) now and f*ck the computer science future.

So far all this bloat and inefficiencies were covered by Moore's law and dramatically improving parameters of hardware (please remember that initial mainframes often used to have 64K (not megabyte but kilobytes) of memory and PL/1 (which in many areas is a higher level language then C++ and Java) worked well in those circumstances which is simply incredible, earth-shuttering achievement if you ask me. If you look at IBM optimizing and debugging complier then gcc and other C++ compilers clearly looks like a second rate implementations.

In other words, you can always claim any software development methodology to be highly successful, even if it is not. Bloat and inefficiencies will be covered well by the tremendous growth of power of computers that is still continuing unabated, although slowed down a bit. In ten years people start discovering the truth, but at this point you will be rich and successfully retired somewhere or Hawaii. Meanwhile to can fleece lemmings by running expensive courses and publishing books that teache this new and shiny software development technology.

You can claim any software development methodology highly successful because even if it is not. Bloat and inefficiencies will be covered well by the tremendous growth of power of computers that is still continuing unabated, although slowed down a bit.

OO is a set of certain ideas which are not a panacea and as such never was and never will be a universally applicable programming paradigm. Object orientation has limited applicability and should be used when it brings distinct advantages, but not be pushed for everything like naive or crooked (mostly crooked and greedy) authors of "Object Oriented Books" (TM).

Here is the number of books of authors who wanted to milk the cow and included words "object oriented" in the title. Stats are for each year since 2000 (data are extracted from Library of Congress):

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 92 83 104 76 69 70 76 68 57 60 61 46 27

So there are a lot of authors, who try to sell the latest fad to unsuspecting audience much like snake oil salesmen of the past.

I have strong personal hate for authors who wrote Object Oriented Algorithms and Data Structure books, and especially authors who convert previous procedure-oriented algorithms books into object-oriented attempting to earn fast buck; corruption is a real problem in academia, you should know that ;-).

In a way, the term "object oriented cult" has a deeper meaning -- like in most cults high priests of the cult (including most "object oriented" books authors) really love only money and power. That is the real (but hidden) object of many OO evangelists. And they do not believe in anything they preach...

In a way, the term "object oriented cult" has a deeper meaning -- like in most cults high priests of the cult really love only money and power. And they do not believe in anything they preach... That is the real (but hidden) object of many OO evangelists.. And they do not believe in anything they preach...

Many common applications can better be developed under different paradigms such as "multi-pass processing", compiler like structure, abstract machine paradigm, functional language and so on. Just imagine that somebody tries to solve in object oriented way a typical "parsing of a text string problem" that can be solved with the regular expressions or via lexical and syntax analysis algorithms.

Of course any sting is a derived object of alphabet of 26 letters but how far we will go with such "OO approach". Just look at the poverty of books that sell object oriented approach to students who want to study algorithms and data structures. Those snake oil salesmen who wrote such books are using OO as a marketing trick to get a quick buck do not deserve the title of computer scientists and their degrees probably should be revoked ;-) Lord Tebbit once said "You can judge a man by his enemies." Judging from the composition of pro-OO camp in computer science any alternative paradigm/methodology promoter or even skeptic like me looks good by definition ;-)

When I think about OO I see two distinct trends:

Natural (slow) progress in refinement of existing concepts in a way more suitable for modern hardware . One is positive and is connected with the refinement of traditional programming constructs (generic procedures, templates, hierarchical namespaces and controlled visibility of variables, etc.). The hierarchical structuring of namespace and, to a certain extent, limited hierarchical namespace inheritance is a very good idea and here OO languages added to the language design arsenal. In essence OO blends concept of the procedure and data structure, providing each data structure with procedural components (pointers to functions) and the way to initialize instances allocated on the heap using a special procedure called constructor.

. One is positive and is connected with the refinement of traditional programming constructs (generic procedures, templates, hierarchical namespaces and controlled visibility of variables, etc.). The hierarchical structuring of namespace and, to a certain extent, limited hierarchical namespace inheritance is a very good idea and here OO languages added to the language design arsenal. In essence OO blends concept of the procedure and data structure, providing each data structure with procedural components (pointers to functions) and the way to initialize instances allocated on the heap using a special procedure called constructor. Junk science or Lysenkoism, if you wish. The second is hugely negative attempt to position OO as a new universal software engineering paradigm. Often OO is oversold as panacea and even as a cult (Bertrand Meyer). Ideally objects should be independent communicating entities, which means that programming is accomplished by building structures and exchanging messages rather than by traditional procedural way. For many (most?) problems forcing OO representation leads to a mismatch of the language used to the problem domain.

To understand where OO languages stands here requires to delve in a little bit of history. First on all programming projects can be categorized based on the size of codebase. While limits are somewhat arbitrary the general tendency holds well. For example, if we exclude comments and lines devoted to help screens and processing of options we can distinguish between following six categories:

Tiny: upto 100 lines. Productivity of programmer can be 1000 lines of debugged and tested code per day or more. Small upto 1K line. Productivity of programmer can be 100 lines of debugged and tested code per day or more. Medium upto 10K lines. Productivity of programmer can be 10 lines of debugged and tested code per day. per day or less. Staring from approx 1K line you need to use multiple namespaces so only programmers who understand and can ingeniously apply this concept well can successfully work on the upper limit of this range. That excludes probably 50% of people who call themselves programmers. Large upto 100K lines. Productivity of programmer is typically less then 10 lines of debugged and tested code per day. If manpower is limited such project takes years to complete (two or more years). Usually this is complex systems. For a project that contains 100K line and has only one programmer a reasonable estimate is a couple of years (initial versions of Linux, Python and Perl interpreters belong to this category) Only few people are able to successfully design and implement such programs. Of course complexity matters too. For example compilers and interpreters are more complex and requires specialized knowledge to write. This is probably an upper limit for an individual programmer. Huge above 100K lines. The project has high chances' to fail or finished with large cost and time overruns. Such projects require a team of programmers and specialized tools. Monstrous above 1 million lines. The project has very high chances to fail. Large cost and time overruns are given. OS/360 was one of such projects. It was described in famous Fred Books book the Mythical man-month. Please not that while hardware was the real breakthrough, the OS was the second rate despite huge cost and time overrun. Only compliers for OS/360 were first class. But that was old IBM later destroyed by greedy and evil neoliberal bean counters Louis V. Gerstner Jr. and Samuel J. Palmisano

What is interesting that significant share of the most important software projects, that created system we used today were completed before 1990 when OO became fashionable (Unix, C, C++, DOS, Windows 85, Windows NT, Microsoft C and C++ compliers, Microsoft Office, GNU toolchain, Oracle, DB/2, Apache, Delphi, Perl,

As experience with hose projects had shown the structuring of programming namespace and developer discipline is the necessary precondition of the success. This is the major issue. For medium size projects and above skillful structuring of the namespace is one of key determinant of the success of the project. while initial tools of structuring namespace were based on Algol-60 concept of scope, Fortran concept of common blocks and and separate compilation, Modula-2 developed between by Nicklaus Wirth from 1977 and 1985 and not Simula-67 was the real breakthrough in this area.

Capabilities of structuring of namespace differs between major programming languages. Algol-60 introduced great idea of semitransparent mirror when subroutines can view variable in encompassing subroutines but encompassing subroutines can't view variables declared inside nested subroutines. This abstraction provided be very powerful way of structuring namespace. It also introduced the idea of the scope of variable (local vs global is just two extremes, there ca be shades of grey in hierarchical system that Algol-80 invented. that also introduced related to scope the concept of visibility. Again this was a tremendous breakthrough, a real revolution in programming languages design. Simula 67, the first OO language in existence, was an extension of Algol-60

Fortran, which was older language then Algol 60, approached the problem differently -- because of separate compilation it defined so called common blocks, which on complier level are separate namespaces were each variable is prefixed by the name of the common block. You can think that each separately complied subroutine 'exports" variables into common block.

PL/1 managed to combine Algol 60 ideas with Fortran idea on a new level and generalized this idea introducing the concept of external variables in namespace structure that fully resembles Algol-60. In PL/1 each separately compiled program need to declare variables it want to export to other program as external and those variable do not obey algol-60 visibility rules. They also need to be allocated statically and run time mapping of addresses was performed by the linker. There is also more complex idea of areas more similar to Fortran common blocks but dynamic in nature. What is important is that PL/1 introduced the idea of "multi-entry subroutines, which were essentially "poor man classes."

With the growth of CPU speed and size of the memory, the to allocate variables on the heap with garbage collection became more and more important ( the only early language with built-in garbage collection was LISP, originally specified in 1958). PL/1 also introduced early version of classes in the form of multiple entries to the subroutines and notion of generic calling interfaces and multiple inheritance via like attribute for structure (which copied the definition of the initial structure to the new structure -- the derivate of the old. Call to the subroutine with multiple entries in PL/1 was in essence the call to a "poor man" constructor, which can initialize various structures present in it, and each entry point was a "poor man" method of this "class". As Perl does not require a return statement at the point where new entry points is defined, they could overlap, but that's non-essential. Entry point can be "generic" so that different entry points are selected by complier based on the combination of input parameter (for example, one for int another for float). Unless special care was taken and all variables are allocated on the heap, such a "poor man class" has only one instance. And while nothing prevented programmers to program it in such a way that it supported multiple instances via pointers to them in many case one instance is enough :-) Multiple instances were needed less commonly and they can imitated by using array of structures and index to this array pointing to particular instance. So in rudimentary form we can see that key elements of OO existed since April 7, 1964, the date of release of OS.260 with its compliers suit. or more then 50 year ago. Think about it -- half a century ago.

The first language that merged previously existed elements in a well integrated framework which later became known as OO, including the idea of "constructor", was Simula-67. While a derivative of Algol 60 it stems from so called simulation languages with their emphasized on imitation of real-world objects, and it shows. It never achieved mainstream usage but was influential as a revolutionary prototype. Later in "bastardized" form (without co-routines) the ideas if Simula-67 were rehashed in C++ with first commercial release in 1985 and a usable implementation around 1989 (V.2.0). Neither of those language addressed the key problem of regulating of visibility of variables, which is the critical problem for large programming project. Simula still lived in Algol-60 world of semi-transparent windows installed on the boundaries of subroutines. C++ separated the namespace via separately compiled programs. It also can import identifies via inheritance mechanism.

I would like to stress again that the breakthrough was in handling of namespaces in programming languages was achieved around 1985 by Nicklaus Wirth (one of the contributors to Algol-60 project), before OO became fashionable. Modula (developed from 1977 to 1985) introduced the concept of modules: programming unit with its own namespace that can export variables into other modules on the main program. It was the only early mainstream language that supported coroutines. The revolutionary concept of exporting and importing variable from namespaces of module, each defined by physical files allowed "regulate" visibility of variables that really can scale. In a way this was a superior, moré powerful and flexible way to deal with this problem then inheritance mechanism introduced by Simula 67. All those talks about multiple inheritance in view of existence of this mechanism are slightly suspect ;-) But nothing can stop complexity junkies to flog the deal horse :-).

Here is an example of the source code for the "Hello world" program in Module 2:

MODULE Hello; FROM STextIO IMPORT WriteString; BEGIN WriteString("Hello World!"); END Hello. The Modula-2 module may be used to encapsulate a set of related subprograms and data structures, and restrict their visibility from other portions of the program. The module design implemented the data abstraction feature of Modula-2 in a very clean way. Modula-2 programs are composed of modules, each of which is made up of two parts: a definition module, the interface portion, which contains only those parts of the subsystem that are exported (visible to other modules), and an implementation module, which contains the working code that is internal to the module. The language has strict scope control. In particular the scope of a module can be considered as an impenetrable wall: Except for standard identifiers no object from the outer world is visible inside a module unless explicitly imported; no internal module object is visible from the outside unless explicitly exported. Suppose module M1 exports objects a, b, c, and P by enumerating its identifiers in an explicit export list DEFINITION MODULE M1; EXPORT QUALIFIED a, b, c, P; ... Then the objects a, b,c, and P from module M1 become now known outside module M1 as M1.a, M1.b, M1.c, and M1.P. They are exported in a qualified manner to the universe (assumed module M1 is global). The exporting module's name, i.e. M1, is used as a qualifier followed by the object's name. Suppose module M2 contains the following IMPORT declaration MODULE M2; IMPORT M1; ... Then this means that the objects exported by module M1 to the universe of its enclosing program can now be used inside module M2. They are referenced in a qualified manner like this: M1.a, M1.b, M1.c, and M1.P. Example: ... M1.a := 0; M1.c := M1.P(M1.a + M1.b); ... Qualified export avoids name clashes: For instance, if another module M3 would also export an object called P, then we can still distinguish the two objects, since M1.P differs from M3.P. Thanks to the qualified export it does not matter that both objects are called P inside their exporting modules M1 and M3. There is an alternative technique available, which is in wide use by Modula-2 programmers. Suppose module M4 is formulated as this MODULE M4; FROM M1 IMPORT a, b, c, P; Then this means that objects exported by module M1 to the universe can again be used inside module M4, but now by mere references to the exported identifiers in an "unqualified" manner like this: a, b, c, and P. Example: ... a := 0; c := P(a + b); ... This technique of unqualifying import allows use of variables and other objects outside their exporting module in exactly the same simple, i.e. unqualified, manner as inside the exporting module. The walls surrounding all modules have now become irrelevant for all those objects for which this has been explicitly allowed. Of course unqualifying import is only usable if there are no name clashes. These export and import rules may seem unnecessarily restrictive and verbose. But they do not only safeguard objects against unwanted access, but also have the pleasant side-effect of providing automatic cross-referencing of the definition of every identifier in a program: if the identifier is qualified by a module name, then the definition comes from that module. Otherwise if it occurs unqualified, simply search backwards, and you will either encounter a declaration of that identifier, or its occurrence in an IMPORT statement which names the module it comes from. This property becomes very useful when trying to understand large programs containing many modules. The language provides for (limited) single-processor concurrency (monitors, coroutines and explicit transfer of control) and for hardware access (absolute addresses, bit manipulation, and interrupts). It uses a nominal type system.

The next advance in set of concept which are marketed as OO was, as strange as it sounds, pipe and socket concepts in Unix. Because the other important element of a set of ideas that constitute OO toolbox is that idea that each instance of the object should have "state". It can suspect execution at some point, return control to the caller and on next invocation to resume the execution from exactly this point. We are tailing about coroutine concept here which was introduced by Melvin convey around 1963 adn was present only in two early programming languages: Simula 67 and Module This concept got a new life and entered mainstream in Unix via the revolutionary concept of pipelines, one of the crown jewel of Unix architecture. Members of pipeline can be viewed as objects that exchange information via messages. Exchange of information via messages lie in the core of "real" OO.

Perl was the first scripting language that created a special programming construct corresponding to namespace called " package " and the notation, which allowed arbitrary access of variables from any namespace to any namespace as long as you know the name of this namespace and provide it explicitly as a prefix of the variable. For example $main:line in Perl is a variable line in namespace main:: . Python was another which essentially replicated Modula ideas.

Export of the variable is like creation of the symbolic link in Unix filesystem, and it allows to use this variables in a different namespace without qualifying it with namespace explicitly.

That in short is the overview of the key ideas. OO added nothing to it. It is just a marketing term that denote combination of several idea into more or less usable package. And the idea of inheritance is no way central to it it is just a variation of the idea of namespaces introduced in early 1970 in Modula.

All OO languages are mix and match various flavors of the same key pre-existing ideas, which some form existed on or before early 1970 and, as such, they are 50 years old. Some OO languages integrate those ideas with better conceptual integrity then others. That's it.

Against, the idea of constructor of the class (as the way to initialize structures in a subroutine) and set of methods was present implicitly in the concept of multi-entry subroutines in PL/1. Message parsing as a programming paradigm was invented by Melvin Conway in 1962 as the method of structuring COBOL complier (the idea of coroutines) and later in a brilliant, innovative form found its way into Unix pipes and sockets.

I can add to this that System/360 in 1962 introduced the idea 8 bit byte and byte addressable memory, along with a really sophisticated instruction set (for example, tr function present in Unix as a command and as built-in function most programming language today is direct descendant from this instruction set). Which was a milestone in the development of hardware that later make possible for us to use interpreted languages like Perl, Python and Ruby, and do not care about ten times of more speed penalty that such implementation entails.

All-in-all, Algo-60, System/360 (with it 8 bit byte, byte addressable memory, high quality compliers, including PL/1), Simula-67 in 1960th, Modula, and Unix in 1970th were trailblazers. In comparison with them ideas that constitute OO were side show, which possible exception of Molula-2 breakthrough.

So when some OO "true believer" claims that Python is OO language, the real question is "to what extent" and what benefits vs costs Python OO implementation provides (fpr example, treating stings as a immutable objects does entails significant costs, even on modern computers ;-) Truth be told only Stackless Python fully implement coroutines concept, when modules do have an internal state and can exchange messages. And any language that does not fully support coroutines and "message passing" interfaces can't be viewed as a "true" OO language.

More often thant not the label of OO language serves more like a marketing gimmick ;-) For example to that extent "classic" C++ is an OO language is an interesting question.

Someone thinking that they should stick to the OO paradigm and treat the others on the order of the goto statement in levels of immorality are really missing out by not looking at this paradigm. The metaprogramming capacity of templates is also quite impressive...The largest pitfall is the belief that OOP is a silver bullet, or the "one perfect paradigm." c++ - Avoiding Object Oriented Pitfalls, Migrating from C, What Worked for You - Software Engineering Stack Exchange

While those good ideas shine in certain classes of programming tasks, such as GUI interfaces, real world system modeling, etc, there are programming tasks (for example computational) were they are useless or even harmful. And generally OO approach does not fare well is sting/text processing tasks iether.

But when I see classic computer algorithms books polluted by OO nonsense, this is just a vivid reminder to me that Lysenkoism in computer science is still alive and thriving. Thos "professors" generally should be fired on the spot.

Also harmful is use of OO in the writing of utilities. I saw a lot of overly complex junk written by this method (to the level of being unmaintanable) and can attest that OO fails in this area. It is just not a suitable paradigm and thinking about construction of a utility in OO-fashion usually lead to poor results and bloated codebase. Often you can cut the size of codebase 50% or more but rewriting it the procedural fashion or using coroutines.

I think for this domain the paradigm of "defensive programming" and associated set of ideas are more useful.

OO fashion ( or "for profit" cult, if you wish ) movement vividly demonstrates that in modern science at least one third of scientists are money seeking charlatans, while the other one third are intellectual prostitutes (among Professors of Economics this proportion is significantly higher).

As such OO serves as an indirect proof of pretty sad observation that in modern science at least one third of scientists are money seeking charlatans, while the other one third are intellectual prostitutes (actually among Professors of economics this proportion is even higher). Conversion of previously decent, honest researcher into one of those two despicable categories is not only possible, but happens quite often. A lot of modern science is actually pseudoscience. Life in academia those days is very tough and often survival, not seeking the truth, becomes the highest priority. Like somebody said "Out of the crooked timber of humanity no straight thing was ever made".

Again, the proliferation of OO books devoted to description of algorithms is completely absurd. It is really intellectually bankrupt way to explain algorithms to students. And what is really terrifying in the fact that good, in-depth books such as Donald Knuth masterpiece The Art of Computer Programming exists since 1968. OO do not replace, but complements procedural programming, as not everything should be seen as an object contarary to what some hot-headed OO enthusiasts (priests of this new techno cult) suggest. Sometime we should call a spade a spade, not an object ;-).

Good design in not about following the latest hot fad, but about finding a unique set of tools and methods that make programming the particular task productive, or even possible. It requires programming talent, not some of language features. Kernighan & Plauger long ago noted this fact in their still relevant book The Elements of Programming Style:

Good design and programming is not learned by generalities, but by seeing how significant programs can be made clean, easy to read, easy to maintain and modify, human-engineered, efficient, and reliable, by the application of good and programming practices. Careful study and imitation of good designs and programs significantly improves development skills.

One should understand that OOP is an old hat and several OOP-based languages are 20 or more years old. Essentially we can look at Simula67 as the first OO manage. Which means that OO is more then 50 years old.

OOP attempts to decompose the world into objects and claims that everything is an object. Which was really natural approach in simulation. That's why OO concepts were born out of experience with simulation languages.

But saying that everything is an object not always (actually pretty rarely) provide an useful insight into the problem. Just think of sorting. Will it help to sort the file efficiently if you think that the records are objects. Most probably not. Things that have a state and change their state while receiving something that can be interpreted as messages are natural candidates to be represented as objects. In this case it is really powerful programming paradigm.

Here are some guidelines to help decide if an object-oriented approach is appropriate:

Does your code manipulate a data structure that corresponds to a real-world object (such as a window on the screen)? Is there a group of variables that you can group into structure processed by the some set of installation functions which can be interpreted as operations on this data structure? Is hierarchical structure of functions space is useful, or flat structure is adequate?

OOP emphases creation a set of classes as a universal method of decomposition of the problem. But in reality such a decomposition heavily depends on the set of data representation and algorithms that programmer knows and is comfortable with. That's why typical decomposition of the problem into classes by Unix programmer can be completely different (and often better) that decomposition of the same problem by Windows-only programmer.

The essence of programming are algorithms operating on data structures and the "programming culture" used in particular OS exerts heavy influence on the way programmers think. In no way OO by itself can help you come up with optimal storage structures and algorithms for solving the problem. Moreover OO introduced entirely new and quite obscure terminology with the purpose of mystifying some old useful mechanisms of program structuring:

The binding of procedures to a data a structure (called object). Procedures pointers to which are stored in the structure itself are now called methods. The ability to store a pointer to the procedure in record field was available in languages since the early 60s (PL/1).

(called object). Procedures pointers to which are stored in the structure itself are now called methods. The ability to store a pointer to the procedure in record field was available in languages since the early 60s (PL/1). Constructing a new data structure (called subclass) by adding new fields (extending) a given structure (the superclass). It's essentially a variation of like construct introduced in PL/1. The cosmetics here is to consider any structure as a new type and use type checking mechanism to prevent certain errors in manipulation of pointers to such structures. In addition the process of creating of a new instance (and its initialization) can be controlled with a hidden call to a special procedure called constructor.

Also while OO emphasize the concept of object (which can be abstracted as a coroutine with it own state) in reality many so called OO languages does not implement the concept of coroutine. As such their methods do not have a real state, they can't be suspended and resumed. In other words they are just new and slightly perverted way to use Algol-style procedures.

As for paradigm shift, OO can be compared to introduction of a local LAN instead of mainframe. That mean that we now have a bunch of small, autonomous PCs each with own CPU, communicating with each other via messages over the net. It takes somewhat pervert imagination to see a simple procedure call as a real message passing mechanism -- only threads communicate through real messages. So true object model is intrinsically connected with multithreading, yet this connection is not understood well. True message mechanism presuppose that object (autonomous PC with its own CPU) was active before receiving it (has initial state) and will be active after processing it (in a new state). To certain extent real OOP-style is a special case of concurrent programming but without any concurrency.

Pointers are a great programming concept. But as any powerful feature it is a dangerous feature. OO tries to hide it removing explicit pointers from the language by hiding them and assigning them a type within the concept on instantiation of a class. Instance of the class is essentially a typed pointer, pointing to the memory area occupied by particular structure.

At the same time removing pointers from the language as first class language elements (which they were since PL/1) is not without problems. It remove a lot of expressive power of the language. As Perl demonstrated quite convincingly presence of pointers even is scripting language framework is very beneficial. Generally the idea that you need to switch to OO framework in order to use typed pointers in retrospect looks problematic.

And the idea of run-time accesses to elements of symbol table is a very powerful one and can be extended far beyond the concept of typed pointes. For example PL/1 style onsubscriptrange exception can be implemented this way. Here again analogy with Unix filesystem is appropriate. One of the powerful concepts introduced by Unix filesystem is the concept of I-nodes -- descriptors for each file.

Now with modern hardware this idea of having a descriptor for each variable is the idea which time has come. It provides multiple benefits and allow to accomplish really elegant things. It is a dream of compiler writers (having complier symbol table available at run time) that has come true.

I see no real reason to remove pointers from a programming languages like most OO languages do, and think that it is impossible without diminishing the power and expressiveness of the language. Of course, you can argue that in OO languages "everything is a pointer." In a way yes, but it is designed to hide the concept not to illuminate it.

In modern languages pointer can and should be a first class language structure as it is now indirect -- pointing to the descriptor of the variable instead of actual memory area of the variable like in C (which is designed as system programming language, so this is must for this class of languages). That allows a lot of checking which prevent typical blunders with pointers. It is like converting ancient razor -- and very useful but a very dangerous tool into modern Gillette shaving razor form :-)

Of course, tricks possible in C with the redefinition of a particular structure (memory area) into another are more difficult, but they are still possible. At least some subclass of those.

Co-routines are a necessary element of OO framework. That's why they were present in Simula 67 -- the ancestor of C++ and grandmother of all modern OO languages. If we assume that object need to have its own state that automatically imply that each method should have its own state too, which they need to preserve from invocation to another.

That means that OO languages that does not support the concept of coroutines are cripples that are missing fundamental feature of the OO model and should not generally be viewed as "real" OO languages.

Implementation of exceptions without implementing methods as subroutines is always deficient. In essence the exception is nothing but stopped co-routine and that means that all regular methods in OO language that supports exception should be co-routines too and should allocate all variables on the heap.

An exception generally ruins stack and keeping all variables in the heap is just a necessity for a clean implementation.

Allocation all the variables on heap, which is necessary for proper implementation of exception (which break stack based procedure call model) generally presuppose garbage collection.

You can view exceptions as frozen coroutines which were initialized and instantly relinquished their control to the caller. Exception is just a reactivation of this coroutine. And if processing of exception allow to return to point of invocation of exception we have full co-routine mechanism in action.

In this sense OO languages that does not support garbage collection are cripples. This list includes C++.

Decomposition of program into modules/classes is an art. OO tend to stimulate more strictly hierarchical (aka bureaucratic) decomposition. This is not the only type of decomposition possible or desirable.

Sometimes much better way of decomposition in non-hierarchical decomposition when some frequently used operations are implemented outside hieratical structures as a shortcuts to typical sequences of operations.

It is true that premature optimization is the root of all evils, but complete neglect of this aspect is also not good.

Programs with "stupid OO-style decomposition" tend to have unnecessary deep procedure nesting hierarchies during execution which not that good for modern CPUs with multistage execution pipelines and predictive execution.

It also make maintenance of programs written by an OO zealot who try to enforce this paradigm in area which is not suitable for it a real nightmare. I encountered several cases when it was more economic to rewrite such procedures from scratch instead of maintaining the mess that organization inherited when such a developer left.

Actually one interesting feature of OO zealot is that are too preoccupied with the hierarchy of objects in their program to produce anything useful :-) All their energy and time goes into this typically fruitless area instead of trying to understand and solve the actual problem. That's why such a program typically are real junk. All efforts went into construction of elaborate and useless hierarchy of "universal" and "reusable" classes. Which will never be reused.

Actually "true OO" is very similar to the idea of compiler-compiler as it tried to create some kind of abstract language (in a form of hierarchy of classes) that can help to solve particular problem and hopefully (often this is a false expectation) is reusable to others similar problems. But I think that more explicit approach of creating such an abstract language and a real compiler from it into some other "target" language can work better then OO.

Moreover there is a great danger in thinking just in term of hierarchy of classes well known to people who designed compilers. There is a great temptation to switch attention from the solving of the problem to the designing of a "perfect" set of classes, instead of solving the actual problem. Making them more elegant, more generic, more flexible. You name it. This is an infinite and most often fruitless process. Often those refinement are not necessary for the particular problem and design became "art for the sake of art" -- completely detached from reality.

So the process of designing classes became self-perpetuating activity, disconnected with the task in hand (with usual justifications that this "universal" set of classes will help to design other problem later on the read, which never happens). The key point is that it became a very similar to addition and occupy lion share of developer time, which often dooms the problem he (or team) is trying to solve. I would call this effect OO class design addiction trap.

Moreover in a team of programmers there is often at least one member who psychologically is predisposed to this type of addiction (kind of and who instantly jump into opportunity disrupting the work of other members of the team with they constant desire to improve/change the set of classes used. Often such people as a wrong as they are fanatical and in the fanatical zeal they can do substantial damage to the team.

This "class design addiction trap" is very pronounced negative effect of OO, but people often try to hide it and never admit to it.

OO class-design addition trap has other side, which is well demonstrated itself in Java. People end with using so many class libraries that application slows down considerably and loading them at the beginning is a nuisance even of computers with SSD. Moreover subtle interactions between different versions introduce a very difficult to debug errors with each upgrade.

In other words usage of huge mass of Java class libraries increases complexity of a typical application program to the level when debugging becomes an art. And that often nullifies any savings on design and coding phases of program development.

Rat race for the generalization/abstraction of the functionality of each and every class is a district danger that exist in OO programming. In the absence of better term let's call it "Over-universalization" and understand it as a distinct tendency to consider the most generic case in designing class libraries. It is a problem of programming as an art and the way of solving it often distinguish a master programmer from an average in a sense that master programmer knows were to stop.

But OO tend to make it more pronounced. But again the problem is universal in programming and exist in designing regular procedural subroutines libraries, for example glib. See, for example History of development of Midnight Commander

This distinct tendency to make classes as abstract and as generic as possible makes them less suitable for the particular problem domain. If also increases the complexity of the design and maintenance. In other words it often backfires. In extreme cases the class library became so universal that it is not well applicable to any case where it can be useful and programmer start re-implementing those primitives again instead of using one from the class library. Such a paradox.

The same problem but to lesser extent happens with designers of libraries or modules for regular procedure languages or scripting languages that do not emphasize OO programming, such as Perl. You can definitely see it in cgi.pm .

The typical path of development reminds the proverb that the road to hell is paved with good intentions. I remember an example from my experience as a compiler writer. For example, initially the subroutine that output diagnostic messages to the screen and write them to the log is simple and useful. Then the second parameter is introduced and it became able to process and output message severity levels (terminal, server, error, warning, info, etc), then collection of statistics for all those levels is introduced, then it became able to expand macros, then to output context of the error, then ability to send messages above certain severity via SMTP is added, and then nobody is using it in the next project. Instead a simple subroutine that accepts a simple parameter (diagnostic message) is quickly written and the cycle of enhancements starts again with new players.

Programs rarely remain static, and invariably the original class structure becomes less useful with time. That results in more code being added as new classes, which undermines the conceptual integrity of the initial design and lead to "class hell": the number of classes grows to the level when nobody can see the whole picture and due to this start reinventing the bicycle.

Moreover often the amount of class libraries grow to the level when just loading them at startup consumes considerable time making Java look very slow despite significant progress on JVM side. It looks like Gossling in his attempt to fix some problems with C++ badly missed prototype-based programming ideas, the ideas that found its way into JavaScript. In a recent blog entry he even mentioned:

Over the years I've used and created a wide variety of scripting languages, and in general, I'm a big fan of them. When the project that Java came out of first started, I was originally planning to do a scripting language. But a number of forces pushed me away from that.

James Gosling, Dec 15, 2005

When custom class library is used, there is another danger. When is already designed and working, people often see better ways to do something. And this temptation of introduce changes is almost irresistible. If not probably regulated it became like building on shifting sand.

Class library mess that exists in Java and that makes Java so vulnerable to exploits suggests that there should be better paradigms on modularizing OO program then Simula-67 style class model. In this sense prototype oriented OO model probably deserves a second look.

One telling sign of a cult if unwillingness to discuss any alternatives. And true enough, the alternative methodologies are never discussed in OO books. As we are dealing with the techno-cult let's be realists and understand that as Niccolo Machiavelli observed

“And one should bear in mind that there is nothing more difficult to execute, nor more dubious of success, nor more dangerous to administer than to introduce a new order to things; for he who introduces it has all those who profit from the old order as his enemies; and he has only lukewarm allies in all those who might profit from the new. This lukewarmness partly stems from fear of their adversaries, who have the law on their side, and partly from the skepticism of men, who do not truly believe in new things unless they have personal experience in them.”

So it is often better to "dilute" or "subvert" OO development methodology then openly oppose it, especially if the company brass is hell bent on Java, Python or some other fancy OO language. Techno-cult adherents usually close ranks when they face a front attack. And as Paul Graham [The Hundred-Year Language] observed groupthink has one interesting property: "It is irresistible to large organizations."

That can be done in various creative ways so the discussion below provides just a few tips. All of them can be "squeezed" into compatibility with usage of some OO language (for example Python can be used instead of TCL in dual language programming methodology), despite that each of them subverts the idea of OO in some fundamental way.

As a programming methodology OO programming competes with several other:

Using scripting language such as TCL and compiled language such as C in a single project has a lot of promise as it better separates programming in the large (glue language), from programming in the small (component programming). See also Greenspun's Tenth Rule of Programming. Lua can be used instead of TCL. Julia is a new interesting alternative that can call C directly; no wrappers or special API.

In a way this is a simple implementation of abstract machine with, say, C subroutines and scripting language library representing machine operations and scripting language as a glue (TCL for C). For many problems this "scripting language+compiling language" approach is a better paradigm of software development as access to the implementation of interpreter by C programmers enforced development discipline already developed and established in scripting interpreter development community. And libraries used by interpreter usually are very high quality and serve both as an example of how things would be done and for preventing "reinventing the wheel" -- a tendency to re-implement parts of the library that are already implemented in any decent scripting interpreter. Programmers are usually learn by example and code of even simple interpreter like AWK or gawk is a great school. We can reformulate Greenspun 10th law of programming as following:

Any sufficiently complicated OO program written in Java, C++ or other OO language contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of scripting language interpreter.

As John Ousterhout aptly put it:

I think that Stallman's objections to Tcl may stem largely from one aspect of Tcl's design that he either doesn't understand or doesn't agree with. This is the proposition that you should use *two* languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions. For the Tcl scripts, ease of learning, ease of programming and ease of glue-ing are more important than performance or facilities for complex data structures and algorithms. I think these two programming environments are so different that it will be hard for a single language to work well in both. For example, you don't see many people using C (or even Lisp) as a command language, even though both of these languages work well for lower-level programming. Thus I designed Tcl to make it really easy to drop down into C or C++ when you come across tasks that make more sense in a lower-level language. This way Tcl doesn't have to solve all of the world's problems. Stallman appears to prefer an approach where a single language is used for everything, but I don't know of a successful instance of this approach. Even Emacs uses substantial amounts of C internally, no? I didn't design Tcl for building huge programs with 10's or 100's of thousands of lines of Tcl, and I've been pretty surprised that people have used it for huge programs. What's even more surprising to me is that in some cases the resulting applications appear to be manageable. This certainly isn't what I intended the language for, but the results haven't been as bad as I would have guessed.

This is approach is closely connected with the idea of structuring application as an abstract machine with well defined primitives (opcodes). If a full language is developed (which actually is not necessary) then this language does not need to produce object code. Compiling into a lower level language such as C, C++ or Java is a more viable approach.

In this case maintained of the application can be split into two distinct parts: maintenance of the higher level codebase and maintenance of the abstract machine that implements the higher level language and associated run time infrastructure.

The great advantage of this approach is that it allow to engage architects in actual programming which always lead to higher quality of final product: many primitives can be created from preexisting Unix utilities and programs and glued via shell language. See Real Insights into Architecture Come Only From Actual Programming

As the cost of programming is heaving dependent of the level of the language used, usage of the higher level language allow to dramatically lower the cost of the development. This approach also stimulates prototyping as often the first version of application can be glued from shell scripts and pre-existing Unix utilities and applications in a relatively short time which make the whole design process more manageable.

Even if the idea of defining the language will be thrown out later and another approach to development is adopted the positive effects of creating such a prototype can be felt for the rest of project development. In this sense "Operate of higher level" is not just an empty slogan.

Compilers stopped to be a "black art" in late 70th and this technology is greatly underutilized in modern software development. In this case you can catch some high level errors on syntactic level, which is impossible with OO although in many way it is similar "compiler-compiler" based methodology. In light-weight form the problem can be structures in compiler like form with distinct lexical analyzer, syntax analyzer and code generation parts. Multipass compiling with intermediate representation writable to disk is a great tool for solving complex problem and it naturally allow subsequent optimization converting read/write statements into coroutine interface. When intermediate representations between different passes are formally defined they also can be analyzed for correctness. Flexible switching between writing of intermediate files and coroutine linkage greatly simplifies debugging. XML can be used as a powerful intermediate representation language, although in many cases it is an overkill. Some derivative of SMTP message format is another commonly used representation.

This is a the newest methodology, often based on LAMP, where the whole virtual instance of OS become a part of application and application uses OS logging, OS scheduler, etc instead of reinventing the bicycle. This is a new a promising approach to programming substantial class of problems. This specialized virtual machine provides services via network interface, for example Web interface. LAMP stack which can be used in this approach proved to be a tremendously useful development paradigm. And in most cases non-OO languages are used in P part of this acronym. But Python and Ruby has well implement OO features, so this approach does not completely exclude usage of OO where is can really beneficial and not dictated by groupthink or fashion.

One important advantage of this approach is the executables in any OS are much more like objects that classes with methods in modern OO languages. They definitely have their state, can be interrupted and resumed and communicate with other executable via messages (which includes sockets). So OS infrastructure in general can be viewed as object oriented environment "in the large" while all OO languages belong to OO in the small.

In his paper Object Oriented Programming Oversold! B. Jacobs aptly noted:

OOP became popular primarily because of GUI interfaces. In fact, many non-programmers think that "Object" in OOP means a screen object such as a button, icon, or listbox. They often talk about drag-and-drop "objects". GUI's sold products. Anything associated with GUI's was sure to get market and sales brochure attention, regardless of whether this association was accurate or not. I have even seen salary surveys from respected survey companies that have a programming classification called "GUI/OOP Programming". Screen objects can correspond closely with OOP objects, making them allegedly easier to manipulate in a program. We do not disagree that OOP works fairly well for GUI's, but it is now being sold as the solve-all and be-all of programming. Some argue that OOP is still important even if not dealing directly with GUI's. In our opinion, much of the hype about OOP is faddish. OOP in itself does NOT allow programs to do things that they could not do before. OOP is more of a program organizational philosophy rather than a set of new external solutions or operations.

He also provided a deep insight that attractiveness of OO is somewhat similar to the attractiveness of the social doctrine like communism (with its ideas of central hierarchical planning model and idealistic hopes that that will eliminate wasteful, redundant procedures). Actually the idea that both OO and Marxism overemphasized classes is pretty cute :-). As well as the idea that full hierarchical decomposition is a close analogy to bureaucracy that is making organizations so dysfunctional:

Unfortunately, OOP and economic communism suffer similar problems. They both get bogged down in their own bureaucracy and have a difficult time dealing with change and outside influences which are not a part of the internal bureaucracy. For example, a process may be stuck in department X because it may be missing a piece of information that the next department, Y, or later departments may not even need. Department X may not know or care that the waiting piece of information is not needed by later departments. It simply has it's rules and regulations and follows them like a good little bureaucratic soldier.

This analogy can well look stretched, but highly placed "object oriented jerks" from academia really remind me high priests of Marxism-Leninism in at least in one aspect -- complete personal corruption.

In his old Usenix paper Objecting To Objects Stephen C. Johnson wrote

Object-oriented programming (OOP) is an ancient (25-year-old) technology, now being pushed as the answer to all the world's programming ills. While not denying that there are advantages to OOP, I argue that it is being oversold. In particular, OOP gives little support to GUI and network support, some of the biggest software problems we face today. It is difficult to constrain relationships between objects (something SmallTalk did better than C++). Fundamentally, object reuse has much more to do with the underlying models being supported than with the "objectness" of the programming language. Object-oriented languages tend to burn CPU cycles, both at compile and execution time, out of proportion to the benefits they provide . In summary, the goods things about OOP are often the information hiding and consistent underlying models which derive from clean thoughts, not linguistic clichés.

In his April 2003 Keynote for PyCon2003) Paul Graham suggested [The Hundred-Year Language] :

... Somehow the idea of reusability got attached to object-oriented programming in the 1980s, and no amount of evidence to the contrary seems to be able to shake it free. But although some object-oriented software is reusable, what makes it reusable is its bottom-upness, not its object-orientedness. Consider libraries: they're reusable because they're language, whether they're written in an object-oriented style or not. I don't predict the demise of object-oriented programming, by the way. Though I don't think it has much to offer good programmers, except in certain specialized domains, it is irresistible to large organizations. Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches. Large organizations always tend to develop software this way, and I expect this to be as true in a hundred years as it is today. ...One helpful trick here is to use the length of the program as an approximation for how much work it is to write. Not the length in characters, of course, but the length in distinct syntactic elements-- basically, the size of the parse tree. It may not be quite true that the shortest program is the least work to write, but it's close enough that you're better off aiming for the solid target of brevity than the fuzzy, nearby one of least work. Then the algorithm for language design becomes: look at a program and ask, is there any way to write this that's shorter?

Dr. Nikolai Bezroukov

Top Visited Your browser does not support iframes. Switchboard Latest Past week Past month

Object Oriented Programming (OOP) is currently being hyped as the best way to do everything from promoting code reuse to forming lasting relationships with persons of your preferred sexual orientation. This paper tries to demystify the benefits of OOP. We point out that, as with so many previous software engineering fads, the biggest gains in using OOP result from applying principles that are older than, and largely independent of, OOP. Moreover, many of the claimed benefits are either not true or true only by chance, while occasioning some high costs that are rarely discussed. Most seriously, all the hype is preventing progress in tackling problems that are both more important and harder: control of parallel and distributed applications, GUI design and implementation, fault tolerant and real-time programming. OOP has little to offer these areas. Fundamentally, you get good software by thinking about it, designing it well, implementing it carefully, and testing it intelligently, not by mindlessly using an expensive mechanical process. -- Abstract to Objecting to Objects, by Stephen C. Johnson,

Melismatic Software The road to Hell is paved with good intentions. -- Proverb

Sep 09, 2020 | medium.com The Reference Problem For efficiency sake, Objects are passed to functions NOT by their value but by reference. What that means is that functions will not pass the Object, but instead pass a reference or pointer to the Object. If an Object is passed by reference to an Object Constructor, the constructor can put that Object reference in a private variable which is protected by Encapsulation. But the passed Object is NOT safe! Why not? Because some other piece of code has a pointer to the Object, viz. the code that called the Constructor. It MUST have a reference to the Object otherwise it couldn't pass it to the Constructor? The Reference Solution The Constructor will have to Clone the passed in Object. And not a shallow clone but a deep clone, i.e. every object that is contained in the passed in Object and every object in those objects and so on and so on. So much for efficiency. And here's the kicker. Not all objects can be Cloned. Some have Operating System resources associated with them making cloning useless at best or at worst impossible. And EVERY single mainstream OO language has this problem. Goodbye, Encapsulation.

Highly recommended!

Dec 01, 2019 | turcopolier.typepad.com Academic Conformism is the road to "1984." The world is filled with conformism and groupthink. Most people do not wish to think for themselves. Thinking for oneself is dangerous, requires effort and often leads to rejection by the herd of one's peers. The profession of arms, the intelligence business, the civil service bureaucracy, the wondrous world of groups like the League of Women Voters, Rotary Club as well as the empire of the thinktanks are all rotten with this sickness, an illness which leads inevitably to stereotyped and unrealistic thinking, thinking that does not reflect reality. The worst locus of this mentally crippling phenomenon is the world of the academics. I have served on a number of boards that awarded Ph.D and post doctoral grants. I was on the Fulbright Fellowship federal board. I was on the HF Guggenheim program and executive boards for a long time. Those are two examples of my exposure to the individual and collective academic minds. As a class of people I find them unimpressive. The credentialing exercise in acquiring a doctorate is basically a nepotistic process of sucking up to elders and a crutch for ego support as well as an entrance ticket for various hierarchies, among them the world of the academy. The process of degree acquisition itself requires sponsorship by esteemed academics who recommend candidates who do not stray very far from the corpus of known work in whichever narrow field is involved. The endorsements from RESPECTED academics are often decisive in the award of grants. This process is continued throughout a career in academic research. PEER REVIEW is the sine qua non for acceptance of a "paper," invitation to career making conferences, or to the Holy of Holies, TENURE. This life experience forms and creates CONFORMISTS, people who instinctively boot-lick their fellows in a search for the "Good Doggy" moments that make up their lives. These people are for sale. Their price may not be money, but they are still for sale. They want to be accepted as members of their group. Dissent leads to expulsion or effective rejection from the group. This mentality renders doubtful any assertion that a large group of academics supports any stated conclusion. As a species academics will say or do anything to be included in their caste. This makes them inherently dangerous. They will support any party or parties, of any political inclination if that group has the money, and the potential or actual power to maintain the academics as a tribe. pl doug , 01 December 2019 at 01:01 PM Sir, That is the nature of tribes and humans are very tribal. At least most of them. Fortunately, there are outliers. I was recently reading "Political Tribes" which was written by a couple who are both law professors that examines this. Take global warming (aka the rebranded climate change). Good luck getting grants to do any skeptical research. This highly complex subject which posits human impact is a perfect example of tribal bias. My success in the private sector comes from consistent questioning what I wanted to be true to prevent suboptimal design decisions. I also instinctively dislike groups that have some idealized view of "What is to be done?" As Groucho said: "I refuse to join any club that would have me as a member" J , 01 December 2019 at 01:22 PM Reminds one of the Borg, doesn't it? The 'isms' had it, be it Nazism, Fascism, Communism, Totalitarianism, Elitism all demand conformity and adherence to group think. If one does not co-tow to whichever 'ism' is at play, those outside their group think are persecuted, ostracized, jailed, and executed all because they defy their conformity demands, and defy allegiance to them. One world, one religion, one government, one Borg. all lead down the same road to -- Orwell's 1984. Factotum , 01 December 2019 at 03:18 PM David Halberstam: The Best and the Brightest. (Reminder how the heck we got into Vietnam, when the best and the brightest were serving as presidential advisors.) Also good Halberstam re-read: The Powers that Be - when the conservative media controlled the levers of power; not the uber-liberal one we experience today.

Notable quotes:

"... In fact, OOP works well when your program needs to deal with relatively simple, real-world objects: the modeling follows naturally. If you are dealing with abstract concepts, or with highly complex real-world objects, then OOP may not be the best paradigm. ..."

"... In Java, for example, you can program imperatively, by using static methods. The problem is knowing when to break the rules ..."

"... I get tired of the purists who think that OO is the only possible answer. The world is not a nail. ..."

Nov 15, 2019 | developers.slashdot.org No, not really, don't think so. ( Score: 2 ) OOP has been a golden hammer ever since Java, but we've noticed the downsides quite a while ago. Ruby on rails was the convention over configuration darling child of the last decade and stopped a large piece of the circular abstraction craze that Java was/is. Every half-assed PHP toy project is kicking Javas ass on the web and it's because WordPress gets the job done, fast, despite having a DB model that was built by non-programmers on crack. Most critical processes are procedural, even today if only for the OOP has been a golden hammer ever since Java, but we've noticed the downsides quite a while ago. Ruby on rails was the convention over configuration darling child of the last decade and stopped a large piece of the circular abstraction craze that Java was/is. Every half-assed PHP toy project is kicking Javas ass on the web and it's because WordPress gets the job done, fast, despite having a DB model that was built by non-programmers on crack. bradley13 ( 1118935 ) , Monday July 22, 2019 @01:15AM ( #58963622 ) Homepage It depends... ( Score: 5 , Insightful) There are a lot of mediocre programmers who follow the principle "if you have a hammer, everything looks like a nail". They know OOP, so they think that every problem must be solved in an OOP way. In fact, OOP works well when your program needs to deal with relatively simple, real-world objects: the modeling follows naturally. If you are dealing with abstract concepts, or with highly complex real-world objects, then OOP may not be the best paradigm. In Java, for example, you can program imperatively, by using static methods. The problem is knowing when to break the rules. For example, I am working on a natural language system that is supposed to generate textual answers to user inquiries. What "object" am I supposed to create to do this task? An "Answer" object that generates itself? Yes, that would work, but an imperative, static "generate answer" method makes at least as much sense. There are different ways of thinking, different ways of modelling a problem. I get tired of the purists who think that OO is the only possible answer. The world is not a nail.

Nov 22, 2019 | stackoverflow.com Peter Mortensen, Mar 4 '17 at 22:00 If you want to refer to a global variable in a function, you can use the global keyword to declare which variables are global. You don't have to use it in all cases (as someone here incorrectly claims) - if the name referenced in an expression cannot be found in local scope or scopes in the functions in which this function is defined, it is looked up among global variables. However, if you assign to a new variable not declared as global in the function, it is implicitly declared as local, and it can overshadow any existing global variable with the same name. Also, global variables are useful, contrary to some OOP zealots who claim otherwise - especially for smaller scripts, where OOP is overkill. J S, Jan 8 '09 Absolutely re. zealots. Most Python users use it for scripting and create little functions to separate out small bits of code. – Paul Uszak Sep 22 at 22:57

Mar 02, 2007 | blog.codinghorror.com I'm not a fan of object orientation for the sake of object orientation. Often the proper OO way of doing things ends up being a productivity tax . Sure, objects are the backbone of any modern programming language, but sometimes I can't help feeling that slavish adherence to objects is making my life a lot more difficult . I've always found inheritance hierarchies to be brittle and unstable , and then there's the massive object-relational divide to contend with. OO seems to bring at least as many problems to the table as it solves. Perhaps Paul Graham summarized it best : Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work. Eric Lippert observed a similar occupational hazard among developers. It's something he calls object happiness . What I sometimes see when I interview people and review code is symptoms of a disease I call Object Happiness. Object Happy people feel the need to apply principles of OO design to small, trivial, throwaway projects. They invest lots of unnecessary time making pure virtual abstract base classes -- writing programs where IFoos talk to IBars but there is only one implementation of each interface! I suspect that early exposure to OO design principles divorced from any practical context that motivates those principles leads to object happiness. People come away as OO True Believers rather than OO pragmatists. I've seen so many problems caused by excessive, slavish adherence to OOP in production applications. Not that object oriented programming is inherently bad, mind you, but a little OOP goes a very long way . Adding objects to your code is like adding salt to a dish: use a little, and it's a savory seasoning; add too much and it utterly ruins the meal. Sometimes it's better to err on the side of simplicity, and I tend to favor the approach that results in less code, not more . Given my ambivalence about all things OO, I was amused when Jon Galloway forwarded me a link to Patrick Smacchia's web page . Patrick is a French software developer. Evidently the acronym for object oriented programming is spelled a little differently in French than it is in English: POO. That's exactly what I've imagined when I had to work on code that abused objects. But POO code can have another, more constructive, meaning. This blog author argues that OOP pales in importance to POO. Programming fOr Others , that is. The problem is that programmers are taught all about how to write OO code, and how doing so will improve the maintainability of their code. And by "taught", I don't just mean "taken a class or two". I mean: have pounded into head in school, spend years as a professional being mentored by senior OO "architects" and only then finally kind of understand how to use properly, some of the time. Most engineers wouldn't consider using a non-OO language, even if it had amazing features. The hype is that major. So what, then, about all that code programmers write before their 10 years OO apprenticeship is complete? Is it just doomed to suck? Of course not, as long as they apply other techniques than OO. These techniques are out there but aren't as widely discussed. The improvement [I propose] has little to do with any specific programming technique. It's more a matter of empathy; in this case, empathy for the programmer who might have to use your code. The author of this code actually thought through what kinds of mistakes another programmer might make, and strove to make the computer tell the programmer what they did wrong. In my experience the best code, like the best user interfaces, seems to magically anticipate what you want or need to do next. Yet it's discussed infrequently relative to OO. Maybe what's missing is a buzzword. So let's make one up, Programming fOr Others, or POO for short. The principles of object oriented programming are far more important than mindlessly, robotically instantiating objects everywhere: Information hiding and encapsulation

Simplicity

Re-use

Maintainability and empathy Stop worrying so much about the objects. Concentrate on satisfying the principles of object orientation rather than object-izing everything. And most of all, consider the poor sap who will have to read and support this code after you're done with it . That's why POO trumps OOP: programming as if people mattered will always be a more effective strategy than satisfying the architecture astronauts .

Nov 15, 2019 | www.quora.com Daniel Korenblum , works at Bayes Impact Updated May 25, 2015 There are many reasons why non-OOP languages and paradigms/practices are on the rise, contributing to the relative decline of OOP. First off, there are a few things about OOP that many people don't like, which makes them interested in learning and using other approaches. Below are some references from the OOP wiki article: Cardelli, Luca (1996). "Bad Engineering Properties of Object-Oriented Languages". ACM Comput. Surv. (ACM) 28 (4es): 150. doi:10.1145/242224.242415. ISSN 0360-0300. Retrieved 21 April 2010. Armstrong, Joe. In Coders at Work: Reflections on the Craft of Programming. Peter Seibel, ed. Codersatwork.com , Accessed 13 November 2009. Stepanov, Alexander. "STLport: An Interview with A. Stepanov". Retrieved 21 April 2010. Rich Hickey, JVM Languages Summit 2009 keynote, Are We There Yet? November 2009. (edited) taken from: Object-oriented programming Also see this post and discussion on hackernews: Object Oriented Programming is an expensive disaster which must end One of the comments therein linked a few other good wikipedia articles which also provide relevant discussion on increasingly-popular alternatives to OOP: Modularity and design-by-contract are better implemented by module systems ( Standard ML ) Encapsulation is better served by lexical scope ( http://en.wikipedia.org/wiki/Sco... ) Data is better modelled by algebraic datatypes ( Algebraic data type ) Type-checking is better performed structurally ( Structural type system ) Polymorphism is better handled by first-class functions ( First-class function ) and parametricity ( Parametric polymorphism )

Personally, I sometimes think that OOP is a bit like an antique car. Sure, it has a bigger engine and fins and lots of chrome etc., it's fun to drive around, and it does look pretty. It is good for some applications, all kidding aside. The real question is not whether it's useful or not, but for how many projects? When I'm done building an OOP application, it's like a large and elaborate structure. Changing the way objects are connected and organized can be hard, and the design choices of the past tend to become "frozen" or locked in place for all future times. Is this the best choice for every application? Probably not. If you want to drive 500-5000 miles a week in a car that you can fix yourself without special ordering any parts, it's probably better to go with a Honda or something more easily adaptable than an antique vehicle-with-fins. Finally, the best example is the growth of JavaScript as a language (officially called EcmaScript now?). Although JavaScript/EcmaScript (JS/ES) is not a pure functional programming language, it is much more "functional" than "OOP" in its design. JS/ES was the first mainstream language to promote the use of functional programming concepts such as higher-order functions, currying, and monads. The recent growth of the JS/ES open-source community has not only been impressive in its extent but also unexpected from the standpoint of many established programmers. This is partly evidenced by the overwhelming number of active repositories on Github using JavaScript/EcmaScript: Top Github Languages of 2014 (So far) Because JS/ES treats both functions and objects as structs/hashes, it encourages us to blur the line dividing them in our minds. This is a division that many other languages impose - "there are functions and there are objects/variables, and they are different". This seemingly minor (and often confusing) design choice enables a lot of flexibility and power. In part this seemingly tiny detail has enabled JS/ES to achieve its meteoric growth between 2005-2015. This partially explains the rise of JS/ES and the corresponding relative decline of OOP. OOP had become a "standard" or "fixed" way of doing things for a while, and there will probably always be a time and place for OOP. But as programmers we should avoid getting too stuck in one way of thinking / doing things, because different applications may require different approaches. Above and beyond the OOP-vs-non-OOP debate, one of our main goals as engineers should be custom-tailoring our designs by skillfully choosing the most appropriate programming paradigm(s) for each distinct type of application, in order to maximize the "bang for the buck" that our software provides. Although this is something most engineers can agree on, we still have a long way to go until we reach some sort of consensus about how best to teach and hone these skills. This is not only a challenge for us as programmers today, but also a huge opportunity for the next generation of educators to create better guidelines and best practices than the current OOP-centric pedagogical system. Here are a couple of good books that elaborates on these ideas and techniques in more detail. They are free-to-read online: https://leanpub.com/javascriptal... https://leanpub.com/javascript-s... Mike MacHenry , software engineer, improv comedian, maker Answered Feb 14, 2015 · Author has 286 answers and 513.7k answer views Because the phrase itself was over hyped to an extrodinary degree. Then as is common with over hyped things many other things took on that phrase as a name. Then people got confused and stopped calling what they are don't OOP. Yes I think OOP ( the phrase ) is on the decline because people are becoming more educated about the topic. It's like, artificial intelligence, now that I think about it. There aren't many people these days that say they do AI to anyone but the laymen. They would say they do machine learning or natural language processing or someth