A follow up to https://www.youtube.com/watch?v=QM1iUe6IofM.

source

42 COMMENTS

  1. "When you have a hammer, the whole world looks like a nail." In the examples presented here, I didn't see much by way of data or state. What I saw was some kind of attempt to encapsulate procedure. I am willing to concede that this is very likely a misuse of object oriented programming. (And I have been guilty of it. Mia culpa.) My background is C and then C++. What I would like to know is what are the pros and cons of objects when it comes to manipulating and using the data fields of a struct (or class). Is foo->bar = belch superior to foo.setbar( belch) or what of setfoosbar( foo, belch) ? If one of these is better, which and why?

  2. Very interesting videos, but your code does not seem to be strictly procedural either. When you instantiate a new HashMap<,>() and then call its containsKey method, you are indeed using classes and objects. Isn't a procedural integration of object-oriented components, like your own, a useful approach?

  3. I would like to elaborate one thing about the example given in 14:50. Imagine a situation where this code is in a closed environment, for example on a disc. You, as a programmer, want to extend this functionality. Say you want to add a new item type. Now if the code on the disc was written in an object-oriented fashion, you could easily add a new item by importing the item class, extend it and override the tick behaviour. In don't see how you could do this more easily with the procedural code you have written (using the switch statement).

    It all boils down to the fact that OOP is not a better way to write more readable code. It makes your code more maintainable, testable and extendable (like the example I gave) because it encapsulates behaviour. And like everything in programming, different situations needs a different solutions. You should always apply the solution that fits the problem and the situation the best. This implies that object-oriented design is not always the way to go.

  4. OOP forever. When you make big projects it makes life very easy. For example in my game engine, each entity has many many attributes. It is nice to hold all their attributes in one class with many instances.

  5. All this talk about OO but yet there is still no proper consensus of what it even is. Just like the concept of religion. I'm not saying that it is a quasi-religion but it does seem to get quite close. I'd like to see a proper discussion or a debate about this if that meant that everyone would actually articulate what they even mean with it as unless it is defined even if just for the sake of argument for that talk alone even that would be a step forward from all of the random ramblings I see in the comments of this video.

    Having said that to me OO is not about the syntactic sugar nor about the various implementation techniques, features and conveniences but about black box-ish program units (or in other words modules) communicating with each other using a beforehand agreed upon protocol (or in other words an interface) which allows one to divide and conquer the codebase one module at a time and swap out one for another freely as long as the interfaces don't change. In other words the idea of turning a codebase into a network of small virtual computers talking to each other.

    However if one sees modern OO as just the belief that a program unit must be just a synonym for an abstract datatype with every function being required to be tied to one as a method and remembers how modern OO languages are full of all kinds of workarounds for getting around the very idea of OO they have then obviously the OO dogma in the language is just mandating one to put extra complexity into the codebase by denying the programmer the freedom to describe the problem in the simplest way.

    A good programming language should be like good philosophy i.e., give the programmer the tools he needs and get out of the way.

  6. You take one spaghetti code example and turn it to another spaghetti code example. All the code is embarrassing, even the examples you have written. Bad code can be written in any paradigm. And your videos are prefect examples of that…

  7. Object oriented programming is excellent if your programming object represents a real live object, creating classes for hard disk drives, for usb sticks, for graphic card, for pci, for isa, for Uart, for sd card, etc, and making them all fully compatible with one another, will make code in a very easy abstraction manner, hiding the low level complex electronic interfacing binary code, in a way turning an electric circuit that does not comply with human thought to do our bid in a way easily understood by human mind.

  8. Realistically, the motivation for OOP is, in large part, about economics – how fast a company came get a product to market as cost effective as possible. Companies have gravitated to OOP languages like C++, because management has more control over the project and the programmer when the project is broken up into parts. As long as each programmer knows what I/O parameters are passed back and forth, he or she can go off and write their own code. If someone quits or is fired, someone else can be brought in and, fairly easily, pick where the other person left off.

    This was not the case back in the old days of Assembler for IBM 360/370 and such. Back then expensive anti-social, single, nerds, who spoke fluent hexadecimal and binary and grew up entering program code via toggle switches, often wrote long tedious programs in Assembler. They were regarded nearly as gods who, with egos the size of Texas, could (and would) often misbehave without fear of being fired. If a company lost a key programmer, management could risk the whole company going belly-up.

    But really folks! We are talking semantics here. Back in the day what is now called "Objects and Classes" was simply called subroutines and data. I can not imagine one or two programmers trying to write a Windows type OS, with all the GUI, starting from scratch in Assembler. By the time they finished, the product would be obsolete. Writing an new OS in C or Objective-C using hundreds of programmers would turn out a product much more quickly. However, there is this trade off … thing(life is all about the grey area) – the code would be highly inefficient and a Processor hog(like most OSs are today).

    While OOP programs are easier and more quickly written, procedural code is more efficient- less redundant. I realize that much has been done, to make compilers more efficient, but there is only so much that can be done without losing flexibility. I find that my best programs are written in procedural code, while taking advantage of OOP for program organization and easy parameter passing.

    Ultimately, my programs end up being a bunch of procedural code written inside of various "Objects" that I can "Call" (old Assenbler term) when required. Also, I try to keep the "Objects" (subroutines) small so I can store them in a library where they may be re-used in another program.

  9. Ok, those codes were kinda dumb, but let's talk seriously: let's suppose you would code a chess interface. Professional ones can't allow users to make illegal moves. So, you would need to hide the array/matrix of the chessboard, letting a few f()s verify if a move is legal, before execution.
    How would you do that, using PP (procedural prog)? You would have to put in a separate file the chessboard and all related f()s, in order to compile them separately, isolating data, right? Well, in OOP this is an unnecessary overhead: you can just write a class, hidding the chessboard as protected.
    And if months later you decide to expand the thing, in an alternative mode, like the Crazyhouse Chess? This mode adds new rules, but keep the old ones, too. So, its code needs to reach the chessboard directly.
    If you do it trough PP, you have to add the new code in that file, risking to mess an already debugged code. In OOP, all that you need to do is to inherit the old class.
    If you still didn't notice any advantage about using OOP, that's because your projects are too easy and/or small.

  10. Dude I totally feel you. I also feel the same about OO concepts and UML. Why can't we just focus on the thing that is gonna work in real time. Why to just waste the time scaring people with diagrams I mean we waste our time, mind on something so stupid that don't even make sense to be generalized. I am also functional-procedural guy. I mean there may be something that can be easy with it but other than that it makes simplest thing worstly complex. And why to forget it's pretty harsh on memory to even with all the garbage collection. But anyway we have to follow what is it after all. Sad Face 🙁 I wish everything was functional, I'd prove myself a better programmer.

  11. Let data be data? Reminds me of pre OO days of data analysis vs functional analysis. In the bad old days you had data structures that worked with some functions but not others and you rewrote functions over and over again that had many shared parts for slightly different data. And a change to data structure needed to be threaded through a lot of code. That sucks. OO allows expressing common behavior once and then overriding that behavior only where needed. I have seen no function based approach except CLOS that really does this well. But then you are doing type based dispatch of some kind.

    Some of this stuff feels like going backwards.

  12. It is click baiting. I have been doing OO for 30 years and I am quite good at it. Especially things like CLOS. I have seen code bloat a lot when switching from good OO to function based approach. I have tried it a few times and I am not convinced. I also tried the clojure approach and also felt like I was missing useful functionality.

  13. I believe your main point is that OOP is bad because you find it creates unneeded complexities to simple tasks and you find it confusing to understand what's going on in a new code base because of how objects and methods are spread out in a project. Certainly nothing wrong with that, it's a valid reasons to dislike a paradigm.

    I don't think it's OOP that is the issue though. For myself, I find it very clear what's going on and can much more quickly understand an OOP based project vs a purely functional based project. Perhaps the issue isn't that one paradigm is better than the other, but that both are valid and the different styles resonate better with different brains.

  14. To all you idiots yelling "BUT WHAT ABOUT BIG PROJECTS": Let me tell you about Jonathan Blow's games.

    You ever heard of Braid? It's a critically acclaimed video game from 2008 about time travel, and it's actually pretty technically complicated because it stores the state of every entity at every frame. 90 thousand lines of C++ code, all of them procedural. No STL. Runs like a charm on PC, Xbox 360 and PS3.

    You ever heard of The Witness? It's a critically acclaimed video game from 2016 about exploring an abandoned island, and it's got a triple-A scope open world. Several hundred thousand lines of C++ code, all of them procedural. No STL. Runs like a charm on PC and PS4.

    Now, talk to me about how infeasible procedural code is.

  15. Actually there is no need for OOP anywhere. You can't just throw data into conceptual containers and say that mimics the real world. As if the real world is some infallible computing construct to begin with. I still believe OOP was introduced to indoctrinate students into believing evolution is a real thing. Cause nobody I know uses OOP in real life.

  16. i "liked" oop, stuff starts out neat like a brand new car. 😀 but then you use your car, and by the times you get all your stuff in your car that you need… It is like the junk box you haven't looked through for 3 years.

  17. I honestly don’t understand why this video has so many dislikes. While I do agree that the example code Brian used weren’t the best, he did make some solid points.

    I feel like so many of y’all are probably just upset he’s calling something out that most folks are too afraid to call out. (Or maybe your code looks like the example code … IDK.)

    At the end of the day, there’s never one right tool for all jobs. I personally have come to love procedural-style programming for the majority of my code due to writing a lot of JavaScript and C, but I also run into lots of places where OOP feels like the way to go. For example, every time I see C code in which the author tried to write C in OOP-style, I almost always instantly wanna vomit, but in the same way, 99.998% of procedural-style PHP code I’ve seen make me wanna hurt innocent little kittens (I’ve written and seen A LOT of PHP code). I’ve seen horrible Python and Ruby code in both styles. Several folks have mentioned gaming … yes, exactly, OOP is great for that.

    My point is, take your time and pick the right tool depending on the project. I think the problem we have is that so many developers just blindly follow what someone said in a talk and consider them hard rules to follow or “you’re doing it wrong” … that’s very unfortunate, because there are no hard rules, IMO.

    JUST PICK THE RIGHT TOOL FOR THE JOB, DAMMIT.

    All in all, IMO, Brian made some solid points.

  18. People jumping on the bandwagon saying oop is future. OOP is complex. People made it more complex by adding their own stupid lumps on top of other. I am an engineer so, I was introduced to programming with C. Soon, it was time to learn Java and it was fun for first few lecture then it become pain in the ass. The learning curve is just too steep and and there are so many things you need to keep track of. At first I thought this was just me and I was too dumb to get it but no it was hard for everyone. And I think this is not going to work in the future because we will soon need alot of man power in programming sectors. OOP is just too complex and it takes too much time to produce a batch of decent OOP programmers. I think everyone agrees with that. A language that is easy to learn and teach is a must need. This complex mess that OOP is going to fade out soon. There needs to be serious reform in programming sector. I am not saying procedural is better, it has it's own limitations but OPP is not the future at all.

  19. all we needed was UFCS in C++ and we could refactor code to & from OOP … and get the syntactic advantages of the OOP calling style(autocomplete, chaining) with functional/procedural code.

  20. Are you really that stupid?? This are basic examples that only show the concepts.

    If you take the Args example for instance, it's very easy to extend it to lets say 20 arguments, your code instead will look like crap after 10 arguments and all of your if/else branching.

LEAVE A REPLY

Please enter your comment!
Please enter your name here