Waaait, but I thought OOP was carefully crafted to "scale with big teams", and that's why it works so... ahem... "well". Turns out it was just memetic spillover from the creators' previous work?
And we absolutely needed 30-45 minutes to learn that that wasn't why it was created. The first part is a history of OOP languages to debunk something I'd never heard even claimed until I watched this video. The history was interesting, but also wrong in a few places. It was amusing to hear him talk about Arpanet being used in the 90s, though.
If I get bored with life I'll rewatch and take notes, that was the main one that made me chuckle and stuck with me. It was details around Lisp and a couple other things that were outside his explicit research scope (he specifically researched C++, Smalltalk, and Simula per his blog). Like claiming that everything in Lisp was based on lists (even in 1960 that wasn't true).
I'd just expect more from someone who takes 30+ minutes to debunk a claim that doesn't matter and most people have never heard to be more particular in getting details correct.
On the first part of the video, to be more constructive, it does not matter why a language or tool or whatever was made. The claim, that he debunks, is that OO languages were made to be good for working with teams. Whether it was made for that is immaterial, and no one needs 30 minutes of mostly historically correct video to get to The Truth(tm) of the matter. What's more interesting, and he never bothered to get into, is whether OO is actually good for working with teams (I can go either way, I've dealt with enough garbage OO programs to know that OO itself does not help things, but enough good OO programs to know that it can help things).
To anyone who has not yet watched the video, the second half is interesting, the first half is mostly a waste of time.
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.”
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.
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'
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.
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.
Muratori's statement (that he debunks in his talk): OO was created for teams.
Graham's statement: OO is useful for teams.
Those are distinct concepts, there's lots of evidence of statements like Graham's out there, and you've helpfully provided one. What igouy is asking for is evidence of the former claim.
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.
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.
"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
That feels like saying stealing food is a permissionless new way to get food. And I'm not at all convinced that the governments of the world could not regulate blockchains, or their use, if they wanted - either in ways like outlawing it, or auditing / regulating / taxing companies which use it, or pressuring insurance companies to put limits against insurance cover, or numerous other ways.
Yes, I agree, and this is all very cool, however regarding this point:
> There is now a sovereign nation state that accepted Bitcoin as a currency, and, mark my words, no doubt more will follow this 2022.
Sure. That's true, but doesn't actually matter, imo., because the point of crypto is to:
> Replac[e] central banks, and by extension, their grasp on the limitless money printing
So approval from the government in the case of crypto is worth about as much as it is for making love. It's the losing side of a game saying "You know what, we'll be so gracious as to allow you to win". Never needed your permission to begin with.
You’re referencing the point of Bitcoin, not the point of crypto. Other platforms aren’t interested in destroying the existing financial system and would much rather digitize it and make it open to everyone.
70-ish years. I'd say we just recently came out of the early days of computing around the 1990s or 2010s.
>How long do we need to wait before someone comes up with an actual application of blockchain technologies that isn’t a transparent attempt to retroactively justify a technology that is inefficient in every sense of the word?
Currency is inefficient? It's sure better than trading cows.
Smart contracts? Writing things using english and then every side involved hiring lawyers to be used as bad just-in-time compilers for what was written is way more inefficient.
"Bitcoin was the beginning of the end for the state" – geohot. And I can't imagine much more of an inefficient system than the state and central banking.
> How much pollution must we justify pumping into our atmosphere while we wait to get out of the “early days” of proof-of-work blockchains?
Energy production problem, not a blockchain problem.
> How many people must be scammed for all they’re worth while technologists talk about just beginning to think about building safeguards into their platforms?
God, devs, please don't put restrictions on your platforms under the guise of "safety". Same goes for governments. Stay out. If you have no clue how something works, it's partly on you if you gamble all your savings on it. But also, who is excusing scams? We all think scams are bad. Nobody is seeing someone who fell for BitConnect and saying "Well, it's the early days, so it's fine that you got scammed."
It seems to me that this lady really wants to dislike. In general. She enjoys disliking things.
> Currency is inefficient? It's sure better than trading cows.
Currency is a problem that's already solved much more efficiently in a lot of countries.
> Smart contracts? Writing things using english and then every side involved hiring lawyers to be used as bad just-in-time compilers for what was written is way more inefficient.
Writing a bulletproof smart contract is difficult, as demonstrated by endless exploits despite the contracts being written & reviewed by specialists paid lots of money.
The advantage of the legal system is that when shit hits the fan, humans (in court) can step in and determine what the intent of the contract was despite potential loopholes, whereas in code, there is no difference between "loophole" and "intended behavior". Now you can of course have an authority that has power over smart contracts and can step in and rollback exploits, but that's just the current legal system with extra steps, at which point you may as well not use a smart contract at all.
> And I can't imagine much more of an inefficient system than the state and central banking.
There are obviously edge-cases and cryptocurrency is valuable in those, but in the vast majority of the world banking is a solved problem and much more efficient than cryptocurrencies. Compare the total cost (fee + environmental impact due to energy use, etc) of a card transaction or bank transfer with a cryptocurrency transfer.
I'm not saying that cryptocurrencies are useless - there are use-cases for them including in countries where the established monetary system is broken. But outside of those edge-cases, cryptocurrency would be a very wasteful downgrade from the status-quo.
> Currency is inefficient? It's sure better than trading cows.
> Smart contracts? Writing things using english and then every side involved hiring lawyers to be used as bad just-in-time compilers for what was written is way more inefficient.
If crypto is doing these things really more efficiently than current solutions, then why neither use case has any significant adoption of blockchain solutions?
Every technological revolution is held back as long as possible by those making the most money using the current system.
London streets will be covered in 3 feet manure if industry progresses at this pace.
You’re crazy if you think this fool contraption you’ve been wasting your time on will ever displace the horse, there is no significant adoption.
Electricity is dangerous, there is no significant adoption, gas lamps and candles work fine.
Remove trollys since we can make more money selling tires, oil, and buses.
Internet is a fad, what use case is it solving, it burns a lump of coal every time a book is ordered, there is no significant adoption.
EV1 - we will take your electric cars and crush them, there is no significant adoption.
Proof of work guaranteeing that no one can alter history unless they spend more energy than the entire network has spent already to secure property rights has no use case and no significant adoption.
At this point either you see a pattern from history, or you remain perpetually on the wrong side of a Blub paradox.
