I haven't seen a better explanation about OOP till date than the one given by a guy who never had any formal engineering training, but always had clear idea about everything he did and preached, be it technology, design or art.

Here, in an excerpt from a 1994 Rolling Stone interview, Jobs explains what object-oriented programming is.

Jeff Goodell: Would you explain, in simple terms, exactly what object-oriented software is?

Steve Jobs: Objects are like people. They’re living, breathing things that have knowledge inside them about how to do things and have memory inside them so they can remember things. And rather than interacting with them at a very low level, you interact with them at a very high level of abstraction, like we’re doing right here.

Here’s an example: If I’m your laundry object, you can give me your dirty clothes and send me a message that says, “Can you get my clothes laundered, please.” I happen to know where the best laundry place in San Francisco is. And I speak English, and I have dollars in my pockets. So I go out and hail a taxicab and tell the driver to take me to this place in San Francisco. I go get your clothes laundered, I jump back in the cab, I get back here. I give you your clean clothes and say, “Here are your clean clothes.”

You have no idea how I did that. You have no knowledge of the laundry place. Maybe you speak French, and you can’t even hail a taxi. You can’t pay for one, you don’t have dollars in your pocket. Yet I knew how to do all of that. And you didn’t have to know any of it. All that complexity was hidden inside of me, and we were able to interact at a very high level of abstraction. That’s what objects are. They encapsulate complexity, and the interfaces to that complexity are high level.

I’ll start by saying that I don’t clearly understand the English as simply stated.

However, three things might help us (a) English was not Edsger’s native language (b) he was very proud of his skills in English (c) he delighted in coming up with snide remarks (one of his good friends was Bob Barton, who also liked to do this).

I read this as “programmers will never approach professional status” — and — “the programming occupation will never become extinct (too bad)”!

He desired the process of getting computers to “do what we mean!” to be rather like the mathematics he was used to when getting his PhD in mathematical physics. In his own words:

After having programmed for some three years, I had a discussion with A. van Wijngaarden, who was then my boss at the Mathematical Center in Amsterdam, a discussion for which I shall remain grateful to him as long as I live. The point was that I was supposed to study theoretical physics at the University of Leiden simultaneously, and as I found the two activities harder and harder to combine, I had to make up my mind, either to stop programming and become a real, respectable theoretical physicist, or to carry my study of physics to a formal completion only, with a minimum of effort, and to become....., yes what? A programmer? But was that a respectable profession? For after all, what was programming? Where was the sound body of knowledge that could support it as an intellectually respectable discipline? I remember quite vividly how I envied my hardware colleagues, who, when asked about their professional competence, could at least point out that they knew everything about vacuum tubes, amplifiers and the rest, whereas I felt that, when faced with that question, I would stand empty-handed.

He had “bitten the apple” and gotten hooked. And the dual attractions and repulsions of math on the one side and programming on the other stayed with him his whole life.

It was his pristineness towards the former that got him to disparage the latter — even though that was the path he also had taken …

Developers hating on stuff is almost universally a useless observation. Any programming concept, paradigm, language and what have you has those “haters”, who tend to be vocal but rarely reveal anything significant. Many developers hate pointers, many developers hate Python or JavaScript or Java or whatever, many developers hate hard tabs, many developers hate this or that or the other thing.

When you step away from the outpouring of emotion and see how software is actually developed around the globe, in industry and for research, in applications large and small, in embedded systems and server farms, with emphasis on usability or security or speed or readability or some combination thereof, by individuals for their own use and by thousands in collaboration – you find that various paradigms are used for various purposes, with more or less success and ease and fun, and the “hate” is largely a waste of time.

Of course, over years and decades, things shift about. Fashions come and go, languages come and go. Programming is a human endeavor, and this is how human endeavors work. Programming nowadays is practiced by many more people than, say, metalworking, so there’s more variety of opinion and more audible bitching among programmers than among blacksmiths. Many years ago it was the other way around.

Object-Oriented Programming is a fundamental concept of modern software development. In different contexts it may be highly suitable, optional, or irrelevant. That’s all.

In the beginning there was Bob. Bob wrote code in a “Stream of Consciousness” way (SOC). He would dump out code as he was thinking it and it was good… most of the time. There would be a bug and he would fix it.

Bob could handle 2 thousand line programs (2k LOC) with ease. With enough debugging time he could handle 4kLOC. But management saw the need for more complex apps.

Now there were two programmers. The problem was that Bob wrote SOC code, from Bob’s consciousness. The other programmer couldn’t figure out what the hell was going on.

Bob would write 1000 LOC, call a function which would eventually become 1000 lines as well. And so on. Pretty soon the developers were hitting 10KLOC but they couldn’t add another feature without a rewrite. Management was pissed.

This happened all over the country. It limited the size and complexity of applications running on computers. The hardware guys in the meantime doubled the ability of the computers every couple of years or so. Management was pissed.

Until someone said “Hey let’s break down this massive blob of code into a bunch of small, well defined functions.” Functional Decomposition was born. Func-D (cool name huh?) became the norm. When it was followed, the functions were small (single-purpose?), they were well-defined (had clear prrequisites and clear postconditions) and a clear name that was easy to figure out.

