I dunno man even just learning that Bjarne thought Simula's classes were cool specifically because of the domain of what he was working on—and learning that he ran into the same “unity build” problem that anyone who's worked on a large C++ project has encountered, years before literally anyone else in the world had—was fascinating, something I'd never heard before, and very interesting context in the broader scope of “OOP.”

> Whether it was made for that is immaterial

This is in the talk, he explicitly says that its often brought up that "OOP is made for large teams" "you're not using it as intended" "its not made to model your domain hierarchy" etc etc. The first 30 minutes is his reaction to that, disproving it.

Whether thats true or interesting is a different question, but its explicitly stated in the video, at the start, before he goes into the history.

> "OOP is made for large teams" "you're not using it as intended" "its not made to model your domain hierarchy"

Are there actual references for those quotes? Were they said by some kind-of expert or by a sales person or by cousin John?

Are they strawmen set-up to knock-down.

I highlighted "OOP is made for large teams", right clicked, clicked "Search Google for ..." and found the answer almost immediately. Give it a shot!

1) 'AI Overview "No, it's not strictly true that Object-Oriented Programming (OOP) is exclusively made for large teams, but it does offer significant advantages in such environments."'

2) 'Casey Muratori -- The Big OOPs: Anatomy of a Thirty-five'

Still no reliable reference.

You’ll get better results if you just search for “OOP large teams” rather than the specific phrase used in the video. You’ll get results like https://en.wikipedia.org/wiki/Object-oriented_programming#Po... that point to specific references such as https://www.paulgraham.com/noop.html which says:

    Object-oriented programming is popular in big companies, because
    it suits the way they write software. At big companies, software
    tends to be written by large (and frequently changing) teams of
    mediocre programmers. Object-oriented programming imposes a
    discipline on these programmers that prevents any one of them from
    doing too much damage.

He spends the first half of his presentation debunking the meme that OO was created for working with teams, not that it happens to be good for working with teams. Your quoted bit is not evidence of someone making the first claim, only the second.

> You’ll get better results if you just search for

That isn't what @bevyenjoyer told me to do. Moving goal posts.

That's why it's important for the OP to provide a reference, so from the beginning we are all talking about the same thing.

This is not moving the goal posts. Different people making the same claim may use different phrasing, and Google very much has recency bias. By searching for something slightly different we deprioritize the video we’ve already seen.

A primary source: https://www.youtube.com/watch?v=_ahvzDzKdB0

The only place "team" shows up in the transcript is here:

> So. Language design is not at all the same kind of work it was thirty years ago, or twenty years ago. Back then, you could set out to design a whole language and then build it by your own self, or with a small team, because it was small and because what you would then do with it was small.

Which is not about OO at all. Got an actual quote or is this link really just an interesting but irrelevant non sequitur?

EDIT: For those coming in later who don't feel like clicking random Youtube links, parent post is referencing Steele's talk "Growing a Language".

You know that thing people do where they say the same thing using different words? You’ll have to comprehend the words rather than merely pattern matching on a specific phrase.

In particular, note how he talks about growing the language by adding new things to it which are like the existing parts of the language. Contrast that with APL, where the existing parts of the language all had funny symbols, but new things added by the user needed alphanumeric names. In Java the language gives you a bunch of classes and interfaces and whatnot, and you extend the language by defining your own classes and interfaces. You don’t have to do this yourself, of course, since you can include libraries alongside your code. Those libraries can extend the language by defining new classes and interfaces.

As he says:

    43:54 Back then, you could set out to design a whole language and then
          build it by your own self, or with a small team, because it was small
          and because what you
    44:02 would then do with it was small. Now programs are big messes
          with many needs.
    44:07 A small language won’t do the job. If you design a big language
          all at once and then try to build it all at once, it will
    44:15 fail. You will end up late and some other small language will
          take your place.

It's a remarkable stretch to go from those words to "OO was created for working with teams." It is neither implicit nor explicit in the talk and I don't know why anyone would make the claim you are making.

