Little late to the party, but how are you practicing language production (to use a fancy term for it)? I'm also journeying to learn Japanese. Kanji recognition comes fairly easy after drilling for both reading and listening, but when I'm trying to remember a word: say a word, or write a word I often draw a blank. I struggle to remember the correct pronunciation or even the radicals in the kanji. I'm interested in what other fellow learners are doing.
41:25 "an anonymous function which doesn't see anything from its enclosing scope" is present in C++ in the form of a lambda with an empty capture clause, i.e. [](T arg1, U arg2) { /* You can only use arg1 and arg2 */ }.
this "use" feature in 41:35 is somehow present in c++ in form of lambda functions, where you declare copy variables inside [ ] braces. It's not as simple as the example through.
8 years since this masterpiece. I’ve progressed with simple procedural code to the point where I physically cringe reading others peoples OOP code labyrinths
all of the strong patterns and principles used in the industry are using OOP, for example SOLID, Design Patterns, Clean, Hexagonal architecutres and Domain Driven Design
The popularity of Java style OOP now seems obvious to me, and is caused by three main factors: 1. No or less memory management. 2. Autocomplete. Browsing for methods is a real thing, although it wasn't common in my generation of programmers. 3. SVO order - typical in western languages. Sadly, functional languages use VSO or VOS - which are very uncommon in modern language branches. But you are completely right that subject-object aren't usually well defined in programming, so the Japanese might think of Ruby as being OVS while English speakers consider it SVO.
ever since i started coding I resonated with the points made in paralysis analysis. granularizing large classes and jumping through a bunch of methods is very annoying. and the interplay between objects can be challenging.
This video is great. The topics discussed in this video(dogmatic usage/forcing of object-oriented patterns without good reasons for it) is one of the reasons I like the Lua language so much. It doesn't get in your way and lets you just do what you want. It's flexible enough to support object-oriented programming, but doesn't force you to use it.
The "use" block thing is basically a C++ lambda if you don't use an ampersand or an equals sign in the square brackets. I just wish they came up with a better syntax for it.
Hey brother great video, I have a video that I think nicely compliments this one where I go into a bit more detail on why tiny functions and classes are bad. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-BPHro8zQBQ0.htmlsi=wUXhizbfMtpXrOos
Hey Brian. I love your old series teaching programming and I found all the videos I have watched thus far fantastic. I love your teaching style and the focus on narration and an understanding of the underlying technology used rather than an endless stream of context-less examples and practice questions. However, while jQuery is still relevant to a degree today when it comes to supporting older browsers or simply out of preference and a shorter syntax, vanilla JavaScript has come a long way and has made its original purpose mostly obsolete. Do you have recommendations for a resource which covers the more modern side of vanilla JavaScript for use in the browser? I dislike all the popular platforms which show up at the top of search engines because of their extreme reliance on examples after examples and because they often just paraphrase other sources with some trial or paywall added on top, and I love your simple teaching style which explains the inner working of the language.
Many if not all of his observations are correct of course but his conclusions are nuts. OOP is not garbage. OOP adoption is not a disaster. Today's software, tools, and applications are frigging awesome compared to what was available before 1995. What many OO programming languages (and many functional programming languages) have done wrong is attempting to achieve "purity". Java could have been designed to support classes, interfaces, polymorphism, encapsulation, and even inheritance as well as traditional imperative procedural programming all in the same language. Scala almost does this and is a significant improvement over Java. Python doesn't force you to use classes. Extremism is always bad. Run away from extremists politics, religion, fad diets, and extremist programming languages and techniques, i.e. Haskel, Lisp, Smalltalk, Test driven development, UML diagramming, Agile, etc.
Half the commenters seem to think that "object-oriented programming" means "code that uses classes." Brian Will was pretty clear that he wasn't saying "don't use classes." He could have been a little more explicit about this, but I think he defines OOP as having three main properties: (i) all of a program's functionality is contained in class methods; (ii) all of a program's data is contained in class instances; and (iii) class properties are all private, or predominantly private, so that classes can only ever directly manage their own internal state (i.e. classes are used to "encapsulate" state). Two things about that: First, that's a pretty reasonable way to define OOP. It's pretty much what I learned in university when they were teaching Java and C++. Second, defined in that way, OOP absolutely is terrible.
I see a lot of conceptual errors in this video. 19:12 Java is "pass-by-value", if that value is a reference (aka reference variable), you do pass an object reference. 21:01 Encapsulation means that data are not publicly available, which ensure value validation. That doesn't even relate to the fact that more objects can invoke method on the same object. This is shared state, like in procedural programming: guess what, in procedural programming you can touch every data with no encapsulation. So hooray for encapsulation. 22:30 Having a global object? Yes. Traversing to parent to dive to another object? Yes. What's the problem here? (Moreover, Ive never - NEVER - seen circular reference through object in OOP). 26:00 This problem is about software architecture, regardless of the paradigm used. Actually, when specs change, modifying a procedure in Proc. programming is at risk of breaking more things (changing API etc.), while in OOP you just create another class/subclass and you don't even have to touch any existing code. 27:31 In proc. prog. and OOP you both can change the specs of your data structures, but encapsulation and inheritance in OOP allow you not to rewrite existing code to accomodate these new changes. I have to go rn, so cannot continue viewing the rest of the video ... but I can just imagine the court-like thesis he will bring about just to give the illusion that "OOP is bad" is the real deal. To me, this is a fanboy video (sad that people fall for this and don't analyze what he really says).
based on your title: if you come from functional programming and you're not comfortable of using object oriented programming then don't use it, but take in count that that pattern of programming was used to make almost all the software in the world
I think this video is really helpful if you like OOP or not because not enough people even make the connection, that OOP, functional Programming and Rusts borrow checker all try to solve the same fundamental Problem of computation. OOP forces you into structure, that makes it harder to run into problems with shared Mutable state. Functional Programming makes all state immutable and tries to deal with the consequences, rust enforces strict ownership rules to rule out that multiple functions influence the ssme Mutable state at the same time. This critic of OOP boils down to the fact, that of these 3 Solutions, OOP is the only one that doesn't gurantee anything. Haskell and rust can mathematically proof, that these class of problems can't arise, while OOP is more of a workaround. Which Solution is the correct one highly depends on what Problem you're trying to solve. Functional Programming makes some things unreasonable difficult and is still to slow to be used in systems Programming. Rust enforces alot of structure, inhibits fast Iteration times. OOP doesn't actually offer any guranteed protection. If you just need a one-time Script even OOPs structure is overwhelming and not needed
Why ... why use an abstract class or interface when classes already encapsulate/abstract code and and you NEED to implement the interface anyways. Wtf is the point 😂. I'll stick to classes and data structures cause they can be handy. Abstract BS is redundant and makes code a nightmare to read
Some allure of OOP certainly comes from the complexity generated by algebraic properties of classes. Classes are sets of methods, so the complexity of set theory is shining through. Multiple inheritance, or just implementation of multiple interfaces, makes it even more complex and entertaining. It's even more coconuts with generics. Those who have studied algebra know that you can make such a toy of simplest mathematical objects. Doesn't automatically mean that that math has any utility though.
I like to be pedantic so I'll point out that "plain text" includes plenty of formatting. A line feed literally formats text so that it appears on the next horizontal line below. Multiple spaces are often inserted just to format the output with an indented margin. Also: it's not far fetched to make a text editor interpret FF as page break, or SI/SO as emphasis toggle, like originally intended.