Developers went nuts. With Funky-D applications grew an order of magnitude. 100KLOC programs were in reach, team sizes grew and the complexity of the applications grew as well.

And there’s Bob. Bob wrote tons of smaller functions sure. But when we needed a new function, he just wrote it. There were a 1000 other functions so he didn’t check if the one he just wrote already existed. Bob caused weird bugs, e.g. a code fix in one function caused the bug to go away in some parts of the application but not all parts.

Until someone said “Hey let’s organize these functions into groups..” Modules were born. The idea is that you place a function within a module (aka namespace). Put functions that “belong together” into the same module. It organizes them and puts a nice name around it.

Some languages even implemented scope. Some functions could be called from outside the Module (public) while others could only be called from within it (private).

Developers went crazy. Complexity and the size of applications went up again. The damn hardware guys kept pushing the edge… and you know it, management was still pissed.

Bob worked on that. His programs had four modules: Main, Feature1, Feature2 and Generic. Main was huge. Feature1 and Feature2 were smaller but they had 10’s of exactly the same functions that Bob cut-n-paste into multiple modules. And then the dumping ground was Generic which was humongous. It had tons of functions again.

Someone said, “Let’s make a Module able to inherit from another Module” and some other language capabilities and thus OO was born.

Love it! Complexity and size grew again.

But Bob now had 4 classes Main, Feature1, Feature2 and Generic. Feature1 and Feature2 inherited from Generic. So now Feature1 and Feature2 were cleaner, but Generic was a dumping ground filled with crap.

Then someone came along and said “OO sucks! It’s the worst”.

Thanks Bob.

The problem with OO is that it is exactly the opposite of failure: it was immensely succesful (in contrast to the actual benefits it provides).

In the dark days of OO's height of success it was treated almost like a religion by both language designers and users.

People thought that the combination of inclusion polymorphism, inheritance, and data hiding was such a magical thing that it would solve fundamental problems in the "software crisis".

Crazier, people thought that these features would finally give us true reuse that would allow us to write everything only once, and then we'd never have to touch that code again. Today we know that "reuse" looks more like github than creating a subclass :)

There are many signs of that religion being in decline, but we're far away from it being over, with many schools and textbooks still teaching it as the natural way to go, the amount of programmers that learned to program this way, and more importantly, the amount of code and languages out there that follow its style.

Let me try and make this post more exciting and say something controversial: I feel that the religious adherence to OO is one of the most harmful things that has ever happened to computer science.

It is responsible for two huge problems (which are even worse when used in combination): over engineering and what I'll call "state oriented programming".

1) Over Engineering

What makes OO a tool that so easily leads to over engineering?
It is exactly those magical features mentioned above that are responsible, in particular the desire to write code once and then never touch it again. OO gives us an endless source of possible abstractions that we can add to existing code, for example:

• Wrapping: an interface is never perfect for every use, and providing a better interface is an enticing way to make code better. For example, a lot of classes out there are nothing more than a wrapper around the language's list/vector type, but are called a "Manager", "System", "Factory" etc. They duplicate most functionality (add/remove) while hiding others, making it specific to what type of objects are being managed. This seems good because it simplifies the interface.
• De-Hard-Coding: to enable the "write once" mentality, a class better be ready for every future use, meaning anything in both its interface and implementation that a future user might want to do differently should be accommodated for, by pulling things out into additional classes, interfaces, callbacks, factories.
• Objectifying: every single piece of data that can be touched by code must become an object. Can't have naked numbers or strings. Besides, naming these new classes creates meaning which seems like it makes them easier to deal with.
• Hiding & Modularizing: There is an inherent complexity in the dependency graph of each program in terms of its functionality. Ideally, modularizing code is a clustering algorithm over this graph, where the most sparse connections between clusters become module boundaries. In practice, the module boundaries are often in the wrong spot, produce additional dependencies themselves, but worst of all: they become less ideal over time as dependencies change. And since interfaces are even harder to change than implementation, they just stay put and deteriorate.

You can iteratively apply the above operations, and in most cases thus produce code of arbitrary complexity. Worse, because all code appears to be doing something and has a clear name and function, this extra complexity is often invisible. And programmers love creating it because it feels good to create what looks like the perfect abstraction for something, and to "clean up" whatever ugly interfaces it sits on top of some other programmer made.

Underneath all of this lies the fallacy of thinking that you can predict the future needs of your code, a promise that was popularized by OO, and has yet to die out.

Alternative ways of dealing with "the future", such as YAGNI, OAOO, and "Do the simplest thing that could possibly work" are simply not as attractive to programmers, since constant refactoring is hard, much like perfect clustering over time (for abstractions and modules) is hard. These are things that computers do well, but humans do not, since they are very "brute force" in their nature: they require "processing" the entire code base for maximum effectiveness.

Another fallacy this produces is that when over engineering inevitably causes problems (because, future), that those problems were caused by bad design up front, and next time, we're going to design even better (rather than less, or at least not for things you don't know yet).

