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!
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.
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.
@@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. ;-)
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.
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.
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
> _"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 :)
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.
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
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.
@@hoefkensj 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)
@@hoefkensj 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.
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!
Wow. I was struggling to compose oop and fp in one paradigm for years now and you did it in two lines for me. Thank you! Now I need to think how I combine that with logical.
I thought that thumbnail(cells under microscope) was mistaken but after watching it I knew i was wrong ! Thinking about OOP as human body structure cells and organs connect with each other is a mind blowing. also, I am happy and surprised that creator of this paradigm is coming from a biological background as me (doctor)
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.
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.
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.
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: ua-cam.com/video/QM1iUe6IofM/v-deo.html
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).
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.
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
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.
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.
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.
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. ;-)
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
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 😅
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. 🤓
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.
Any "why" for such statements? That merging allowed modern computer world to happend by solving problems existed in previous paradigms. Before posting your precious totally wrong opinion, maybe, its a good idea to watch/read smth Alan Kay and other sources from this talk?
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".
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.
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.
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. 🤓
lol, I once tried to break down object objected language into parts of speech. Which is incredibly similar to what you did at 16:50 Basically I looked at what linguists did with English. They broke it down into parts of speech. Subject, predicate, verbs and nouns. etc etc. I tried to do what with OOP. I was also simultaneously exploring the concept of modularity. Called it "Machine Neurology". The concepts do not make much sense to average programmers but the similarity of this to what I did is astonishing.
I say there is such a thing as Zeitgeist that influence people. And what ends up happening is people from different places doing the same thing. Strangers doing work done in parallel.
Vocabulary is defined in a survival of the fittest popularity contest. That which the masses say a word means ends up in the dictionary. The masses have spoken and OOP is what OOP is and not what Alan Kay wanted it to be. OOP is C++ and JAVA. I say put that to rest, you shouldn't work against the masses and call your approach a different name. I called my views Machine Neurology but I see now that may get squished by the popularity of AI
Messaging is event driven programming soo trying to call it OOP will just make confusion. And what you are talking about is modularization. Making programs modular. Dynamic Linked Libraries. maybe what we need is to come up with a more markatable name to Dynamic Linked Library programming (ie: "Machine Neurology")
@@victorolvera6482 Kay didn't invent OOP. He simply didn't understand the basics of computer science and came at programming from an amateur's perspective. It shows in the delusions about the topic that his admirers share with him.
@@lepidoptera9337 🤔The thing is she governs quite a bit of influence. You gotta think about the guanxi. She is a colleague because her work overlaps mine. If she would only take a look at my stuff and talk about it publicly I would be grateful. She would also redeem some of her naivete. Vocabulary is a survival of the fittest POPULARITY contest. If its true what you say, that Kay wasn't the one that came up with object oriented programming. It just proves my point. Kay is on the history books as the guy who coined the term. Similar to the story of Phil Katz and PKARC vs PKWARE
objects are instances where class is a blueprint .when you discuss anything regard oop and compare with human life this means methods are activity and objects are person who is responsible for each and every activities
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"
That's because what Kay called OOP wasn't OOP to begin with. He was simply not familiar with the work of others or, if he was, he was too full of himself to honor it.
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...
@@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
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.
7:26 - encapsulation is left out. then the entire talk is about encapsulation and she's surprised that encapsulation requires passing of requests (yes, I purposefully didn't use "messages").
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.
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 ua-cam.com/video/QjJaFG63Hlo/v-deo.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.
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.
@@bluedark7724 it's a pattern. In its basic form it's a class with three methods, attach, detach and notify. attach takes an object to add to the list of subscribers, detach does the opposite. Notify iterates over the list of subscribers calling notify.
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. ;-)
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
"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.
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.
@@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.
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.
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.
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 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
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. ;-)
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.
@@lepidoptera9337 All that text, just to say "you suck", you are insufferable and obviously people do not tell you enough.
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 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, 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.
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 :)
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.
@ 8:30 stops talking about herself.
2023年，看到这个视频依然觉得非常棒！其实这恐怕才是程序编写的本质，是更高视角的。面向过程和函数式，恐怕只是处理对象关系和它们之间消息的另一种方式罢了。感谢分享！
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.
@@hoefkensj 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)
@@hoefkensj 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.
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
You started in SQL? that's wild I've never heard anyone start in sql but it's not a bad idea.
Wow. I was struggling to compose oop and fp in one paradigm for years now and you did it in two lines for me. Thank you!
Now I need to think how I combine that with logical.
I always have a great time listening to Anjana Vakil
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.
😂😂😂
i love this woman. i can listen her forever.
me too bro
Me too!
+1 😊
+1
I thought that thumbnail(cells under microscope) was mistaken but after watching it I knew i was wrong !
Thinking about OOP as human body structure cells and organs connect with each other is a mind blowing.
also, I am happy and surprised that creator of this paradigm is coming from a biological background as me (doctor)
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.
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 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.
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.
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: ua-cam.com/video/QM1iUe6IofM/v-deo.html
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).
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
You misinterpreted what she was saying
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.
*She is a great communicator👍👍*
Buddy is not a person; buddy is just a "friend-verifier"!
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.
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.
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? ;-)
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
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 😅
What an important talk in this time where people bash OOP because they know nothing.
She certainly knows less than nothing about it. ;-)
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.
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.
Any "why" for such statements? That merging allowed modern computer world to happend by solving problems existed in previous paradigms. Before posting your precious totally wrong opinion, maybe, its a good idea to watch/read smth Alan Kay and other sources from this talk?
Thank you so much.
she did auper well, super cool to see a unique perspective
all i can say is thank you a lot
Thank you for sharing!!!
Thank you for this talk, Anjana.
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".
starts at 07:13
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.
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.
Word salad is
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. 🤓
lol, I once tried to break down object objected language into parts of speech. Which is incredibly similar to what you did at 16:50
Basically I looked at what linguists did with English. They broke it down into parts of speech. Subject, predicate, verbs and nouns. etc etc. I tried to do what with OOP. I was also simultaneously exploring the concept of modularity. Called it "Machine Neurology". The concepts do not make much sense to average programmers but the similarity of this to what I did is astonishing.
I say there is such a thing as Zeitgeist that influence people. And what ends up happening is people from different places doing the same thing. Strangers doing work done in parallel.
Vocabulary is defined in a survival of the fittest popularity contest. That which the masses say a word means ends up in the dictionary.
The masses have spoken and OOP is what OOP is and not what Alan Kay wanted it to be. OOP is C++ and JAVA.
I say put that to rest, you shouldn't work against the masses and call your approach a different name.
I called my views Machine Neurology but I see now that may get squished by the popularity of AI
Messaging is event driven programming soo trying to call it OOP will just make confusion.
And what you are talking about is modularization. Making programs modular.
Dynamic Linked Libraries. maybe what we need is to come up with a more markatable name to Dynamic Linked Library programming (ie: "Machine Neurology")
@@victorolvera6482 Kay didn't invent OOP. He simply didn't understand the basics of computer science and came at programming from an amateur's perspective. It shows in the delusions about the topic that his admirers share with him.
@@lepidoptera9337
🤔The thing is she governs quite a bit of influence. You gotta think about the guanxi. She is a colleague because her work overlaps mine. If she would only take a look at my stuff and talk about it publicly I would be grateful. She would also redeem some of her naivete.
Vocabulary is a survival of the fittest POPULARITY contest. If its true what you say, that Kay wasn't the one that came up with object oriented programming. It just proves my point. Kay is on the history books as the guy who coined the term.
Similar to the story of Phil Katz and PKARC vs PKWARE
Start with Smalltalk and it makes sense.
objects are instances where class is a blueprint .when you discuss anything regard oop and compare with human life this means methods are activity and objects are person who is responsible for each and every activities
Yes, and all of that is bullshit for kindergarteners. It tells you all the things you don't need to know and none of the things that you do. ;-)
In Python, a "class" is just an object that's somehow able to create new objects when __call__-ed 😊
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"
10 minutes in and she hasn't said anything useful: all she did was the typical melodramatic "Everything you thought is wrong!" bullshite.
Amazing talk. Thanks for the recording!
I preserved with this for a minute or two then gave up; excruciatingly directionless an boring.
WASTE OF TIME
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.
That's because what Kay called OOP wasn't OOP to begin with. He was simply not familiar with the work of others or, if he was, he was too full of himself to honor it.
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. ;-)
really good speaker
yes polymorphism. Probably THE core concept of OOP. I personally prefer functional programming.
@@indicted_ham_sandwich 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.
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.
Great talk Anjana Vakil 👍
Anjana, your talent & insight is a gift to the programming community! Thank yoU!
Really nice talk
great talk.
7:26 - encapsulation is left out. then the entire talk is about encapsulation and she's surprised that encapsulation requires passing of requests (yes, I purposefully didn't use "messages").
I love her gestures
she talks with like dozen of organs.
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.
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 ua-cam.com/video/QjJaFG63Hlo/v-deo.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.
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
@@bluedark7724 it's a pattern. In its basic form it's a class with three methods, attach, detach and notify. attach takes an object to add to the list of subscribers, detach does the opposite. Notify iterates over the list of subscribers calling notify.
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.
Microservices are the perfect example of OOP concepts.
4:00 yay sexism!
You can tell that her brain never got over the philosophy and English major stage. ;-)
And I hope it never does. :)
APhilosopherWomanTalkingOOPWhatCouldGoWrong extends Prejudice
What's your problem? Weird comment.
Happy to see a South Park fan
Great talk
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.);-)
It's not what you are underneath, what you do define you - Batman's Girlfriend
Talk actually starts at 6:45, it's basically just ads before that
This was a really helpful talk to reframe the way I'm structuring solutions. Thank you.
This was the most confusing talk ever !The whole.idea revolves around one sentence, the rest is rubbish!
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.
They leave out P. POOP
@@MikAlexanderwhat would the p even stand for lol
"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.
She reminded me of the IQ lady the way her body moves when talking.
it finishes at 6:48 .
6:30 video starts.
thatttt referenceee thoooo :)))) m not your friend guy. But honestly, brilliant talk. Really helped me put some things into perspective
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.
A philosophy major loves Object Oriented Programming. Figures.
Bwahahahah
Hot take: good oop = functional with awkward syntax.
You mean to say thinking about Object Orientation in a Functional way will tell us what OOPs really is? Haha
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.
There is not much you can learn from SmallTalk other than how not to do programming. ;-)
is there anyone to help me in finding job as python django developer . I am fresher
I just wasted 35 minutes
print: " I'm not your Buddy PAL! "
nonono, it's OPE. As in "Ope, I see what you did there."
Thanks
I just love you 😍.
Much much respect for you. 🙌❤️
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.