Object Oriented Programming is not what I thought - Talk by Anjana Vakil
Vložit
- čas přidán 4. 11. 2020
- This talk is a historical & philosophical journey deep into the heart of darkness, er, object-oriented programming (OOP). Join me as I have my world shaken by the discovery that objects & classes aren't OOP's most important concepts: messages & late binding are. We'll try to peek inside the heads of Alan Kay & other OOP founders as they created languages like Smalltalk, and find that those "old" ideas seem strikingly relevant today. Our jaws may drop as we realize that OOP & functional programming aren't as different as we may have thought and that the 1st OO language wasn't created in the 60's or 70's, but much, much earlier… What awaits us at the end of this journey? At worst, we'll undergo a brief crisis of faith in everything we ever thought we knew about programming. (A support group will meet after the conference.) At best, we'll shift the way we view this near-ubiquitous but oft-misunderstood paradigm, and walk away with new insights for how we architect & understand our code.
Presenter: Anjana Vakil
Event: Øredev Conference
main content starts from 6:47
Thank you
Dude you're a god or somethin
thank you!!
Was 90 seconds in and about to leave before I saw this comment
I was about to say at the 14 minutes mark, and goes for a minute or 2
I actually enjoyed this talk. Not that I learn something new but because this talks isn't really about knowing. It's about MAKING SENSE and some people like me who refuse to implement something if they don't get the real essence of a concept or idea, this really helps a lot. Thanks!
me too! This analogy with biology helped me to see the things in another way. It makes more sense than plato theory, and others that ussualy are used to explain OOP.
Smalltalk is the ideal way to learn and understand object-oriented programming because of its OOP purity and OOP consistency. Smalltalk is OOP distilled to its basic essence. That's why it is so simple.
Smalltalk is message passing. Smalltalk is late binding. Smalltalk doesn't obfuscate OOP with nonsense such as "access modifiers" and multiple inheritance and other extraneous stuff.
Alan Kay famously said, "Actually, I made up the term object-oriented, and I can tell you I did not have C++ in mind." (At OOPSLA 1997.)
Yes, "Code With Huw" has actually started a series about the original ideas of OOP. He's using the Digitalk SmallTalk V manual from the 80's, the one Alan Kay recommended, and translating it to Squeak for the modern audience. Cool stuff!
I started Learning programming at the age of 22 and my first programming language was small talk and a year later C++. lol
It is also useless. ;-)
@@lepidoptera9337 no, it's quite useful.
@@Gnaritas42 Dude, if you want attention, then just say so. ;-)
I really enjoyed your talk, thanks a lot.
10:14 OOPS #1 biological metaphors
13:20 OOPS #2 big ideas
20:40 OOPS #3 beings vs behaviors
26:20 OOPS #4 boundaries
33:19 OOPS #5 belief structures
You can tell that her brain never got over the philosophy and English major stage. ;-)
OOP is about messaging between objects where the internals are hidden and unaccessable/callable/executable in any way except by the object itself on its own terms where no two objects share memory or data. Java dictated us what OOP is, but they had no idea and ruined the whole discussion and started an eternal confusion.
Messaging is an implementation detail that has nothing to do with the object concept. Everything that can be done with messaging can be done faster, easier and better with function calls. The only valid reason for messaging is the use case of distributed systems (spatial or temporal). On a single CPU that is running one copy of the code messaging is a foolish concept.
@@lepidoptera9337 that might be true but I don’t use FP so messaging is the way to go for me. It does make the code clearer too. And I might make microservices from it one day anyway. And it is the only way to make objects communicate in an uncoupled way… in my example it is angular services that communicate via messaging (events). If I don’t do it that way I get a circular dependency. But you are welcome to suggest a better solution for this particular problem. And don’t say FP. I don’t have the time to learn FP now. The project needs to be finished in 6 months.
@@paulholsters7932 Nobody can stop you from doing idiotic things that you don't understand. That messages can't lead to circular dependencies is plain false. Messaging has nothing to do with the dependency problem to begin with. If you don't know how to avoid such situations, then you are simply not an experienced programmer and the problem is caused by you in the first place. If you are planning to use microservices one day, then you better design for them from day one. That's just architecture for dumies.
FP doesn't exist. I don't know why you would even think that I am talking about FP. Is it because all you know about design patterns and paradigms is these two acronyms? OOP and FP? Is that it? In that case you need to take a CS 101 class SAP.
@@lepidoptera9337 No messaging allows more flexibility as the object can store the message, pass the message out, replace parts of the message, add parts to the message, etc... Messaging is just late bound function calls if you understand LISP quote then a message is a quoted version of a function call, and the overhead can be removed via a just in time(dynamic compiler) perhaps. Single CPUs are a bad idea, so is splitting RAM & CPU, both RAM & CPU are made of silicon a lot of your computer is idle where if you merged RAM & CPU into some sort of a celluar-automata type thingy you can have a lot of processes/objects everywhere.
I didn’t really learn anything new from this talk, but it still doesn’t feel like I’ve wasted my time. It was really enjoyable.
Thank you for sharing!!!
Thank you for this talk, Anjana.
Objects aren't verbs, they are nouns. Methods are verbs. Attributes are adverbs and adjectives. class car has attribute color and does things with imperative call to verbs/methods. All these analogies are imperfect, but I think mine makes sense. Her function is a verb, to find out who the friends are. Functional and OO are orthogonal. An OO design could be implemented with or without state/local variables. I think the idea of looking at programming as linguistic is the right way (as opposed to as a particular kind of math equation). Pub/sub is another thing, and callbacks as message is equivalent to subroutine calls. All programming paradigms are restrictive, that's the point. Functional - no local variables, structured, no goto, OO everything is related to a an object. All programs are OO, otherwise just a disorganized mess.
you should create a video about this. It sounds interesting.
@@leaoaugusto Yes and a song, animation. In the style of SchoolHouse Rock.
I can understand that Mr. Alan Kay regrets coining the term "object" and what she means when discussing verbs vs nouns, but I think at this point OOP is not what they want it to be. What they want should be called a different name: microservices? Message Oriented Programming?
I hate when people try to redefine a well established concept just because they had an epiphany about a better way to do things; even if the original intention was different (Mr. Alan Kay's original plan for OOP) the fact is, OOP is OBJECT oriented programming not MESSAGE oriented programming. In JAVA I create objects, not verbs... I don't pass messages; message is not even a primitive or reserved word in most OOP languages. And there is a perfectly valid use for OOP for many, many tasks... not every problem has to be solved with the same tool (or paradigm). When can solve problems with a "cell -message oriented" paradigm, but we still have lots of problems worth solving with OOP, as most people understand it, there's no need to redefine the concept in such a contrived way as to make OOP "not really about objects". Coin a different term and use that style of programming when it is appropriate.
When you look at it that way it makes so much sense. Just like how every sentence has a noun and verb, every statement has an Object and a function / method
SQL is my first language but I'm branching out and I've recently started learning Python. I've been searching for a way to understand OOP and it was starting to feel like the first rule of OOP is that nobody talks about OOP. Or maybe, if you think you understand OOP, you don't understand OOP. This talk has helped me so much to grasp the basic concept. Also, I love how you speak with such clear passion for your subject. Thank you!
Abstraction, Inheritance, Encapsulation, Polymorphism. Am I on the right path? :D
Alan Kay had two metaphors for OOP. One was biological cells, yes, but the other was the Internet. Kay saw Smalltalk as a "software internet" where objects are "virtual computers." Both metaphors are based on the *message passing* paradigm.
Are there any articles or videos that analyze in depth Erlang versus how Smaltalk does things today?
Metaphors are for idiots and that is simply not where OOP came from. OOP came from resource optimization on machines with small memory footprints.
@@lepidoptera9337can you expound more on that?
@@lepidoptera9337 Dude, if you want attention, then just say so. ;-)
@@TheCidraque That's my line, kid. Please learn the history of CS properly. At best classes are telling the compiler when to reuse functions. They are also completely unnecessary and the compiler strips all of that information from your code completely. Your CPU never gets to hear about your classes and objects. In effect OOP is, for the most part, a (pretty poor) program documentation technique. ;-)
I was hating oop, and now I hate oop, my cells and organs.
Cancer must destroy the cells. I.e OOP
Well, the message passing between your cells and organs are OOPing the f out... for sure.
😂😂😂
Object-oriented programming and functional programming have always been two sides of the same coin. Functional programming isn't actually stateless. There is state in the data that is being transformed in the computational pipeline. The key difference between these two programming paradigms is *encapsulation* - it's an organizational principle.
That is not so. Functional programming is stateless, but what people are doing in practice is not functional programming. There is, technically, no such thing as functional programming. In computer science the pure function paradigm was invented as a mathematical proving technique and it has turned out to be extremely useful. What we are doing when we are programming, however, is not the same as theorem proving. The overwhelming use of computers is as sources of complex side effects and that is, of course, not stateless (because we want the computer to change the state of the environment). Encapsulation is a documentation technique. It has absolutely no consequences on the actual code execution level.
@@TapetBart When was the last time you got paid by an employer to prove a theorem? ;-)
One can not program without side effect. That's physically impossible. At the very least your computer consumes power. Even the most trivial "useful" program like "Hello World" changes its environment by producing output. You simply don't know what you are talking about. ;-)
@@noobdernoobder6707 There are no stateless programs. At most there are functional programs that keep a (now useless!) copy of the original data in place, only to delete it later. The only relevant side effect of that is that it wastes memory. Everything else is completely identical to a program that does not keep that copy. Are any of you guys even THINKING about what it is that you are doing? I don't think so. Most people seem to treat "computer science" as a tribal sport these days. ;-)
I have no idea how this is supposed to impact parallelism. Keeping multiple copies of data of which only one copy is valid at any given time during the execution of a program has nothing to do with parallelism. It doesn't solve any of the hard problems of parallelism, like dependencies, runs, locks etc.. Nothing does. That's why smart people avoid parallelism like hell. Take it from me... I have spent years of my life with programmable hardware, where every single operation is parallel with every other operation. If you think that's "fun", then welcome to a special kind of hell for software engineers who just don't know better. ;-)
This is wrong.
@@virus3103 Almost every bullshit that random people are dropping on the internet is wrong. What are you going to do about it? ;-)
I googled "Good examples of classes for teaching OOP".
It landed me here. Something is really wrong with OOP when I need to search for it. No natural choices :-/
Everybody uses either some bunch of animals or strange classification of persons, in order to show inheritance etc.
Both these use cases are an entirely artificial construct. Perhaps this is the biggest secret of OOP? You may use your classes, or use someone's libraries, but the usefulness is just the concrete one?
Btw. when objects of two classes mutually exchange the information, it is often quite arbitrary to which class you allocate the method.
That's because there are hardly any good use cases for OOP in reality. Static GUIs work well, but then... who gives a shit about what happened on the Amiga 30 odd yeas ago? It's 2023, for heaven's sake. I do agree with your last sentence... until a requirement changes and it becomes important to have the method in one particular class (and the sandwich always lands on the buttered side)... and then the great refactoring begins.
Thank you so much.
I always have a great time listening to Anjana Vakil
Never knew Alan Kay was a Biologist... That explains so much!
It's funny at 26:00 where she's blurring the lines between OOP and FP and (basically) writing JavaScript in Python. ;)
Another excellent talk from Anjana Vakil.... I love her philosophical / linguistic take on things.
If you want to understand OOP you have to learn Solidity. For example reentrancy there is an important concept that should be enforcable in any language.
It's more like
isFriendsOf(buddy, 'guy')
and buddy is just data. buddy = self/this
Amazing talk. Thanks for the recording!
2023年，看到这个视频依然觉得非常棒！其实这恐怕才是程序编写的本质，是更高视角的。面向过程和函数式，恐怕只是处理对象关系和它们之间消息的另一种方式罢了。感谢分享！
She said the idea is as it should be, however just having an idea doesn't mean it will be incorporated in the final product. The implementation of OOP and it's patters in all of the languages I tried suffered from this.
Look at some of the arguments here: czcams.com/video/QM1iUe6IofM/video.html
great talk.
People who are commenting that they have not learned anything new from this talk & were not already previously sufficiently familiar with smalltalk missed the point entirely.
Last year (2022), Smalltalk celebrated its 50th anniversary. There were *four* individual celebrations! The first was the 50th anniversary edition of *JRMPC* (The James Robertson Memorial Programming Competition) in Toronto, Canada. The second was *Camp Smalltalk Supreme* also in Toronto, Canada. The third was the *Making Smalltalk* event at the Computer History Museum in Mountain View, CA. And the fourth was the *Smalltalks 2022* conference in Buenos Aires, Argentina.
All of these celebrations can be viewed at www.youtube.com/@50yearsofsmalltalk.
What other programming language has enjoyed so many anniversary celebrations? Smalltalk is most remarkable for its contributions to Information Technology.
Thank you, thank you, thank you. As a Biology major and now a self thought programmer working to understand OOP this talk REALLY hit home with me and added a lot of useful context to finally really under stand this paradigm in a deep way.
No, you don't. You just think you do, which makes you extra dangerous. :-)
What gets me with many OOP languages is the concept of a class which is totally in line with Linnaeus whereas in modern biology we think less about the idea of "a bird" being a specific class and more as a collection of dino-traits and a collection of birdy-traits that come together to make the thing we call "a bird". Which is more in line with how some more recent languages (like Rust) handle binding behaviour to data.
Great talk Anjana Vakil 👍
Use OO modeling to find the right places in your application to put boundaries. Use FP techniques within those boundaries.
garbage collection is a mistake
btw. pascal had it right the entire time, use pointers only in those cases where it makes sense and don't use them anywhere else
also microsoft somehow managed to take the notion of references from C++ and then complete break the functionality in C#, that is probably the main reason everyone is so gang ho on functional all of a sudden
Sounds reasonable, is it something knew as "practice"?
> _"Use OO modeling to find the right places in your application to put boundaries. Use FP techniques within those boundaries"_
thanks a lot for summary :)
Correct. The difference between languages consists of the syntactical sugar for the metaphor you think in, while writing the software.
Devicey (machine) - Controls
Mathy (functional) - Transformations
Bayesianey ( 'ai') - Categorization
Stringy (lisp) - Human Interfaces
Messagey (object) - Simulations, Systems
Delayed Messagey - Intersystem Systems
what about sync and reactive paradigms ? ,(in some sectors they are the most used and popular ones , thinking of vHDL)
on a side note i would have tought that after 20 years of "your doing it wrong" - OOP seminars and presentations , they would have given up by now and realized that OOP cant deliver , besides that i know quite a few people who all came to the same conclusion: apparently you need a degree in geneology and phylosophy more than a degree in math and programming to succeed at OOP if such a thiing is even possible., and a lot more that just realize oop is bad, and thats the only paradigm that ive ever heard this , for , never heard a functional programmer say: " danm procedural codebase , one should never program procedurally, nor have i heard a procedural programmer complain about functional or any other paradigm but ive heard them all complain about oop , prolly theres a lessen in there somewhere,. and yes writiing gui applications can be done without oop, QT is prolly the most OOP oriented toolkit out there , and am able to blackbox it and writer procedural code around it that works perfectly , and i have to type a whole lot less code for it.
@@DonAlcohol I don't think you grasped the point here: syntactical sugar reflects the different methods by which humans think, and the methods by which humans think can vary in concert with the optimum system model. Some of us wield all, some of us wield few, and some of us use a paradigm and some resist it. I suspect that you're trying to make the case that the kind of work you do is easier to write and more productive by not using OOP. That could mean the category of work you perform does not include the category of simulations. I prefer the pascal architecture we used pre-oop. Others prefer the functional architecture we used before pascal. NOw, you brought up reactive, which of course is a failure of the architecture of browsers given that open source gains that led to reduced costs and a vast ability to learn from and copy one another's code, also led to open source market for resistance to major improvements. I see the browser based tech as highly democratic and cheap per se, at the cost of spending billions per year and hours after hours because we don't have a compiler that does all the work for us, and so we compensate with all these 'hacks' we are self impressed with. The optimum language is already known. The way we compose software within it follows general design patterns. There have been minor improvements in software design over the decades largely for no other reason than decrease in cost of cycles, memory, and storage. And each generation re-learns the same things and tries to reinvent them, but they're all just basic design patterns.
@@TheNaturalLawInstitute no i actually understand what you mean and with the firs reply i just wanted to mention that you forogot some in your listing , (including a verry common one , wich is sync , the te paradigm used (besides functional) in spreadsheets. and with the second comment i wanted to point out that there is 20years of guides and presentations with the topic "why you are doing OOP wrong, and what is the correct way everybody seems to miss.. only to find that every guru and OOP connaisseur seems to have his own interpretation off why OOP does not deliver what it promises to. its never the "fault of OOP" but always some rule or guideline the users seem to miss or implement wrongly, but every GURU seems to contradict the otherones in how to do it right. (just as OOP does contradict its own definitions of what the stuctures are supposed to be, you dont have do go any furter than a singleton, its an oxymoron, read the definition of class then read what a class is supposed to be used for then realize on how many fronts a singleton violates those definitions) , and i hate using OOP myself but i dont forse other people to not use it , I know of verry few occasions where OOP is actually the best way of thinking about a problem , one of wich is in markup, and i mean (lets say HTML) the notation itself makes sens using some sort of objects that are grouped , the rendering / processing of that ML can be done better with procedural , ANSI (terminal markup and positiioning , for instance is a procedural way of markup but one as to agree thats less intuitive than html/css is to keep on top of things but thats about the only one. and as a last one: if you try to emulate realworld thinkg in a programming anguage and you link the way we categorise things similar to the abstraction in OOP, you should try to categorise living things,(or just humans for that matter) and see at what level a straight hiearchy breaks down the reason you almost cant make a hiearchy that makes sense at all and doesnt break the branching of a hiearchy , is the same reason abstractiion and encapsulation in OOP fail every time for a project in actiive development . and run a textsearch (with fzf or so) on a OOP project of some size for the words controller, handler,setter,getter,helper,factory,abstract, (or how manny times a button with the label "connect" actually runs a method in some subclass of connectionhandler while a func connect() would make allot more sense , if it succeeds great if it fails it cn throw an exeption, but it doesnt have to call amethod inside connectionhandler.connectionfailedhelper.conectionexeption)
@@DonAlcohol I dunno. OOP does what we want it to: simulations. Way 'back in the day' I wanted it before I knew it existed. Because I was writing simulation games on the first consumer computers. And I kept running into problems. IMO complaints about OOP come from people who haven't written anything large, that has to be broken down into responsible components agents, each of whom has to make decisions that can be driven by messages or events. There are a limited number of language paradigms available, and a limited number of design patterns possible, and we all know what they are and they serve different purposes at different scales. My main concern is that the browser era is teaching people to write bad code with bad tools that costs many billions of dollars. Now there is some tradeoff here between the economics of the current era's disposable software and the past era's operating systems (long-running) and applications (long-running) and now server (can be either) and browser (short running). But I've known for more than a decade how much time and money are wasted, people are employed, because of bad tech. So, you can either write in every paradigm or you can't. You can either choose the tool or you can't. I don't write embedded software. I don't write drivers. I don't write operating systems. I design platforms and applications, and (you don't know me) I built and sold two of the largest privately held software consulting firms in the country. I don't design much any longer, and don't program much any longer - it stopped being interesting. But Uncle Bob is pretty much right about everything and his advice stands. We will converge on one language. We know what it is. We will keep inventing a 'few' new tools that take advantage of faster processors and more memory and more distributed systems, we will keep inventing a few new patterns, and there are two generations we can at least envision coming down the road after the current bayesian and future baysian agent predictions. When we get to bayesian transaction I hope someone has fun with that one.
I'm a late learner of Kotlin, and this has cleared the lateinit part so much...thanks Anjana
Sorry... I'm trying to help not troll you... But Anjana describes "late binding" a lot of times in this talk which is (and I'm massively oversimplifing) related to polymorphism is OOP.
`lateinit` in Kotlin is more of a workaround to avoid having "null pointers" (it's not that great a workaround because it's just replacing `null` with something that smells very very strongly of `null` but isn't explicitly called "null"). The two aren't particularly related.
Great talk
she did auper well, super cool to see a unique perspective
*She is a great communicator👍👍*
Really nice talk
On a linguistic note: great point about not being a grammatical “object”. But I think she meant to say it is the grammatical “subject” not “verb”. The subject is the active agent “doing” things in a sentence. The grammatical object is passive. Objects in programming as described here are agents, not just passive receptacles.
Really great presentation on perspective once she got into it!
Objects in an OOP language are hints for the compiler for how to organize its compiler tables and they are tools of the architect to document code structure and to limit access of the individual programmer in the team to private data that are also disallowing the modification of interfaces. Objects don't exist in the executable. Neither of these functions has anything to do with grammar or agency (other than the differences in agency of the architect/programmer paradigm, which has everything to do with business structure and nothing with programming).
Messaging as a big idea isn't unique to OOP, though. It's accomplished with modularity. Plus, verbs are not unique either. Every function is a verb in the same way as Anjana got to, but immediately got to the problems of state management. This was an excellent talk in favor of FP for anyone who understands the pain of mutable state.
Spoken like a FP purist who ignored everything except the things that could be taken out of context to prove their point.
@@saritsotangkur2438 I hope you are having a good day and many better ones to come.
really good speaker
Anjana Vakil is the teacher I was looking for in my journey to Software Developer.
Kind of object-ish things that are almost an objects. I felt stupid every time she got vague and fluffy.
"It sort of moves a little bit in that direction." Immediately after I unpaused after my previous one.
i love this woman. i can listen her forever.
me too bro
Me too!
+1 😊
+1
just like OOP it takes 10 years to get to the main topic.
Lmao
Thanks
OOP paradigm is a concept, not always practical. In more than 20-year of programming work I never used it. I think RDBMS affects the practicality and effectiveness of OOP. Much of my work has been related to data analysis and processing and I never used OOP in any of my applications. And all of my customers are happy.
YoUR Soo muCh SmartS
Agree but at different fields and different level it depends on the requirements.
The merging of Code and Data together was never a good idea, right from the start of OOP. Thinking about Objects in terms of what they do is fine, but really, just thinking of them as Data unrelated to Code entirely is probably even better.
Buddy is not a person; buddy is just a "friend-verifier"!
Word salad is
She is a good presenter, but lacks content. It was just waste of time.
Where OO can get tricky is that unlike real world objects - the sky is the limit for language objects - the rules of "reality" can be bent, changed and broken - leading to code that is bent, changed and broken 😅
Now I am learning to best of both OO and FP world ... excellent talk
Yes, let's master both. She's right about the 'what the object does' vs. 'what data and structure'. Monads are good to understand, whether from an OO language or an FP language, because they are what's she's describing as little chunks of data with process around them. 🤓
BTW Monads in Haskell are kind-of inverted OBJECTs.
I preserved with this for a minute or two then gave up; excruciatingly directionless an boring.
This was a really helpful talk to reframe the way I'm structuring solutions. Thank you.
Interesting. I hate "really existing" OOP and I knew Alan Kay's original vision was a little different but I didn't realize it was so different.
Curious to know whether the original developers of the concept of OOP agree with her fanciful ideas...When I started learning C++ classes, I too thought in these lines and was excited. Later on, alas, to find that OOP is just a programming concept and the objects/classes in C++ have nothing to do with actual objects of the real world...
8:41 she is summarising the original idea by Alan Kay
@@pik910 Kay is not the inventor of OOP by any count. His ideas about it are not even mainstream and have little, if anything to do with the reality of why it was invented in the first place.
Seriously, I feel the same........OOP object has nothing to do with objects of real world........instead it is variable and function in one package as simple as that
@@lepidoptera9337 He is the principal designer of Smalltalk. Mainstream ideas of OOP today are misnomers.
@@drcl7429 Smalltalk is an aberration that nobody of importance uses. ;-)
This actually sounds like what I understand the "actor model" to be. I wonder what Kay thought about the actor model and how it relates to his notion of OOP.
He loved it and said Erlang is ironically the only language, that he would consider OO today.
Sorry, Anjana, I don't think calling a method is sending a message.
Think of the scenario that your boss, your client, and your coworkers are asking you to do things for them separately, but at the same time, and all of them want you to finish the job immediately. How does that feel? Yeah, it's a mess! And that is the OOP languages we are familiar with.
But if they email you about the jobs they want you to do, and allow you to do the job whenever you see fit. When you are done with one job, you reply to the corresponding email. If something is hard to do and your client gets impatient, he just goes away and finds someone else to do the job. How does that feel? A beautiful world! And that is Erlang.
That's why Alan Kay thinks Erlang to be the only mainstream OOP language, in the purest form, though ironically, Erlang is categorized as a functional programming language and not an OOP language.
a method is just a low level programming construct. a routine that can be executed on the processor. OOP employs this construct to implement collaboration between objects. As soon as you are thinking about Objects you have jumped up into a higher abstraction level where objects collaborate by communicating with each other (hence the term messages). Although it is implemented on processor as a method invocation at a lower level of abstraction. hope that clears things. What you are referring to are just two ways of control flow. One is imperative (method calling) and other is reactive (handling messages as events), both of which alan kay refers in this talk czcams.com/video/QjJaFG63Hlo/video.html.
Sounds more like a lack of software engineering experience than an oop vs actor model issue. If you want to do concurrency then use concurrency patterns. If you don’t have the concurrency requirement then don’t. Don’t apply the wrong pattern and then say something sucks, that’s a strawman argument.
Talk actually starts at 6:45, it's basically just ads before that
What an important talk in this time where people bash OOP because they know nothing.
She certainly knows less than nothing about it. ;-)
it finishes at 6:48 .
i dunno: how is the isfriendof method behaviour and not data???? Here is my take on it: the core of OOP is decoupling. Which means the behaviour of obj a should not in any way depend on behaviour or data from object b. and moreover objects should never share information like whether guy is a friend or not
Good luck with that strategy. See you are your next refactoring party. (Unpaid overtime, of course.);-)
Many people bashing her in the comments. Why? She just told the truth. OOP is just about "message" as Alan Kay said. Don't make things more complex because they aren't.
Yes, that is bullshit. Alan Kay had nothing to do with the invention of OOP to begin with and he simply misunderstood what it was trying to do. Almost no implementation of OOP uses message passing. Those that do contribute nothing to the solution of the problems that OOP was initially trying to address.
The example of encapsulating Friend in a function does not scale. What if we want it to support multiple functionalities?
You are simply running up against the fact that OOP can, in the best case, describe tree-like dependencies, while in real life dependencies in complex software tend to form graphs.
You mean to say thinking about Object Orientation in a Functional way will tell us what OOPs really is? Haha
Aren't cells microservices? They communicate by APIs.
Yes. They are putting too much effort into redefining OOP into something it is not, just for the sake of redemption of its original author's intentions. There are more appropriate terms for the style of programming the presentation illustrates. I've also heard about this paradigm referred to as "Agent Oriented Programming".
Anjana, your talent & insight is a gift to the programming community! Thank yoU!
Great job mixing philosophy linguistics and code concepts! We need more like this
exactly
> _" linguistics and code concepts"_
thus reminds me of the talk given by co-creator of julia language.
I love her gestures
she talks with like dozen of organs.
This reminds me a lot of the observer pattern or event-driven architecture. Is she saying any OOP system is basically an event-driven (message-driven) system? Very interesting talk.
Yes, kinda. If you want to program in OOP the way Alan Kay imagined it, then yes it is a form of event driven architecture. However, it is not the observer pattern. In OOP the caller knows who to send the message to. In observer pattern there is no caller per se, the caller instead notifies other objects that have subscribed to it of it’s changes.
@@saritsotangkur2438 Thank you for your reply!
@@saritsotangkur2438 Events then? Since C# Events doesn't know who's listening or subscribed
She's right about the 'what the object does' vs. 'what data and structure'. Monads are good to understand, whether from an OO language or an FP language, because they are what's she's describing as little chunks of data with process around them. 🤓
21:56 > _"procedural focuses on data, OO focuses on behaviour"_
oh lol, what to write in exams now haha
It's 100% incorrect to begin with. Procedural programming is focused on action while OOP is just a bean counting strategy that gets stripped out by the compiler completely. The compiler can't strip out procedural code which actually does something (and it doesn't, unless it is dead code, which is rare).
> _"Procedural programming is focused on action"_
@@lepidoptera9337 yeah, exactly. I was taught in the class that "PO focuses on functions, OO focuses on data"
when I realized that, in c++, a class' private parts could be manipulated by its friends, more than just my mind was blown, as it were.
Why is that a problem? In C++ absolutely everything that belongs to the program (data and code pages) can be accessed with a pointer. The language implementation does not prevent this by design, otherwise you could, for instance, not write operating systems with it. If what you want is a language that is not Turing complete, then C/C++ are not the right choices.
Start with Smalltalk and it makes sense.
What is a practical example of "delaying the beliefs of what's going to happen" in programming?
Every piece of bad code in the world is a practical example of that. There simply is no such thing as "a bug". There are only people who don't know what will actually happen when they write code. A bug is the disconnect between the programmer's beliefs about the language and the compiler and the compiler's actual architecture. ;-)
@@lepidoptera9337 this is one brilliant definition of a bug.
Why does everybody leave out the S. it’s OOPS NOT OOP. Object Oriented Programming System.
Relax
That's only when you learn programming in India.
is there anyone to help me in finding job as python django developer . I am fresher
WASTE OF TIME
"OOP" becomes very very blurry when you move away from systems designed around Java/C#/C++ principles. For example, you can grow your own object system out of pure lambdas and closures (in Scheme, Clojure, Common Lisp etc). But rather than do things like this, people are too busy following loudmouthed knotheads who don't explore more than one domain where one approach excels. There is a world of difference between brittle and stiff OOP (think Java) and something seen in Common Lisp's CLOS for example. There is a wide swath of middleground between functions and objects. And depending on how flexible your language is, you can design one in terms of the other. But you won't get that kind of flexibility in most common languages. Scheme is a great language to explore paradigms with. The whole spec is around 45 pages (with examples). However, it is so flexible you can make Functional programs, Object Oriented Programs (build your own with closures and messages), Declarative Programs and Logic Programs (The Reasoned Schemer).
OOP is not language dependent. It is always just documentation. The final binary does not contain any traces of your OOP code, if your compiler is any good.
@@lepidoptera9337I was about to say "Java leaves plenty of traces of OOP in the binary"... but then I noticed you said "... if your compiler is any good" ;)
@@edgeeffect Java was an idiocy. It's "write once, deploy nowhere" for starters. It provides next to no useful additional abstractions compared to let's say C++ but suffers from the same problems (complex types are passed by reference... welcome to recursion hell...) without allowing low level programing (no, pointers are a real feature, they are not a mistake) etc.. It was basically language design during an amateur hour of sing as much as you want CS Karaoke.
APhilosopherWomanTalkingOOPWhatCouldGoWrong extends Prejudice
6:30 video starts.
I just love you 😍.
Much much respect for you. 🙌❤️
starts at 07:13
Microservices are the perfect example of OOP concepts.
yes polymorphism. Probably THE core concept of OOP. I personally prefer functional programming.
@@peach_of_justus honestly, I don't remember. But there's a reason you ask. Let me know your thoughts.
IMO the core concept of object-oriented programming is parameterization of behaviour rather than just data; by this, I mean passed in behaviours that are not known at compile time, like how data values are not known at compile time.
Messaging is simply invoking a parameterized behavior.
"Recursion on the concept of program" is composing parameterized behaviours into more behaviours.
Late binding is another way to describe this same concept.
First-class functions are an alternate way to conceive of parameterized behaviour.
Happy to see a South Park fan
I really don't know the use of messaging in in-process system whatever paradigm you use.
What puzzles me is why Java streams is not being talked about. It is about data and you add behaviors that will operate on the data. Just like composing functionality, and for streams it is very powerful.
But I feel it is just a halfway house. If only this could be expanded not only for streams but for most use cases, we will be composing functionality (with easy to understand code) instead of writing boilerplate code. And yes I like it to be inside the Java eco system.
A philosophy major loves Object Oriented Programming. Figures.
Bwahahahah
Hot take: good oop = functional with awkward syntax.
It's not what you are underneath, what you do define you - Batman's Girlfriend
nonono, it's OPE. As in "Ope, I see what you did there."
print: " I'm not your Buddy PAL! "
thatttt referenceee thoooo :)))) m not your friend guy. But honestly, brilliant talk. Really helped me put some things into perspective
10 minutes in and she hasn't said anything useful: all she did was the typical melodramatic "Everything you thought is wrong!" bullshite.
4:00 yay sexism!
I don't know if late binding (message passing) is such a good thing for changes. It's dynamic typing, and that always is worse to change/refactor than static typing. Late binding pushes what could be a compile time error to runtime. AFAIK one of the annoying things about Objective-C was that if you mistyped a method name it compiled and was just ignored at runtime or something like that?
Speaking as a Smalltalk developer here I find I can quickly refactor classes using the tools Smalltalk has available. In smalltalk if you mistype a method name the method will not compile. There can still be run time errors, however. For instance, you could put 2 objects of different classes into a collection, and then call a method on all objects in the collection. So a message could be sent that cannot be executed because the object does not have a method protocol for that message. In that case, in Smalltalk at least, the program does not crash but "doesNotUnderstand: " gets called on that object. So that gives you some leeway into making your system robust. But the real key is just programming and debugging in a way that will not run into these errors. Unit testing can help with that.
@@zenchess Yeah, except for not throwing an exception this sounds exactly like all those dynamically typed languages to me. Having to write unit tests for things other languages just check in the compiler for you. In what cases does smalltalk detect missing methods on "compile" time? When the type of a local variable can be inferred? Then it is at least better in that point than other dynamically typed languages, but still. I prefer strict static typing when possible. (With type inference and all the nice handy things of course.)
Late binding is orthogonal to dynamic typing. All it means is that the function (method) being called is not set at compile time. Whether it is typed checked or not is up to the language to decide. Java type checks whereas Python doesn’t.
I don't think to name Erlang here is correct! Erlang used message passing to solve concurrency problems and to avoid the problem with threads in other platforms like JVM/Java, they use immutability (functional paradigm), even how an actor send/receive a message and do thing based on them is not relevant to message passing in OOP. I enjoyed the talk, this was a talk for the ones who started programming but still have some false parts. it was better if Anjana used Scala instead of Erlang. comparing message passing in this manner was wrong, they used it to resolve different problems. message passing in Erlang is not even part of Functional Paradigm.
Message passing has exactly the same problems as threads. All concurrent systems have them. They are not "just" a consequence of "stupid implementation". Concurrency removes the abstraction that there is no time in computing. And once you let it in, it will cause all kinds of unpleasantness because "who's first" suddenly matters.
@@lepidoptera9337 what I meant by threading is its implementation, the API developers are using, I assume we know it’s a must if you want to use more CPU cores; yes behind a scene everything is threading if you do. but the thread implementations in JAVA, C++, etc and the context switching, dead locks, etc has pitfalls. actor model solved this assuming we know it’s using threads behind the scene but it hides it from us.
@@masoudesmaeilian5083 Parallel processes that don't communicate are perfectly safe, but very limited, of course. It's always the interaction that makes life difficult. Deadlocks and races are not implementation dependent. They are inherent in concurrent designs. I once talked to a CS professor who had implemented two concurrent languages and who was considered a leading specialist in the field. He told me that he had basically given up on the idea that one could make concurrency easy and safe. One can always make it work, of course, and I have done it often enough in my work. It's just no fun to debug these systems and it might not get significantly easier, not even with new languages. I hope I am wrong.
This was the most confusing talk ever !The whole.idea revolves around one sentence, the rest is rubbish!
I don't see why this isn't just referred to as 'modular'.
Because "modular" is far more general than OOP. OOP was originally meant to put limits on modularity to allow for automatic optimization.
@@lepidoptera9337 thx good to know. I find the expression OOP confusing as I struggle to understand what it means.
@@stevenlightfoot6479 In its most basic form it means that we are packaging data and functions that act on data together and we call that a class. The problem with that is that very often the most important functions in our code are not just acting on one data structure but two or more, i.e. the association of functions with any one data structure is ambiguous at best or counterproductive at most.
Consider something like a dogClass. Every dog object has a name, date of birth, an owner, a vet and maybe even a dog walker. Where do you put the healDog() function? With vetClass or the dogClass?
Even worse, both the owner and the dog walker are walking the dog and the owner has to pay the dog walker. So does walkDog() belong to dogClass, ownerClass, dogwalkerClass or neither? Are there multiple versions of it (oh, horror!)?
Who calls payDogWalker() at the end of walkDog()? You may have to go to absurd lengths to sort these kinds of things out by calling dogWalkerClass.invoiceDogOwnerforDogWalkActivity() as part of dogClass.walkDog() or something similar just to allow messaging between two classes (dogOwnerClass and dogWalkerClass) that are being references by dogClass data.
Problems like these can snowball very quickly in large OOP projects if the architect didn't think dependencies through all the way. Or let's say the architect is really, really good and it all works but now the requirements change and suddenly there are new dependencies that didn't exist before. Suddenly it doesn't matter what object structure worked well in the past. That's why it's dangerous to make the kinds of structural decisions that OOP requires early in the architecture phase of a project. They usually don't tell you that in OOP classes, though. The usual examples for beginners have trivial dependencies which hide real world problems.
also: thinly wailed recruiting scheme going on here :D
you should really think about C++ as a low level version of C# instead of an object oriented version of C
yes, because defining ADT's using basic syntax without language elements that tell you it's an ADT is so much clearer
As someone who was trained on scheme, it absolutely boggles the mind that people think functional programming is a better way to write code. The free software foundation made scheme the default language for writing extensions for all the GNU projects many many years ago and nobody ever thought it was a good idea to actually use that.
I mean C++ is essentially a oop version of c. It took great parts of c and built upon it to help programming enterprise applications. C# took that same premise but did it to c++. They all have their place. Same with the paradigms. I think people look to much to these concepts as the end all be all and say one trumps another. When, In reality they’re all just different tools and practices that are a part of a bigger system.
I think most advocates of Pure FP (ie no OOP at all) have never dealt with a huge codebase or gamedev before. OOP has problems when using it at a small scale but on big programs I couldn't imagine using anything else.
@ 8:30 stops talking about herself.
Throughout my 12 years of programming OOP languages, I can confidently say that I have no idea what OOP "is" and what it's all "meant to be" in a higher sense. I get a powerful feeling that people are trying to rationalize this messy programming world, and make us look at it from specific points of view, none of which perfectly describes reality. As for "use the best tool for the job" - who even knows what "best" is when new tools are constantly appearing, the people on the team have different backgrounds, and in 5 years all code will be legacy anyway? I think we're not smart enough to comprehend all the complexity of software, but from time to time, someone smokes something and has an interesting dream of what it all means - and the dream never helps anyone, but in any case, we're all looking for a prophet to make us feel safe in this incomprehensible programming world.
You are mostly telling us that you have no experience in software design. Let me give you some attention then. ;-)
@@noobdernoobder6707 You got it... objects are not good representations of most problems and compilers remove objects completely, which means that OOP is basically just a really bad documentation technique that writes a lot of boilerplate to express something that the programmer usually doesn't even need and want. Architects like OOP, though. Why? Because it allows them to micromanage interfaces and they can bash the actual coders for violating "their" design. The biggest problem with objects is deep inheritance, which locks the code into a rigid structure that may not be appropriate. Even if the architect got the initial class hierarchy "right", changes to the requirements can break the class hierarchy in really nasty ways, requiring a lot of refactoring, which is confusing and violates the "never break a working system" rule.
@@lepidoptera9337 Thanks for the attention! Not sure what qualifies as experience tbh. Did I write class diagrams? Probably did, a long time ago. Wrote a lot of sequence diagrams (hundreds). I also wrote countless classes. Does that count? Anyway, I'm not saying i'm not the world's worst programmer, but I'm curious whether anyone did any studies testing claims about OOP. I totally get this phenomenon you wrote about, that architects can use class (or other) diagrams to show developers how thet did stuff wrong. For a mere 9 months did I work with a software architect, and stuff absolutely moved slower - I suspect that the guy was really bad though, but the one datapoint I have is not saying good things about architects.
@@ardeleanvladgeorge7493 My experience with (rigid) architecture is that it clashes with the reality of requirements change. Most complex projects are actually exploring the question "What does the customer really want to do?" while they are developing the solution. So unless the architect has godlike visions of the future even the best intentions and the best intellectual execution of the original requirements will necessarily cause problems in the future... IF the original architecture is too keen on "getting it absolutely right".
Techniques like OOP that are trying to lock the architecture in too early are necessarily suboptimal in a dynamic environment. They look good on paper before they are being committed to actual costly work on the code, but can easily backfire by making large scale changes necessary at later stages. I put myself through refactoring hell once (on a single person project!), and that taught me to be more open than perfectionist. In the end I rewrote most of the top level structure in a couple of days from scratch. It was easier than trying to fix the bad choices I had made in the beginning incrementally.
This talk is not what I thought.