2) "State Oriented Programming"

There's a famous quote: "There are only two hard things in Computer Science: cache invalidation and naming things". This is about the first of those two.

First a thought exercise: take a complex program that reads a file, like a compiler, or maybe a word-processor. By definition (before any further user input), all objects in that programs memory are derived from the contents of its input file. The reason why those objects exist at all is because if the program needs some kind of information (like the compiler asking "what is the type of variable a?"), for speed reasons, it needs to have cached this information. In theory, we could write a functions, such that every time any information was needed, it would re-scan the input file, and never store any objects at all. Slow, but possible, even for interactive software.

As programmers, we choose how much to cache, all the way from nothing to redundant amounts.

The problem with caching is the invalidation part: as data is derived from other data (which in turn is derived from other data, etc.), if the original data changes, so should all the derived data. Almost no programming languages do this for you automatically, meaning the programmer is in charge or writing code that detects when data has changed, how to recompute it, and to make sure all parts of the program "hear" about it, which is very error prone. Programs that would re-scan the source data every time are less buggy (don't ever get into an inconsistent state), and are easier for a programmer to change (dependencies are more explicit).

Ever wonder why so many problems with computers can be fixed simply by restarting/rebooting/re-running/re-generating/re-compiling? Welcome to cache invalidation.

This is a problem with almost every language, but OO exacerbates it by promoting copies of data (because, data hiding) and generally making it harder to track and update these data dependencies (because, many layers). Beyond that, thinking of your code as defined by "objects" makes you more likely to want to store everything, even in cases where data is transient, and could be defined much better as a sequence of transformations. You cannot add a field to an object just for a short amount of time, once you add it, you are now responsible for it to be valid for the lifetime of the object.

Is this some thin-veiled way of trying to promote everyone to rewrite their code base in Haskell or another pure functional language? No. First, Haskell doesn't even solve all these problems. But being aware that every time you "cache" something that this is a choice, and there may be an alternative way of structuring things that can make the cached data be more transient or simply be recomputed is one of the most important ways to reduce complexity in software. In most any language, you can structure code to be "as functional as possible", within practical limits.

I’ve not seen many actual developers do this. Not actual people who develop software for a living.

There has been a resurgence of the idea that it is not the only paradigm out there.

Functional programming, first seen in the 1950s, has had an uplift in languages that enable its use. Or at least parts of it.

This approach swaps out some trade-offs in OOP related to things like concurrency and program structure.

I think this has created a broader interest in how we design programs and what techniques are available.

That’s a good thing.

Actual hate on OOP - or other techniques - is a bit daft. You run the risk of missing a valuable tool for the tool belt.

It’s hard to praise too highly the programming languages that are the bridge from one way of looking at programming to much better ways of looking at programming. The two greatest such in the 60s were Lisp and Simula. Perhaps the greatest single conception of a software system of the 60s was Sketchpad.

As explained elsewhere on Quora, and in “The Early History of Smalltalk”, I had chance encounters with Sketchpad and Simula in my first week of grad school in late 66, that shocked me into a realization about “computers as basic and universal units” via the connections and parallels with other like things, such as biological structures, computers on networks, processes in time-sharing systems, general systems of parts intercommunicating, and so forth. I started to think about dynamic languages to make such processes, and how the processes could be made efficient and parsimonious enough to be universal.

Someone asked me what I was doing, and without thinking, I said “object-oriented programming”. (A very bad choice as it turned out, for many reasons.)

In the first years of the 70s at Xerox Parc with the great help of a terrific research group, and especially Dan Ingalls, we were gradually able to solve the software engineering problems to make this “systems approach” to programming practical (and especially on the emulation architecture hardware of Chuck Thacker). The starting place was how Lisp systems were built and made efficient.

This led to real power of expression, and a number of breakthroughs at every level, from the user interface to the metal.

This attracted great attention, and 10 years later in the 80s “object-oriented languages” started to appear. The only ones that had some of the same flavor as Smalltalk were several versions of Lisp. There were several “object Pascals”, even an “Object COBOL”!, and of course, C++.

It’s important to realize that C++ was part of a chain of ideas starting around 1979 by Bjarne Stroustrup who was also shocked into action from encountering Simula. He was not trying to “steal from Smalltalk” in any way. Here’s what he says in his history paper:

C++ was designed to provide Simula’s facilities for program organization together with C’s efficiency and flexibility for systems programming. … The goal was modest in that it did not involve innovation, and preposterous in both its time scale and its Draconian demands on efficiency and flexibility.

Elsewhere, he takes pains to say that he’s “not trying to do what Smalltalk at Xerox Parc did”. He was essentially trying to do with C what Simula did with Algol.

His approach was via “Abstract Data Types” (which the co-inventor of Simula — Dahl — also liked), and this is the way “classes” in C++ are generally used. And, similar to Simula being a preprocessor to Algol, C++ was a preprocessor to C: the “classes” were program code structuring conventions but didn’t show up as objects during runtime.

And for a variety of reasons, some of them not good, some reasonable, C++ got very popular.

It became part of the “colonization” of the term “object-oriented”. By the end of the 80s we could not explain the software at Parc as being “object-oriented” because the term had become co-opted. This kind of thing happens a lot in many areas. So it was understandable, and Bjarne certainly wasn’t to blame. The term became a kind of fad.

But it was — and is — quite annoying. I had to start calling the Parc stuff “real objects”, etc.

The push-back on complaints was the same one for pop changes in language usage and meaning i.e. “the people determine what a word or term means”.

But the -ideas- of OOP that worked so well for us at Parc came from many places, and we liked Goethe’s quote: “We should all share in the excitement of discovery without vain attempts to claim priority”. We did what we did, and we called it what we called it.

Hence the quote, which is not so much about C++ per se but about the term that we had been using to label a particular approach to program language and systems design.

—— Note: Quora tends to bury comments, so I’m copying an interesting one here along with my reply:

Abhinav Sharma: Thanks! I’m curious if you considered rebranding “real OOP” once the term had gotten colonized? I realize it must feel sad to have the term you coined get misconstrued but do you think a rebranding would be a good way for the ideas themselves to live on?

AK: I think the ideas are living on for historical purposes for those who are interested. And something can be learned about human nature by comparing implemented artifacts from the past with what got accepted and why.

On the other hand, the 70s idea of “real OOP” was hugely powerful back then, but what was implemented was far from a complete set of ideas, especially with regard to scaling, networking, etc. Dave Reed’s MIT thesis happened in 1978 and this dovetailed with ideas I thought important also, but funding and other circumstances delayed implementing his version of “real objects” until the early 2000s (this was Croquet).

How dynamic objects intertwined with ontologies and inference was explored by Goldstein and Bobrow at Parc. Their 4 papers on PIE and their implementation were the best extensions ever done to Smalltalk, and two of the ideas transcended the Smalltalk structure and deserved to be the start of a new language, and perhaps have a new term coined for it.

One way to look at this is that computers have enormous degrees of freedom and capacity, and this makes it very difficult to come up with great tools to program them. This is a mismatch with how humans learn and particularly with how we learn and do skill based activities. The latter tend to be very conservative, whereas the demand of computing is that we have to shed our skins every few years (and we don’t).

I don’t think that “real OOP” as we thought of it then, is the way to go in the future (and didn’t then). Consider Sketchpad, and that it is programmed in terms of constraints that the system solves to guarantee a very close fit between what was desired and what is manifested. This is an early glimpse into “requirements-based programming”. It has something like objects — hard to get away from the main idea — but is “relational” rather than message-based (the messages are implicit, etc.) Sketchpad was a tour de force in many ways, including its solvers. But they didn’t go far enough to handle general requirements. Today I think this is doable via a half dozen new techniques plus enormously larger machine capacities.

Stuff like this is what we should be working on!

No, by most measures it is a success. How would you determine whether a programming paradigm is successful? Obviously there are several ways:

1. Has it improve the maintainability of large software projects? Yes. I have the pleasure of seeing a very large code base 90% of which is in C on a daily basis. Had it been written in object oriented C++, it would be substantially more maintainable than it is. The principle problem with imperative, non-object-oriented programs is the proliferation of uncontrolled state - once the code base is large enough that no single person understands it, there are no guarantees that variables your code references will not change whenever you call any function. Object oriented style forces the containment of state in a way that makes it predictable when it will change.

2. Has it made programming easier? Yes. Beginners find it much easier to think about collections of objects evolving over time, since it allows us to apply intuition from the physical world that is usually correct. For experts, self-contained classes are much easier to reason about than uncontrolled gobs of state.

3. Is it widely used? Yes. Its very unusual to hear of a new project being started in a non-OO language, and its equally unusual for a new language to appear with no OO features. Go and Clojure are not normally thought of as object-oriented languages but both have significant object oriented features.

4. Has it encouraged software reuse? Yes, but not as much as it was claimed that it would. Writing code to an interface does encourage reuse within projects and for very general components such as collections libraries and GUI widgets. However, because each interface is essentially its own little private language, its impossible to exploit common patterns to reduce code in ways the original designer did not intend. In functional style, we can pass anonymous functions around to make use of data in unexpected ways. In object oriented style, we pass objects around and call their interfaces, but this is only possible if everyone already knows what the interface looks like.

5. Is it more expressive? No, not usually. Purely object oriented programs tend to be longer than their non-OO imperative equivalents, and much longer than their functional equivalents, because you need many little functions because your state is broken up into little objects, but you do not have the generally reusable abstractions that make functional programs so short. However, in some cases because OO interface polymorphism allows dispatch of functions by type, it can lead to more expressive code. This is especially true for graphics and for simulation where families of objects with different responses to common interfaces are a very natural way to work.

So that's about 3.7 out of a possible 5 points, which isn't bad. Critics of object oriented programming are usually referring to one of the last two points where OO is only marginally successful, but missing the important contributionts its make to maintainability, ease of use and the proliferation of better programming languages. It is definitely true that OO - especially Java and the OO dialect of C++ - have encouraged verbosity and discouraged the use of powerful, general abstractions in favour of very specific ones, but it is also true that the new generation of languages that has followed are still for the most part object oriented languages with more powerful features and fewer restrictions, not a return to Common Lisp, C and BASIC.

Dijkstra is a pretty smart guy, who has seen a lot. It is worth understanding what he thinks. I cannot claim any special knowledge of Dijkstra’s intent, however he has previously not been a huge fan of human ability.

I think he is saying that while software is eating the world, AI is eating the software employment world. The number of thoroughly professional software developers is not growing very fast, while a tsunami of semi-educated developers assisted by AI is attacking the job market like a zombie horde.

He may also be feeling that employers do not really desire professional developers because they expect too many things, like a salary, and to be treated with respect. Employers would prefer something more easily manipulated, a blue-collar kind of developer willing to work long hours for sociopathic managers on death-march projects at low wages. Or that could just be me :-).