EDIT: You seem to be conflating the two ideas still. OO being created for teams is a different claim than it being good for teams. At most, you could stretch Steele's talk to the second, but not to the first.

True, he doesn't come right out and say the words. But don’t lose sight of the context. This is the big Keynote speech at a conference called OOPSLA, or “Object-Oriented Programming, Systems, Languages & Applications”, in 1998. It is safe to say that the audience has heard of Java by now. They already know that the core language design choice made during the creation of Java was to make it object—oriented. Objets are everything and everywhere in Java. Even the simplest “Hello World” program in Java has to be written as a class with a a Main method.

This talk tells us why he and the others at Sun made that choice. He says right there that he wants Java to enable people to write large programs. He specifically contrasts it with the small languages and small programs of the past, the kind that were invariably written by individuals or small teams.

This is what he believes OOP is good for, and why researchers have been studying it for so long. He is reinforcing the belief of the attendees that OOP in general, and languages like Java specifically, are a panacea created for the explicit purpose of letting engineers work more efficiently together on large, complex systems.

We know from the historical record that early researchers did not have this belief. We know that many practitioners of the 90s and 2000s did. This talk may not be the genesis of that belief, but it is proximate to it.

The fault for this myth will almost certainly be marketing. The best place to look probably won't be something for those in the trenches, but more targeted at management types.

I've listen'd to just past:

24:50 -- "A lot of people talk about these things. They talk about those compile time hierarchies and all that sort-of stuff; and they say - like you know, here's the thing that you just don't understand, it's all about large teams …"

Is there some example that you can point me towards, where a lot of people are saying compile time hierarchies are all about large teams?

(I suppose Ada is an example of design for programming-in-the-large.)

Is that a source given during "The Big Oops: Anatomy of a Thirty-Five-Year Mistake"? Otherwise the author might reasonably say that isn't what they meant.

A lot of people have said a lot of things about OOP for decades. So looking at the context in which something was said is an ordinary sanity check.

It is not moving the goal posts.

It is moving goal posts.

Oh if only you watched the presentation, where he quotes Bjarne Stroustrup and Alan Kay xD

Here's one of the Alan Kay quotes —

"Unfortunately, inheritance — though an incredibly powerful technique — has turned out to be very difficult for novices (and even professionals) to deal with." Alan Kay, The Early History of Smalltalk, page 82

That's taken from a section which reflects on introducing programming to children in the summer of '73 —

In part, what we were seeing was the "hacker phenomenon", that for any given pursuit, a particular 5% of the population will jump into it naturally, while the 80% or so who can learn it in time do not find it natural.

… it is likely that this area is more like writing than we wanted it to be. Namely, for the "80%", it really has to be learned gradually over a period of years in order to build up the structures that need to be there for design and solution look-ahead.

    -

Here's how that Alan Kay quote is used in The Big OOPs —

13:47 -- It's because 10 years earlier, he was already saying he kind of soured on it. He's like, inheritance was like really powerful, but people just didn't know how to use it. Novices and experts apparently both couldn't use it, right. It was just uh you know, it's really good, but no one can figure out how to use it, I guess. Uh so that's a little bit weird.

   -

Not "kind-of-soured on it" one page later —

There were a variety of strong desires for a real inheritance mechanism from Adele and me, from Larry Tesler, who was working on desktop publishing, and from the grad students. page 83

   -

Not "kind-of-soured on it" but wanting a "comprehensive and clean multiple inheritance scheme" —

A word about inheritance. … By the time Smalltalk-76 came along, Dan Ingalls had come up with a scheme that was Simula-like in it's semantics but could be incrementally changed on the fly to be in accord with our goals of close interaction. I was not completely thrilled with it because it seemed that we needed a better theory about inheritance entirely (and still do). … But no comprehensive and clean multiple inheritance scheme appeared that was compelling enough to surmount Dan's original Simula-like design. page 84

Oh if only you watched you could share.

Seriously? Just open any trade rag from the last 40 or 50 years.

So it was a sales pitch? And we would have blindly believed the sales pitch because …?

(I asked for actual references for those quotes so we don't waste time with moving goal posts.)