I’ll take a different view.

Dijkstra has a specific goal in mind when discussing professional status. Specifically, to him, a professional is trained extensively to solve problems methodically. If you need a bridge from point A to point B, a professional civil engineer knows the complete set of design alternatives that the profession has worked out. He will evaluate each of those alternatives and rationally choose the best one for the situation. Another professional engineer, when confronted with the same problem, would come up with the same solution. No creativity. No art. No fuss. No bother. Just pure methodical workmanship.

Programming today is far from that. Give a problem to a dozen programmers, and you will not get back even two similar designs. They will be wholly unique.

Dijkstra wanted programming to be more than craftsmanship. He wanted it to be methodical. A discipline. He even wrote a book on it:

So what Dijkstra is lamenting is that programming is much more likely to become obsolete due to being taken over by AI than it becoming a true rigorous discipline as he envisioned it.

And I am forced to agree.

Footnotes

Computer scientists did not come up with object-oriented programming before procedural programming because humans don't normally start with the most sophisticated ideas first. Humans start with simple ideas and then work their way up to sophisticated ideas.

THE DEVELOPMENT OF HIGH-LEVEL PROGRAMMING LANGUAGES

Digital computers work by executing a long list of instructions one instruction at a time, but it can execute 1,000,000,000 instructions per second.

Computer programmers write algorithms consisting of long lists of instructions initially consisting of only 4 types of instructions arranged in various ways to accomplish something such as being a Word Processor.

#1 A typical modern digital computer has only 4 types of instructions:

1) It can move a number from one place to another place: memory locations and input/output.

2) It can perform simple computations such as adding and multiplying numbers.

3) It can do conditional jumps, and

4) It can execute subroutine calls and returns.

#2 Assembly language took the basics of digital computers and their instruction sets and put it into a mnemonic language that made it easier for programmers to code computer programs. However, assembly languages were unique to each digital computer.

#3 High-level language took assembly languages and created 4 abstractions that made programming even easier and allowed the same program to run on any digital computer that had a compiler created for it.

1) Variables and more complex data structures are a useful abstraction for the numbers stored in memory locations. These are the data in data processing.

2) Computational statements use variables that add, multiply, other computations and then store the result in another variable. These are called assignment statements which do all the computation in computer programs.

3) Flow control logic uses the conditional jump instruction to implement loops, if-then, do-while, and switch-case statements using the variables. These allow programmers to create the flow control logic of computer programs, and finally

4) Functions (subroutines) use the call – return instructions and the stack and take input variables and produce output variables and perform other useful work. Functions are the worker-bees of computer programs.

WHAT WAS WRONG WITH THE OLD HIGH-LEVEL LANGUAGES?

The old high-level languages had a fixed number of types of variables, although one could create an infinite number of types of functions. They also had no good way of organizing software, no good method of storing and re-using functions.

OBJECTS

To fix those 2 problems, the object (aka, class) was invented. Objects replace modules and are used by modern programmers as their universal organizing mechanism. Objects can also be used to define any type of data structure/variable which work as though they were native to the programming language. Programming with a high-level language that contains the object mechanism is called object-oriented programming.

RUNTIME ENVIRONMENT

The invention of the runtime environment which manages all objects in the computer’s library of objects and lies between the program and the operating system was the next great improvement in modern programming.

CONCLUSION

The above was the highly-simplified version of the development of modern high-level language leaving out the development of the modern operating system which is essential in modern programming. I enjoyed developing the real-time multi-tasking operating system in the mid-1970’s.

I also left out the development of functional programming for simplification purposes. You may have noticed that I also left out all mention of the programming paradigms. I did that because those paradigms are a viewpoint created after the development of modern programming. I find them to be nonsense, a figment of somebody’s imagination. But if other programmers find paradigms inspirational and useful, that is good. They don’t change the reality of modern programming because modern programming is what it is.

I hope my short essay helps you understand how modern computer programming evolved—which I personally witnessed decade after decade.

I’ve seen this. It falls under one of my favorite topics to write about, jerk programmers.

Most of the hate comes from Haskellers. Not from FP folks, but from Haskellers specifically. They insist that Haskell is wonderful (it is) and that it’s based on easy-to-grasp principles (it’s not) and that it solves every problem well (it doesn’t).

There are many poorly-designed, over- or under-engineered OO systems. This is partly because OO allows cruft to accumulate, but it’s more that OO is the dominant paradigm and has been for nearly 30 years.

OO is programming by metaphor. People get introduced to metaphor in middle school. FP is programming by abstract algebra. Most people, even most computer scientists (and certainly most developers) are never introduced to abstract algebra. That’s fine. The amount of advanced algebraic topics you must understand to fluently use Haskell is not large, but most people have none of the necessary background.

All software is “done” when time or budget (or both) run out. That’s the nature of professional development. Get used to bad code. If you can put together a long-lived, tightknit team of likeminded developers who are experts in your preferred tools/tech stack, you’ll make something you like. However, that’s not the reality of development.

A pretty long time ago I used to hate OOP because it’s typically taught mixed with the Object-Oriented Design. They need to be considered separately.

OOP is a way to control complexity. It lets you write the larger programs easier, faster and more reliably. The major reason for this is that it makes you think more carefully about the interfaces and limit the number of cross-dependencies. This carries some overhead, so the problem needs to be large enough to get the net benefit from it. That’s why the typical textbooks on OOP look so dumb: they try to show the use of OOP on the small examples that would be much better off without it. You can do OOP in the non-OOP languages too, but you would get even more overhead, the OOP languages condense a good deal of the overhead into the concise statements.

OOD basically says: now that we have OOP to control complexity, you don’t need to think about the design! Just make everything an object and connect them in every which way, and you’ll get a working program! In reality this doesn’t work. The books on OOD demonstrate their point with the small and extremely ugly examples that kind-of sort-of work. But once the scale of the problems goes up, the OOD generates complexity much faster than OOP can handle it. The “big pile of crap” non-design just doesn’t work.

So, the summary: OOP good, OOD bad, and you need to be able to tell them apart.

THe problems with OOP are:

1. It is incredibly distracting. It is very easy to end up in situation where you’ll be doing “illusory work”. For example, you can sink massive amount of time trying to come up with “perfect” (meaning “beautiful”) object hierarchy. Whil you’re busily splitting/merging classes, functionality of your project does not improve, you’re essentially wasting time while being fully convincing that you’re being useful.
2. There are people who treat it like religion. I’ve seen an article (discussing C# extension methods) saying, basically “I’ve found a way to write clean, maintainable and easy to read code, but it wasn’t OOP, so I concluded that it is evil and wrong”. This is just ridiculous.

With all that in mind…

OOP is a useful tool, when applied in the right place. However, you should not attempt to apply OOP to every single problem, it is entirely possible that an easire to read non-OOP solution may exist for a problem you’re dealing with. This is why there are programmers who recommend you to start with C - so you get acquianted with simpler approach first.

In the end, if you ever want to rely on some principle, I’d recommend to stick with KISS and YAGNI.

Basically.

1. A functionality should be only implemented when it is necessary. (YAGNI)
2. If it is not necessary, it should probably scrapped.(YAGNI)
3. Features you implement should be implemented in simplest most straightforward way (KISS).
4. With all that in mind, you should aim to keep the code easy to read, easy to maintain and free of bugs.

The logic behind that is that keeping things simple (KISS) and removing/not implementing unnecessary functionality (YAGNI) will reduce size/complexity of the project, thus reducing both maintenance cost and chance of getting new bugs.

There is no direct path from “Boolean Logic” hardware to the deep software of “Smalltalk.”

The concept of a “electric calculation” came from the writings of George Bool, call “Boolean Logic.”

From boolean logic came “adder circuits.” With a sequencer using a plug board or paper tape, the adder circuits could do complex calculations. The Harvard Mark I, a relay computer with paper tape and the faster Eniac, a vacuum tube calculator with plug boards.

The earliest computers did not have “message passing” or even subroutines.

From Turing’s papers from 1936, we get the “Universal Turing Machine” which leads to first “stored program computer.”

The Cambridge EDSAC is considered the first “stored program” computer which ran its first program in May 6, 1949. It had 512 words of 18 bits and 14 instructions. It didn’t even have a procedure call instruction.

No objects or message passing here or even a subroutine.

The first commercial computer, Univac I, was installed in 1951. Had had 1,000 words of 12 decimal digits (BCD) and a sign bit.

Lets skip a decade.

SIMULA is considered the first programming language with “objects”.

It appeared in 1962 and ran on a Univac 1107. It had 64K (65,536) 36-bit words. It did have a subroutine instruction called “Store location and Jump”. It put the return address at the destination address and then started executing at the next location.

Skip to 1968.

Alan Kay envisions “Dynabook”, “A personal computer for children of all ages.” From his experience with the B5500, a tagged architecture, stack based computer, he started building “Smalltalk”.

There is no direct path from “Boolean Logic” hardware to the deep software of “Smalltalk.”

Since the question has been asked, it’s worth reading the detailed history I was asked to write by the ACM in 1992, that became one of the sections of the 2nd History Of Programming Languages conference. The Early History Of Smalltalk

In brief for here, I saw parts of the idea in various forms starting in the early 60s, and thought it useful, but stayed asleep until in 1966 I saw Ivan Sutherland’s Sketchpad system (which completely changed the ways I looked at computing), and within a week saw and learned the first Simula, which was less grand than Sketchpad, but showed how ordinary programming could be changed to take advantage of instantiations of processes.

This double whammy combination “rotated” me to see things from very different perspectives.

A key part of the “rotation” was that

(1) at that time multi-processing and time-sharing systems were using hardware modified to isolate separate processes in the form of “virtual versions of the hardware”

(2) ARPA was in the process of talking about doing the ARPAnet, that would allow many computers to intercommunicate

(3) my two main concentrations in college had been pure math and molecular biology

The form of the “rotation” was ridiculously simple. It was the simple realization that a computer could compute what any computer could compute, and thus you could represent anything computable at any scale using only intercommunicating computers (most would be virtual) as building blocks.

This was completely impractical (which I think was one of the reasons I didn’t think of it earlier). The molecular biology and the ARPAnet really helped, because it was known in the mid-60s roughly that each cell in our body contained billions of informationally interacting components, and we had 10 to 100 trillion cells in each of us. That kind of scaling actually worked, and was far beyond what computing could do.

I think that seeing Sketchpad shocked me into being able to use “pure math mode” as part of the thinking rather than just the “worry about efficiency” thinking I was used to doing when computing. If you allowed “infinitely fast and large” computing, then the idea made excellent sense: it was a universal building block for all scales, and what remained were the central problems of designing complex systems.

The nature of the intercommunications would allow schemes that were like algebras in pure math to be devised so that terms — like “+” or “sort” or “display” could have both general and specific meanings.

The huge potential got me to look at the “impractical” part, which looked much more doable than I’d thought (it still took about 5+ years and a great research group to do). LISP had already solved a number of the problems, and this proved to be a great set of ideas for context.

In the 1960s, software composites that were more complex than arrays, were often called “objects”, and all the schemes I had seen involved structures that included attached procedures. A month or so after the “rotation” someone asked me what I was doing, and I foolishly said “object-oriented programming”.

The foolish part is that “object” is a very bad word for what I had in mind — it is too inert and feels too much like “data”. Simula called its instances “processes” and that is better.

“Process-oriented programming” would have been much better, don’t you think?

In any case, I did not at all have “Abstract Data Types” in mind as a worthwhile goal, even though they were obvious — and this is because “Data” as an idea does not scale at all well.

You are much better off hiding how state is handled inside a “process”, only having processes, and treating processes as “servers” for each other.

That is what I had in mind back then.

As language for teaching computer science, Haskell has a lot to offer that Java does not. It is a declarative language and takes an approach to programming that is much closer to mathematics. In Haskell, you define what things are in relation to their arguments, whereas imperative languages like java, you describe processes.

Describing a process can be more practical for some tasks, but declarative programming forces you to program in a way that is easier to reason about because values are calculated based solely on inputs, not on state. Provability, while not needed for every programming task, is something students need to learn. It’s very important for software that is not allowed to fail ever.

Haskell teaches the discipline of stateless programming, and that’s a really, really good thing for students to learn. It also teaches about category theory, which helps.

Basically, Haskell was created by academics as a pure way to express many of the foundational principles behind CS.

Java, by contrast, was created by a company to give programmers and easy, familiar-feeling way to do cross-platform development.

It’s not surprising that one would be better for teaching CS, while another would be preferred by businesses that want a language where programmers can be treated as interchangeable parts.

OOP, in most languages, introduces information hiding. This is an advantage because it lets you focus on one thing at a time instead of trying to walk through the control flow. Most of the time, if you are trying to track control flow, then you are trying to do the wrong thing. You should worry about the state and behavior of the objects so that there is no need to track control flow. It takes practice to get used to this, but you should give it a try.

Of course for every rule there is an exception. When writing device drivers and other low level code that deals directly with hardware, there is often a temptation to track control flow. That is probably one reason why people (such as Linus Torvalds) prefer C and do not like OOP. But I have found that, even in such low level code, I prefer OOP as it makes the code easier to maintain.

It’s very difficult to do sufficient justice to Edsger. Besides being a foundational computer scientist — in the original strict senses of the term — he was also one of just a few critical gadflies for our whole field, and especially both CS and SE.

One way to think about a great person is that they are “great and interesting” whether they are right or wrong, or in between. This is because it is their unique perspectives that really count: they help us see from directions we couldn’t.

Those whose tiny sense of self and outlook allow themselves to be insulted by the great gadflies completely miss what “great” and “gadfly” and “progress” are all about.

One of the difficulties in dealing with the ideas of a great person is to be distracted by some of the “really good stuff” they are able to accomplish — which tends to be more rooted in an historical time — and to miss the “really great stuff” they are advocating — which tends to be for much larger durations.

In other words, the bug is to mistake the artifact for the bigger underlying idea. This has happened with a number of greats, including Dijkstra, Bob Barton, Ivan Sutherland, Doug Engelbart, etc.

One of Edsger’s greatest lifelong interests was to find out how to design and write programs that really worked and were “bugfree” — including “knowingly and meaningfully” bugfree.

Following the idea that a programmer *should* have enough of a goal in mind to both try to write a program to do something, *and* to be able to tell if it works as intended, what he wanted was to find ways to *get the goal out of the programmer’s mind and into the code*.

Most goals are predications, and computers present the twin problems of *representing* predications and *running* them. The systems that could do this really well — like Sketchpad — though incredible for any time — were not general purpose enough to do either comprehensibly enough.

So the question is “how can you organize — and confine — what the computer does do to approximate “runnable math”. The vast degrees of freedom of computing are fabulously powerful: how to be able to use as many as possible really safely?

Edsger came up with numerous approaches to this, many of them important. With reference to the question here, he was not looking for a religion or for “golden methods” (this was more the way Wirth thought about this).

You can learn a lot about the way he did think about things by looking at his extremely early Algol 60 compiler, followed by his approach to the THE operating system for the EL X8 computer.

One of the big ideas of the 40s — especially 50s — is that the notion of a mathematical function could be imitated very well, if done with care, and — even better — that the idea could be widened to provide a machine independent abstraction for an idea, and especially for programs that could accomplish goals. This created ways to create a design language and scheme with separated concerns for design, but provided ways to combine the concerns in higher level more goal oriented ways.

This quickly gave rise to several different kinds of programming cultures: one pretty ad hoc, and one “like Dijkstra’s” i.e. an attempt to be as “scientific” and “engineering” as possible with respect to design and building.

The “like Dijkstra” one had the disadvantage of not knowing how to “do everything right” but it did have many starts to deep and correct criticisms of the other culture — which pretty much did everything “wrong” and were so blinded by pragmatism they couldn’t see it.

I think these two extreme cultures are very prevalent today, and both are quite entrenched — from many reasons besides personality leanings — I think there is a lot of the “loss aversion” and “sunk cost fallacies” hurting progress on both sides as well.

A way to end this too long answer is to look at Edsger’s quip that “programming is logical brinksmanship”, and realize that the largest psychological difference between the two factions is that his strict computing and engineering approach wanted to avoid brinksmanship via more care and art. The term “structured programming” as used by him was larger than what it degenerated into.

A companion quote from his contemporary Tony Hoare is: “Debugging is harder than programming, so don’t use all of your cleverness writing the program!” It’s a reasonable generalization to say that many of the computer scientists, software engineers, language designers back then were trying to find way to write programs that could be reasonably debugged. It’s also fair to say that most programmers today code expecting their program to run and be easily debugged (this doesn’t work well).

Another quote along these lines of Edsger’s that is quite telling 60 years later today is:

At least in Holland, the intellectual level needed for systems design is in general grossly underestimated. I am more than ever convinced that this type of work is *just difficult*, and that any effort to do it with other than the best people is doomed to either failure or moderate success at enormous expenses.

All the best systems designers I’ve known over the years have put a lot of effort into *confinement* — and have come up with numerous mechanisms both hardware and software — some of which are completely critical today.

By in large, most programmers violate useful and needed confinements right and left regardless of the tools they have (some of which can really confine well). Or what is done is via extreme kludgery (naming 5 of these right now will help understanding of this note)

The HW vendors especially recently have done very poorly dealing with and helping these issues.

And — it would be great to have those who do realize the importance of confinements to devise much better tools that fit the needs and scalings of our time.

This is already much too long, but I can’t resist telling “The Sphere Story”. One of the lab managers for a few years at Parc was quite a character. He had been the Chief Scientist at a large company, and while there decided that he would like a stainless steel sphere on his desk for a paper weight. He ordered a 4″ one from the shop and eventually forgot about it. 10 months later it showed up with an invoice for $10,000 (about $85K today). After screaming at them on the phone they informed him that he only said “4 inch diameter” with no tolerances, so ….

One of the many reasons that Sketchpad worked so well is that Ivan Sutherland was an engineer’s engineer, and engineers work to tolerances. He decided to make Sketchpad worth within reasonable tolerances e.g. minimizing the least square error fits of the multiple constraints. This allowed very difficult non-linear multidimensional problems to be handled right off the bat.

Compare this with the desire of mathematicians to have “not-true” mean “false” (disclosure: I have a degree in pure math). I remember being shocked by many things in Sketchpad — and this was one of them!

And compare this with the amount of “noise-limiting and correction” in almost all other parts of computing. If you are “thinking system” you are going to have noise and will design the system to work in spite of the different kinds of noise present (including human beings!). It’s that a very different kind of mathematical thinking has to be done besides “A is not not A”.

Note that this doesn’t invalidate Edsger’s large goals, but it shows how poorly the early conceptions of programming have scaled. This non-system view is present in most programming languages in heavy use today, and just doesn’t match up to what is actually needed.