This really took me back to my Java/C++ classes. It's funny how knowledge can lie dormant and forgotten in your brain, but then with the right little push, you remember all this stuff you thought was long gone.
They shouldn't teach you OOP in high school to begin with. Chances are that they are screwing up your mind with all the wrong ideas about what OOP does.
I would love a smart guy like this to stream or record a video of a simple game development, like pong for example, and explain everything he does in ample details and simplified in the same time. I would sit there for hours with a huge popcorn bag just listening to the guy.
+AnUntitledAbridger I think I could quite easily find 40,000 engineers, philosophers and scientists who would find your assertion that anything, anywhere has no weak points to be, at best, very naive.
+AnUntitledAbridger I am really not trying to hate on you or oop, but actually, I too think that it has some major issues. And the biggest issue is that people don't realize that it actually doesn't help you with anything. Let me explain this: The core principles & ideas behind OOP are Abstraction, Inheritance, Polymorphism, Encapsulation. There are more, like Code-Reuse, but these aren't really core principles, instead they result from the use / implementation of the former principles. The thing is: All these core principles aren't exclusive to oop. They can all independently be used in for example function languages, or procedural / imperative languages. And on top of that, most of the principles are really just subsets of what other paradigms have. Polymorphism for example: Extremely useful, even in OOP. However, OOP only allows you to dynamically dispatch (the key mechanic of polymorphism) on a single argument. Other languages / paradigms, like the relatively new Clojure for example, allow you to dynamically dispatch on an arbitrary selection of arguments (they call it multimethods).
I'm in the middle of redesigning my first proper Python program (a recordable looper for guitar/keyboard etc.) using classes. I typically have upwards of 20 loops running at once and before this I was making them all be nested dictionaries of variables and (ironically) classes coded by another person. It worked but was a horrible mess, and I only wrote them that way because I didn't understand Python classes enough to test them out. It's taking a bit of time to rewrite the program but it's so so so worth it. Code is so much easier to read and operate and is in some cases half the length.
All you need to take away from OOP is the idea of associating a function with a type, so that you can call type_instance.function() easily. Everything else is more trouble than its worth. Especially classical inheritance. And I'm saying this as a game dev. If I can make a whole game with has-a relationships rather than is-a's then you certainly can for business applications.
While I'm a great proponent of OOP, with this I have to absolutely concur. Inheritance is useful in a limited set of circumstances. I've yet to meet the first customer who wants me to write an application featuring Dogs and Cats, both derived from the Pet class. Without going into too much detail, I once had to deal with an application that was so incredibly full of is-a relationships, that a piece of code to read in data (exchange rates, although this is not relevant) had so much binding to other classes and libraries, that by trying to isolate just this class and adding the dependencies, I ended up with a class that calculated sunrise and sunset. Now this was from a developer who had some pretty set ideas, and although he was clever, this intransigence meant that the code was essentially impossible to refactor. The guy would write his own implementations of freaking everything, or at the very least a facade, even if a widely adopted standard existed. Like a logging framework.
"I used to be enamoured of object-oriented programming. I'm now finding myself leaning toward believing that it is a plot designed to destroy joy." - Eric Allman "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - Joe Armstrong
+Yazen Alzaghameem Inheritance does not give you the independence you mention (unless you're implementing interfaces). Inheriting from other classes generally violates encapsulation because the child relies on the parent's implementation details.
The problem with OOP as implemented is that it’s not supposed to be difficult to wrap your head around; it’s not supposed to be more complicated; it’s not supposed to make programming harder. It’s supposed to help manage complexity; it’s supposed to be easier to understand; it’s supposed to make our jobs easier. We should ask why new programmers are intimidated by it. We should ask why has OOP not lived up to the promises.
For me I'm perplexed with semantics involving object design. Should the logic and user interaction come from within main(), or should my objects also have methods for input from user?
It has. People care more about patterns and copying and pasting code than making things easier. OO done correctly makes things easier and reduces code.
9:07 - 9:11 THIS! In my experience (primarily in talking to university classmates and in forums...), the only way people REALLY start to get it is when you START the explanation with this, because that IS what it boils down to. To the uninitiated, OOP sounds like "this complicated, yet magical thing that you can't do without", when in reality, it's more like keeping your room tidy - you still have the same toys, it's just that having them all ordered gives you a different feeling... And chicks dig it better (in general)!
2:28 We could literally stop here, represent the paddles and the ball as maps, and represent their movement on the canvas (new paddles at their new positions) as functions of those maps. Then a game function that uses tail recursion to loop endlessly and call those functions. That's it. No need for OOP, no need to worry about memory at all!
+nERVEcenter117 true, but that doesn't make it a less intuitive example to demonstrate the principle. OOP's upside is when you're interfacing with a game engine that has 1,000-1,500 functions in it, and only a small fraction of those are going to be needed for any one task. You do pay a tidbit in resource load for the convenience, but I haven't met TOO many people who are willing to take the loss.
DFX2KX I don't understand how there would be a disadvantage here in functional style. Languages like F# and Clojure have very convenient namespace semantics, including ways to reference just one or a few functions out of a namespace. Browsing such large codebases tends to be easier than OO languages, because you don't need to look at giant object signatures for the one that contains the methods you want, nor do you have to instantiate that object and deal with referencing it. You just call a function.
I personally prefer using the bank account example that many authors like, because it's easier to explain certain things like inheritance, initialization, and mutators than in the GUI example.
+ElagabalusRex I partially agree. A lot of typical programming class examples don't work out nicely when you try to implement them. Something I notice people often get wrong is a "contains" relationship because it means different things in programming and in reality. A car contains an engine, sure. But this often leads to the conclusion that the car-class should have a property pointing to the engine ("the car-class contains an engine-property"). One may want to implement it that way but whether that actually makes sense in that specific case depends on what the program should do.
One of my favorite channels. I'd like to see him talk about how to do OOD (Object Oriented Design). For instance I'm bogged down right now in making my own classes that represent things like Container, Random and Sort. I don't know whether I'm supposed to write my program such as interaction with the user comes from within main(), or if the user interaction should come from within in the objects. I'm using C++ and this is just a hobby of mine.
Agree and would love to a vid on OOD. I mainly program in java but here are my thoughts: to use sort as an example, I'd have a class that handles the sorting algorithms, with a method that accepts and returns a data structure for each. I'd then have a class that handles the set up of the GUI, stores user input in a data structure, and calls the appropriate method on it. I like to keep the amount of code in the main method to a minimum, and tend to initialize all of my objects in a seperate method within the same class that holds the main method
@@Luca-tw9fk in C++ I'm only doing console programming because it's not user friendly to set up C++ compilers to work with gui frameworks. Even I'm console programming I'm doing what you're suggesting:. A class for sorting, with static methods. Seems overkill to create an object that doesn't have any state or is passed around. Do you mean that within one of your classes you instantiate a number of classes?
@@atlantic_love Any language. A universal sort algorithm is nice, academically speaking... but in practice it doesn't matter. How many hundred different types are you sorting in a single application? And even if you want to sort different types with the same algorithm, then what does it really take? A few function pointers in C. That's it.
In many functional programming languages, access to nontrivial data is also restricted to certain functions. However, FP emphases to keep data as simple and open as possible and functions as general as reasonable.
I feel like there is no way I could have understood this video if I didn't already have basic understanding of 'object oriented programming'. I think these videos have to appeal to ~90% of the viewers, but all it did is explain how to program a pong game to a person who already has some idea of how to do it. (This is assuming the video meant to explain 'Object Oriented Programming' to the general public)
+TheUmbrellaCorpX7 State: Level, EXP, attack, defense, speed, and other attributes Methods: Attacking, taking damage, healing, learning new moves Identity: Even if you have multiple of the same pokemon with the same level and the same moves, they are still separate entities and behave individually. That would be my interpretation of his pokemon analogy.
8:40 "We write the code not in terms of data manipulation, but in terms of telling this object to move up or down." This could be easily done with *procedural language* + contexts. Still, I don't see why migrate to OOP.
Because a bat has an immutable Y-position. You cannot do that in a procedural language, because every part of the program can access every piece of data. That's why.
@@SeverityOne Yes, you can do it in a procedural language. Using while loops, and separate variable names representing state for each paddle and the ball. You'd then have a function that specifically accesses each of those variables and changes their values. By having distinct variable names you mimic immutability. PaddleA_posX, PaddleB_posX.
To make the paddles object orientated, you would need data inside the paddle to store the keys for moving up and down and also operations to allow these key values to be set from outside the object. Also an undraw operation would be helpful.
+kranser You don't need undraw, you just redraw the board (but you need the board object). The keys should not be handled by the paddles but by some input system (what if you wanted to use joystick or Wii?). Which should have its own object.
+Jan Sten Adámek Thanks for the information. If the input is an object in itself, how can the paddle object be duplicated to make 2 objects (same data structure and operations, but unique reference)? I guess the input object would reference the individual paddle objects by unique reference number, correct?
+Tai Le Many people (not just college professors) use the word "paradigm" as a synonym for "approach", which is the real problem. Both "design patterns" and "programming paradigms" are "approaches to solving problems"... But they aim to solve different categories of problems. Nevertheless, due to a simplified vocabulary, it's easy for anyone to get confused. It's like how in physics there's "technically" a difference between "speed" and "velocity" (I'm not sure what it was, but I remember a few Sixty Symbols videos about the fact it was a thing...), but in every day speech, we use the two words as synonyms.
I taught myself how to program basic C++ and sometimes do stuff for fun. Some time ago I made a basic Pong on the Windows CMD. This video will be interesting!
Noe Alvarez ~16. Does it matter? I just did it for fun! :) It was a challenge to test the limits of the Windows command console... It works pretty well for what it is. I wanted to further improve it, but got bored. Still, it was a nice, short, amateur project with decent results. Here's a link for the code: dl.dropboxusercontent.com/u/43721327/C%2B%2B/PongOld/Pong.cpp Or, also, the executable: dl.dropboxusercontent.com/u/43721327/C%2B%2B/PongOld/Pong.exe You stat the game with the spacebar. W and S control the left paddle, up and down arrowkeys control the right paddle. You have to press repeatedly to move, instead of holding down.
I like to think of objects as something like a television. You interface with the TV through a remote and can change channels etc. However you don't need to know all the work the TV is doing internally to display an image and change the channel etc All you need to know are the functions of the remote..
This has nothing to do with objects or object oriented programming. This is just engineering. You take a complex process, and you create a simple interface for the said process.
I think the statement at around 11:50 that the rest of the program doesn't need to know anything about the object's behaviour should be prefixed by "for a single threaded program" ....
+Hemmeligt Navn I think that's a bit far-fetched, especially for beginners. It should be documented whether a class (or any element of a program) is thread safe. If it's not thread safe and you use multithreading anyways then all bets are off anyways. If it's thread safe then the behaviour should be basically the same as without multithreading. Every call to the "move up" operation moves the paddle up. Calling that operation twice on one thread or once each on two different threads won't change that.
Then in base, of Object Oriented Programming, the shapes or models are the objects or shapes inside shapes are objects of other objects and whatever is then in manipulate are the operations on the objects or something, correct if wrong. Where the object is a program in itself as well and each object has its own identity with own set of rules. A class is a blueprint to all of that also and stuff is and then the computer interprets and then does compile if it makes sense or whatnot.
2:35 of course, this is not what this video is about, but I would be interested in a video about that subject. the way it is shown there, to just adjust the position linearly while the key is pressed, is a kind of naive approach which won't work out as a proper replacement for the paddle controllers where you could turn the knobs and determine yourself how far and how fast you turn it. however, now you want to make a Pong game that is playable and fun with key presses, which only can be ON or OFF, nothing inbetween. usually, the way it is attempted to "solve" this, is by adding some kind of acceleration, so if you only tap the key quickly, it moves just a little bit to allow for fine movement, however the longer you hold it down, the faster it will go. however, what kind of function to use for this acceleration? there are many possibilities. i think this really is an "unsolvable" problem, meaning there is no "proper" way to solve it, but a lot of ways one can go about it which might be "good enough". is there one that is the best? are there differing opinions?
If you want to learn more about OOP, i'd suggest going with a language such as Java, or C#. C++ is fine, but it's not exactly beginner friendly (Considering you are a beginner).
+Bahadır Onur Güdürü I've only seen one example of scratch, involving a cartoon cat, so I don't know how flexible it is. Would you recommend it for a beginner who wants to make a robot respond to a whistle, for example?
Ray Kent I have made a two-player 2D soyuz docking simulator and a basketball game which uses a physics algoritm also made by me. Without any programming experience I made those in 3-4 hours. I am not sure about what it can do, I am not that experienced but I am sure that no-other program can provide you that easyness. I have read somewhere that an arduino can be programmed by Scratch but again I am not sure. So if you want to make games, yes it's useful but if you want to do other programming things it is not apropriate.
We had to program a version of object oriented pong in my computer class using java. It was good fun, but very difficult, so when I saw this video, I had to watch.
I know this wasn't the point of the video, but since both paddles are instances of a single object, how are the controls uniquely defined? Off the top of my head, the most reasonable solution is to create an operation which prompts for contols (which would probably be passed when the object is created). And a supplementary question: It seems like letting "draw" be an operation of the individual object would lead to a lot of visual desync and clutter. Wouldn't it be better to let "draw" be a property of the board so that all objects are updated and drawn simultaneously each frame? In essence, the "draw" operation has to erase the old instance and create the new instance, which usually means the background needs to be re-drawn anyways. I get that you don't always want /all/ of your objects drawn all the time for efficiency, but it would be pretty easy to exclude things based on distance (or any number of other factors).
+VinceOfAllTrades in OOP, when you create an object, you get an instance ID. That instance ID essentially contains the pointers to the individual chunks of RAM it's unique variables are stored in. To give each it's own uniqe controls, you'd just load one 'Paddle' id into a 'var_Left' and the other into a 'Var right' and then have Q and Z do the 'Var Left.moveUp()" and 'var_right.movedown()' respectively. ditto for the other paddle.
The thing I've learned about Object Oriented programming over the years, is that the more I do it, the less I find it makes sense. Not only for the program I'm working on at that time, but for any program. It is something that is very attractive to those who do very little programming, because on the surface it makes a lot of sense. When you actually do it, it makes a lot less sense. When you've used OO for a long while, it makes no sense.
naikrovek I see what you're saying now dude. Like there a bunch of arbitrary rules that can hinder development and rarely help eliminate bugs. You just gotta not be so strict, and loosen up a little. Object oriented is just that, programming using objects as the fundamental module, so don't get caught up in the beurocracy that comes with the silly rules and it's great.
+naikrovek I've used object oriented (one might even say object dependent) programming and scripting languages for awhile. It's not that it makes less sense, but you find that it gets used where you're not gaining much in using it. I'd have a Mesh object, and a bunch of functions in it to load/save/calculate animations, but there are people who'd have objects for the mesh loader, the mesh saver, the animation routines would be their own class...
Well, I'd say that they're doing it wrong. The objects should be made to encapsulate data, and have accompanying functions that operate on that data, not objects that are, in themselves, operations on data stored somewhere else.
DFX2KX Yeah, I do the same, if you're talking about engine architecture. I have a "scene", which contains "entities", and an entity can have a "mesh" (3D vertice data), which can have a "skin", which means textures and shaders. The "mesh" class does everything mesh-related, like loading from files, and the "skin" class loads texture files, and sets up shaders, and so on. The only reason I'd make a "mesh loader" class would be to be able to re-use that bit of code for other things. But on the other hand, I can just copy-paste some functions, instead.
Something that puzzles me with this is that for the game of Pong for example - the draw methods associated with Objects specify 'how' this object is supposed to be drawn, since the actual drawing happens outside of the object, by means of the encapsulating program (in this game, the screen/main class); Am I right in assuming that there should be a draw() method in the encapsulating environment that invokes each individual's object's draw method? Public void Screen() { public static void main() { Ball theball = new Ball(x,y,size,...) Paddle paddle1 = new Paddle(x,y,....) Paddle paddle2 = new Paddle(x,y,...) draw(); } draw(){ theball.draw(); Paddle1.draw(); paddle2.draw(); } } Does this make sense? [yeah the draw should be in an updating method that constantly runs, of course]
Yes and no. You could have a board have an array of objects, with a function that draws them all ( like you described but more expandable), but there could also be another class that keeps a board, and an array of objects, and does object.draw(board), then the board does not need to know of the objects
+Jordy Brinks But don't you want the board to be responsible for drawing the pieces onto it? Take for example a chessboard with cell objects that form the grid - the cells themselves are valid X/Y locations that may be occupied by pieces (also objects). How would you organize the drawing of these elements? How I'd do it is have a main Board Object with a draw method that draws all cells - and each individual cell has a draw that may (if need be) call the draw method of a piece that occupies it (boolean probably), which then drops the X/Y position from that cell into the draw method of the piece. In essence what I'm struggling with is the drawing itself - should you encapsulate only the 'way of drawing it' rather than 'where to draw it' for each object's draw method; and have the 'where' be specified by some mainframe that assigns locations - possibly via a constructor?
Kevin Cleijne they're both valid, and both have merits. It makes sense to have a piece know if it's location. It makes sense to have a piece know it's "pixels". It makes sense the board instead keeps track of positions, and draws the shapes. It all boils down to the same actually. You could say a chessboard cell is an object, and the way you describe the board would be the encompassing class making the piece draw on the cell -> IE the piece gets a cell object and draws itself on it. Or you could say the board draws the object instead. It depends on the perspective. In this video you could say the objects draw themselves onto the board, or you could look at it from the "class that makes this happen" as the main perspective and say it is drawing the objects.
+Jordy Brinks Yeah, in essence it's the same. I just wonder if it wouldn't be best to have an overseer class taking care of some behavior. Should the Ball be aware of it's collisions, or should the overseeing class handle those events instead? The ball shouldn't really know what it collided with since that breaks encapsulation right? Instead I'd want an overseeing class that takes care of collisions, some entity that knows all positions of all elements that are being drawn. It only makes sense then to have that entity take care of the places where objects are drawn.
They really did a lot a ground breaking work to make that game. Pong seems simple now but it was a feat of engineering and science back in the day. Really ingenious stuff.
having a deterministic size for the objects make garbage collection much easier to automate. IE making them strongly typed objects - especially if all your primitives are derived from a single base object.
Thank you Dr Steve, your video was clear and very helpful. However, there is one thing that is confusing me? Given that both the paddle and the ball have an X,Y position, does the:- paddle look out for whether it has hit the ball or the ball look out for whether it has hit the paddle? Perhaps they are equally valid? Many thanks, Pete
I would say the container object (which was forgotten in the video, and has 'Width', 'Height', and 'ContainedObjects') should look out for any two objects which are contained in it colliding either with each other or the container's wall.
If the ball is below the paddle when you try to move the paddle down, wouldn't the paddle and ball need some logic to avoid one being drawn over the other? Where would that logic go?
Do one on JSON :) that one makes objects really easy. Coming from C++ originally what I like about JavaScript is that the classes are already instances: pos = { x: 5, y: 7, moveVert: function myMoveVert(n) { this.y += n; } } pos.moveUp = function() { this.moveVert(1); } pos.moveDown = function() { this.moveVert(-1); }
"Its probably not going to be more then a few hundred lines long" Honestly that sounds like way to much code, even if you'd go completely overboard with OOP
Greater abstraction leads to greater complexity -- more memory consumption and / or more processor time spent running through all the layers of abstraction.
+I. Wyrd the trick is using the least amount of abstraction that you can while still having a modular project. done correctly, it's practically unnoticeable on anything made after the 90's. Taken to extremes, however, and we get Unity.....
It sounds like OOP has advantages because it allows a kind of modularity in the program itself. On the other hand, it seems like it could be more verbose and maybe not the most efficient way of running a program. I'd think that OOP on really limited hardware might be too slow. Do you think they used OOP on that original pong console?
+isaacc7 Well, it all depends on how strongly the programming language enforces the rules (or in other words: how easily you can break them). E.g. C++ does not check the rules when the programme is running which allows it to have almost no overhead so if you programmed the game in C++, it can run on the original console. By contrast, Java checks the rules all the time which has quite a lot of overhead so it won't be possible to run it on such limited hardware. On the other hand, if you make an error in C++, because the rules are not enforced, it may do very weird things which makes it quite hard to figure out what happened. In Java, the programme will crash just as your code tried to break the rules so it's much easier to debug.
+Mike Meyer ooh, someone mentioned arduino! I love it. in context, you understand, cos I can program the chip (uno) at assembler level, but it's a really pragmatic combination, and, as you say, a bit classic C and a bit OO. Avoiding the megabrain scariness of c++.
***** I really don't want to pester you, I assume that if it's an electric motor drone then the energy requirement of the processor is negligeable. I'd be fascinated to hear more, if you have got the time.
+Mike Meyer There's not that much C++ in the Aurdino libs, and plenty of sketch writers avoid classes entirely just to squeeze a tiny bit more out of the abysmally small RAMspace.
I like to the analogy of Space Invaders and Galaxian. Space Invaders could be programmed using a bunch of arrays, x-y values and speed. Galaxian needed a simple AI for the groups to break off and swoop down. That would be far easier using OO.
What is your get opinion of putting get in front of all accessors. This practice comes from Java Beans, but makes the grammar very strange. All of your nouns (and adjectives) turn into verbs: “Get would you like fries with that?“, “What is your get height?”, “if get name equals "root" then …”
Difficult to get your head around it? I started off with Basic, then QBasic, then i had a long pause from programming (regrettably) and then dabbled some with VB 4, 5, 6. My interest in programming only ever took off for real when i started messing with VB.Net and later i converted to C# and only now have i come to some sort of grasp with non object oriented languages. I must say, object oriented programming is what got me into programming for real to begin with.
I feel like this channel needs to have more advanced material. Everything is either a superficial look at stuff being done in the realm of computer science or explanations of super basic concepts. Why can't this channel be more like numberphile where it actually gets into the nitty gritties of things?
Numberphile most cirtianly does not get rigourous with mathematics; maybe it just feels that way because of your skill set? I do agree that computuerphile is shallow as well though. With my ameture understanding of computer science that may show they simplify tghings a little worse here.
+Vaidas Šukauskas In simple (if not over-simplistic) terms, the word "API" refers to the actual "thing" that everyone sees out of your program/library from the outside ("outside" often being "their program/library"), whereas OOP is one way in which this thing could work on the inside.In slightly more technical terms, an API could be just a set of functions (which is not OOP), whereas OOP is how structures like "classes" and similar ones work (and that's another way to create an API).
So much hate for OOP. I actually really like the style of thinking behind oop . Just the fact that you can write a class once and not have to think about the details behind what each method does. It just does what you want it do as an entity. plus it really helps in organizing your code instead of having each method like a block of 100 lines of code , each method can be less than 20 let's say because you have entities and helper methods that'll take care of most things for you. It might not be perfect for all use cases , but for most of the things I've made solutions for it's been helpful. Plus unit testing is like a piece of cake when you have classes. From what I noticed people who hate it , generally are either wanna be pseudo coders who use python to write scripts , functional programmers ( kudos to you and I respect your opinion) , or C/Assembler programs who think that any form of abstraction is nonperformant and slow.
It would probably have a velocity vector. A speed variable could be used as a factor for the velocity, or you'd simply just increase the size of the time-steps to make the ball and paddles move faster
glitchsmasher By speed I mean a speed factor. If you multiply the velocity vector by the speed factor, you can increasing the speed of the ball over time by increasing the speed factor over time. In pong, it's common for the game to get faster and faster.
+Toni T800 The design Dr. Steve came up with was very minimal. But how it'd be done is via adding another operation (they're in fact technically referred to as methods, not operations) for the pad class; e.g: "handle_collision". In your code, you usually then do: pad1.handle_collision(ball) pad2.handle_collision(ball) The handle_collision method will reach out to see the ball's position and size, and see if the ball intersects with the box its position and size makes. If true, the operation will reverse the x-speed there.
+Toni T800 Definitely not shared variables. One way to do this: There's object 'Pong' which is in charge of gameplay 1. 'Pong' asks paddle, if it collides with ball 2. Paddle asks ball it's position 3. Paddle now knows if it collided and tells result to Pong 4. If collision happened, Pong tells ball to change it's direction
+Jaddua Jones the difference between Java, and say, C and C++, is that Java more or less enforces you to do things via Classes and methods in said classes, whereas you can program an entire C application and only use structs and methods (functions in C). There's some debate as to which approach is better.
If you don't have a proper overview and handle of your program, that's the problem, so don't solve it by using OOP; that will obfuscate the overview further and thereby lessen the ease of modifications and complex code writing. OOP breeds carelessness, half-assed code, and worse comprehension of the underlying logic (making assuming facts and solving problems according to that understanding much more difficult/impossible). If you use the same constant several times, define the constant and share it; not doing so is amateurish and counterproductive to begin with. If you have too many variables to keep track of all the names, give the names a prefix fitting their purpose, eg. DB_EntriesNum or GFX_DisplayWidth (notice usage of capitals for easier readability, might tickle your lowercase variables OCD a little; also notice the very specific and non-cryptic naming so you don't have to go bonkers with comments). Finally, always/rigorously use functions instead of repeating the same code over and over within separate code segments. Simply make sure that you only have to change/modify specific constants/functionality in one place (unless it becomes counter productive, like defining a constant for two adjacent obvious usages of the same number), then you remove the problem that otherwise forces the burden of OOP onto you (less control, less overview, less potential, less production efficiency, less comprehension, less skill development).
+TheMrTape Hear, hear. OOP is a burden unless it's something truly big and complex like an operating system kernel, a game enfine or a desktop environment. In other words, if there's black box, with a lot of internal state with various relations, then it's worth it, not in an application with internal state equivalent to an elevator controller.
+TheMrTape Completely disagree. OOP massively improves type safety, and in fact I find makes it significantly easier to comprehend programs. You provide some vague statements at the beginning and end of your post without explaining any of them. How about actually giving an example of how OOP would breed carelessness, or forces you to have less control or less overview. OOP gives you MORE overview, as it's much easier to see how the basic elements of the program interact with each other. And yes, I do have plenty of experience in both OOP and non-OOP languages. I enjoy programming in C, but I would never make a big end-user desktop application in it. I would in C++, if the low-level access and performance of C++ were desirable.
+TheMrTape In my experience, Object Orientation pays for itself in terms of ease of maintenance. As a program grows, the time wasted by interference between pieces of code that are conceptually unrelated increases and OOP is the best tool to prevent this from being a problem. In fact, I can go a step further and state that object orientation becomes worthwhile for any project that is being developed my multiple people; as simple, well defined interfaces between objects allows two programmers to work completely independently and still create a working product. So, essentially all commercial/academic applications should be written using OOP. The ability to write a program in modules that can be exchanged with one another seamlessly through abstraction is one of the most appealing aspects of object orientation in my opinion; Getting away from having to learn a program before you can improve it is another.
+T Riddle All the languages. You just try to refrain defining a horde of your own objects and their hierarchy "just in case", unless a truly object like subset starts to emerge in your variables and code. Following YAGNI -principle. I generally follow principle that small rewrite once a paradigm is emerging is a lesser evil than adhering to a paradigm that's ill-suited or unnecessary. There's nothing bad in using objects written by others. Done right, they are a fine abstraction for libraries. Even old school languages such as C do OOP on this level all the time. The difference is that in old school languages one generally doesn't think of inheritance before it truly becomes necessary to.
My teachers and peers always praise OOP and hail it as the "only right way" to code, the moment you take off your training wheels, you'll be doing OOP. But I can't be the only one who doesn't like this, right? It seems like it limits one's abilities more than it aids them.
+HOLyPumpgun | Gaming | I don't quite like it, no. I use "OO" languages (I have yet to find a pure OO language, if that says anything about OO) but that's only because I'm extremely used to them. I'm actually designing/writing my own programming language that's procedural, though it MIGHT contain some less OO class kinda things.
take a look at a functional language like clojure, f#, or Scala. there's definitely a steep learning curve to functional languages coming from an OOP background but I promise it's worth learning FP.
@Username and if i find one person that doesn't and bring them to you, are you ready to eat the printout of your comment on a thick A2 paper without ketchup then?
+Vector Hacker I'm aware of the fact that they are not the same, if they were I wouldn't have asked the question. It's just that I've yet to come across an example of something in object oriented code I can't do as easily with what C provides. I presume that these examples are just to simlified for a fair comparison, so I was hoping someone could give me a better example of a situation were object oriented programming has a clear advantage.
+Terrendum here's an example of where it's handy. Doable in C, but a bit handier: have a class called Quarternion. Has a struct of x,y,z,w. you can also pack in some of the more common math functions into the class so you don't have to search too much Quarternion QuartA = Vec4(0,0,1,90); Quarternion QuartB = Vec4(0,1,0,60); QuartA.MultiplyWith(quartB); QuartA.normalize(); stuff like that. or being able to pack all of your graphics routines into a Display object, so that if you ever add OpenGL or DirectX to a project built on the other, it'd be possible to just add a single function to change modes, abstract the change inside the class, and leave the rest of your project untouched. You do pay some for that convenience, however, so it's best to wield it like a scalpel and not a jackhammer.
+DFX2KX Thank you for the example. In C I would define a Quarternion type as a struct of x,y,z,w. Your code example would be: Quarternion* QuartA = Vec4(0,0,1,90); Quarternion* QuartB = Vec4(0,1,0,60); QuartMultiply(QuartA,QuartB); QuartNormalize(QuartA); To keep it all organised I'd put all the Quart functions in a file together. The Display object becomes a file with a couple of includes and maybe some global variables for things like settings/modes. Compile it all to an object file and link it to the main project. Correct me if I'm wrong but other than maybe a pinch of syntactic sugar I don't see the advantage.
You neglected to mention an essential property of the ball: its direction of movement, ie, it's a vector. Also, if it were a real ball, it would have mass, momentum, and a surface area with a coefficient of friction, generating a constantly decelerating force that would interact with the downward force of gravity to continuously alter its direction and velocity. And an even more real ball would have rotational inertia, etc. OOP makes it possible to encapsulate all of this data and processing into a single block of code. As you pointed out, OOP may be overkill for Pong, but not for more realistic simulations involving numerous entities with similar properties. For a more immediate example of OOP, the screen image we are reading is generated from literally hundreds of objects each with its own properties and methods.
Say I was programming a checkers game in object oriented Design, how could the piece know if it jumped another piece.assuming that the pieces know their location.
I'm pretty glad that web front-end development is moving away from OOP to stuff like React and Elm... encapsulated state is pretty nasty to reason about in large scale codebases.
Bad example to choose. Pong - or at least pong clones - were done with hard-wired TTL logic with a few up-down counters and a clock. It was so simple a copy could be made in a shortish evening on the kitchen table. Nary a computer in sight.
Like most tools, OOP has its occasions when it's the right tool for the job, and others where it doesn't really fit. Some parts of your program might be good candidates for it, others, not really. If it's right for that part, then use it. If not, use some other approach. Games are an example of where you might use both object oriented and procedural programming. The sound and graphics systems will be procedural, while the myriad of things in the game world will be objects.
+Roxor128 yeah. The engine interface will usually be class based. or the proedural stuff will be buried in the 'private' functions of the renderer object, with only the command functions to tell it what task it should be doing exposed. Game logic itself is a decent candidate: it's pretty common in level editors for triggers and the like.
I don't think object oriented programming is conceptually challenging. When you start applying odd scopes and private data things get complex quickly. The programmer must on occasion go to great lengths to fight restrictions they place on their own classes in the paranoia necessary for team based projects. I think the most basic way to look at a class is bundled data with methods to manipulate that data. I believe C++ and the like (inspired by C++) have just kept adding "features" and optional rules to the extent that good OOP design is somewhat difficult. One can model OOP styles easily if their language allows first class functions to be bundled with data in a heterogeneous container with some reference to the collection itself. You could even have a "class" that is made of a container of only functions with member data simply being closures.
Yes! OOP is about how the human mind works. With optimising compilers it ends up looking, to the machine, not much different to hand written assembler code. Maybe 20% bigger, maybe 20% slower than the very best achievable by a skilled artisan programmer, but for many applications who cares? There are far more important considerations, in many cases.
Hanniffy Dinn yeah, I think I agree with all the points you made. But, forgive me if you think this is irrelevant, but where are the job opportunities? Most of software development is now human to human skills. Arithmetical calculating got mechanised years ago. Next up? Programming. It's just translation from one language to another, and the target language has no ambiguity. Easy. All of this argument for and against oop will vaporise, just like the manual skills of spinning. OOD (design) will last longer because it pays more attention to humans than to their arbitrary inventions.
Hanniffy Dinn Fascinating! Thanks for that. I'm retired, not "in the market" anymore, but when I was I saw a gradual downgrading of programmers, except for very specialist areas, such as cryptography/security, which scared the management so much that they'd pay a fortune for a proven specialist! Personally, I think that the trend away from making humans talk binary towards allowing them to describe their requirements in other ways will continue, but it's not a simple path. Interesting to hear that there's a huge demand for c++ programmers today, and I'd be interested in hearing your guess about 5 years in the future...
Hanniffy Dinn Thanks for all the info. I'll look into swift and nim out of interest, hope they're both open-source, or whatever. In recent years I've only done a bit of hobby arduino stuff (C-like) on microcontrollers. No more big scale dev for me!
Ray Kent NIM is really interesting and cool, as you can have all the modern features and it compiles into C. So it means you can even program micro controllers if you wanted ! ;-)
This really took me back to my Java/C++ classes. It's funny how knowledge can lie dormant and forgotten in your brain, but then with the right little push, you remember all this stuff you thought was long gone.
funny how you can just access it without calling the memory function of an object of the subclass IT-class of the class lecture first.
This is the best, clearest explanation for OOP I've ever heard. Of only my high school programming teachers had made it that clear.
They shouldn't teach you OOP in high school to begin with. Chances are that they are screwing up your mind with all the wrong ideas about what OOP does.
I spent half a year of college doing object oriented programming in c++, this explanation has made things so clear! cheers!
I would love a smart guy like this to stream or record a video of a simple game development, like pong for example, and explain everything he does in ample details and simplified in the same time. I would sit there for hours with a huge popcorn bag just listening to the guy.
How about another video to demonstrate the weak points of Object Oriented Programming?
+Leo S So a video with nothing in it?
+AnUntitledAbridger I think I could quite easily find 40,000 engineers, philosophers and scientists who would find your assertion that anything, anywhere has no weak points to be, at best, very naive.
+betlamed Oh awesome! I'd love to watch it, do you remember anything about the title of that video?
Would be a pretty short video.
+AnUntitledAbridger I am really not trying to hate on you or oop, but actually, I too think that it has some major issues. And the biggest issue is that people don't realize that it actually doesn't help you with anything. Let me explain this: The core principles & ideas behind OOP are Abstraction, Inheritance, Polymorphism, Encapsulation. There are more, like Code-Reuse, but these aren't really core principles, instead they result from the use / implementation of the former principles. The thing is: All these core principles aren't exclusive to oop. They can all independently be used in for example function languages, or procedural / imperative languages. And on top of that, most of the principles are really just subsets of what other paradigms have. Polymorphism for example: Extremely useful, even in OOP. However, OOP only allows you to dynamically dispatch (the key mechanic of polymorphism) on a single argument. Other languages / paradigms, like the relatively new Clojure for example, allow you to dynamically dispatch on an arbitrary selection of arguments (they call it multimethods).
I really appreciate how you visually explained Object Oriented Programming. This is the first time I'm starting to grasp it.
I'm in the middle of redesigning my first proper Python program (a recordable looper for guitar/keyboard etc.) using classes. I typically have upwards of 20 loops running at once and before this I was making them all be nested dictionaries of variables and (ironically) classes coded by another person. It worked but was a horrible mess, and I only wrote them that way because I didn't understand Python classes enough to test them out. It's taking a bit of time to rewrite the program but it's so so so worth it. Code is so much easier to read and operate and is in some cases half the length.
All you need to take away from OOP is the idea of associating a function with a type, so that you can call type_instance.function() easily. Everything else is more trouble than its worth. Especially classical inheritance.
And I'm saying this as a game dev. If I can make a whole game with has-a relationships rather than is-a's then you certainly can for business applications.
While I'm a great proponent of OOP, with this I have to absolutely concur. Inheritance is useful in a limited set of circumstances. I've yet to meet the first customer who wants me to write an application featuring Dogs and Cats, both derived from the Pet class.
Without going into too much detail, I once had to deal with an application that was so incredibly full of is-a relationships, that a piece of code to read in data (exchange rates, although this is not relevant) had so much binding to other classes and libraries, that by trying to isolate just this class and adding the dependencies, I ended up with a class that calculated sunrise and sunset.
Now this was from a developer who had some pretty set ideas, and although he was clever, this intransigence meant that the code was essentially impossible to refactor. The guy would write his own implementations of freaking everything, or at the very least a facade, even if a widely adopted standard existed. Like a logging framework.
OOP really shines when you have Vector objects and Matrix objects that just know how to be multiplied and added together. So easy!
That's nothing to do with OO, that's operator overloading
"I used to be enamoured of object-oriented programming. I'm now finding myself leaning toward believing that it is a plot designed to destroy joy." - Eric Allman
"The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - Joe Armstrong
+edgeeffect The first quote really says nothing about OOP, and the 2nd seems to be more about programmers than the method they use to program.
Seems like the only people who are not for OOP are the people who do not understand it.
Not trying to say OOP is always recommended.
+Yazen Alzaghameem A lot of people aren't for OOP.
CaesarGamer Explain to me how inheritance is generally bad. Polymorphism + Implementation Independence is bad?
+Yazen Alzaghameem Inheritance does not give you the independence you mention (unless you're implementing interfaces). Inheriting from other classes generally violates encapsulation because the child relies on the parent's implementation details.
The problem with OOP as implemented is that it’s not supposed to be difficult to wrap your head around; it’s not supposed to be more complicated; it’s not supposed to make programming harder. It’s supposed to help manage complexity; it’s supposed to be easier to understand; it’s supposed to make our jobs easier. We should ask why new programmers are intimidated by it. We should ask why has OOP not lived up to the promises.
For me I'm perplexed with semantics involving object design. Should the logic and user interaction come from within main(), or should my objects also have methods for input from user?
It has. People care more about patterns and copying and pasting code than making things easier. OO done correctly makes things easier and reduces code.
That was the greatest crash message ever.
exception: blahblahblah
kernelpanic: blahdiblahdiblah
help!
+Salman Khan peshawar
9:07 - 9:11 THIS! In my experience (primarily in talking to university classmates and in forums...), the only way people REALLY start to get it is when you START the explanation with this, because that IS what it boils down to. To the uninitiated, OOP sounds like "this complicated, yet magical thing that you can't do without", when in reality, it's more like keeping your room tidy - you still have the same toys, it's just that having them all ordered gives you a different feeling... And chicks dig it better (in general)!
I knew that I should use getters and setters but the way it was explained in the video was really good
As house is to blueprint, object is to class. Thanks for simplifying that.
Really helped me understand OOP! Thanks, Computerphile!
2:28 We could literally stop here, represent the paddles and the ball as maps, and represent their movement on the canvas (new paddles at their new positions) as functions of those maps. Then a game function that uses tail recursion to loop endlessly and call those functions. That's it. No need for OOP, no need to worry about memory at all!
+nERVEcenter117 true, but that doesn't make it a less intuitive example to demonstrate the principle. OOP's upside is when you're interfacing with a game engine that has 1,000-1,500 functions in it, and only a small fraction of those are going to be needed for any one task. You do pay a tidbit in resource load for the convenience, but I haven't met TOO many people who are willing to take the loss.
DFX2KX I don't understand how there would be a disadvantage here in functional style. Languages like F# and Clojure have very convenient namespace semantics, including ways to reference just one or a few functions out of a namespace. Browsing such large codebases tends to be easier than OO languages, because you don't need to look at giant object signatures for the one that contains the methods you want, nor do you have to instantiate that object and deal with referencing it. You just call a function.
I personally prefer using the bank account example that many authors like, because it's easier to explain certain things like inheritance, initialization, and mutators than in the GUI example.
+ElagabalusRex
I partially agree. A lot of typical programming class examples don't work out nicely when you try to implement them. Something I notice people often get wrong is a "contains" relationship because it means different things in programming and in reality. A car contains an engine, sure. But this often leads to the conclusion that the car-class should have a property pointing to the engine ("the car-class contains an engine-property"). One may want to implement it that way but whether that actually makes sense in that specific case depends on what the program should do.
One of my favorite channels. I'd like to see him talk about how to do OOD (Object Oriented Design). For instance I'm bogged down right now in making my own classes that represent things like Container, Random and Sort. I don't know whether I'm supposed to write my program such as interaction with the user comes from within main(), or if the user interaction should come from within in the objects. I'm using C++ and this is just a hobby of mine.
Agree and would love to a vid on OOD. I mainly program in java but here are my thoughts: to use sort as an example, I'd have a class that handles the sorting algorithms, with a method that accepts and returns a data structure for each. I'd then have a class that handles the set up of the GUI, stores user input in a data structure, and calls the appropriate method on it. I like to keep the amount of code in the main method to a minimum, and tend to initialize all of my objects in a seperate method within the same class that holds the main method
@@Luca-tw9fk in C++ I'm only doing console programming because it's not user friendly to set up C++ compilers to work with gui frameworks. Even I'm console programming I'm doing what you're suggesting:. A class for sorting, with static methods. Seems overkill to create an object that doesn't have any state or is passed around. Do you mean that within one of your classes you instantiate a number of classes?
@@atlantic_love All of this can be done easily and without any confusion with libraries.
@@lepidoptera9337 What language are you talking about? Which libraries?
@@atlantic_love Any language. A universal sort algorithm is nice, academically speaking... but in practice it doesn't matter. How many hundred different types are you sorting in a single application? And even if you want to sort different types with the same algorithm, then what does it really take? A few function pointers in C. That's it.
In many functional programming languages, access to nontrivial data is also restricted to certain functions. However, FP emphases to keep data as simple and open as possible and functions as general as reasonable.
I feel like there is no way I could have understood this video if I didn't already have basic understanding of 'object oriented programming'. I think these videos have to appeal to ~90% of the viewers, but all it did is explain how to program a pong game to a person who already has some idea of how to do it.
(This is assuming the video meant to explain 'Object Oriented Programming' to the general public)
>assuming the video meant to explain 'Object Oriented Programming'
I think the title suggests otherwise.
4:56 Best Blue Screen/Kernel Panic ever
Ok, now you need to cover functional programming too! :)
I was taught to think about objects as being similar to Pokemon ahah
so if you add a method and you already have for you have to remove one also removing certin methods would require you to visit an old man
***** 151
Dr. Steve Bagley is my favourite hamster.
+TheUmbrellaCorpX7
State: Level, EXP, attack, defense, speed, and other attributes
Methods: Attacking, taking damage, healing, learning new moves
Identity: Even if you have multiple of the same pokemon with the same level and the same moves, they are still separate entities and behave individually.
That would be my interpretation of his pokemon analogy.
+Voussoir And suddenly I feel enlightened :o
I kind of understood objects before, but now I can actually see how useful they can be. Thank you!
Brilliant... Such a great way to tech object oriented programming. It's so simple too. Make a fun simple game, not a school or other boring structure.
SB's facial expression for objects, @5:09, just excellent 'of Objects'
8:40 "We write the code not in terms of data manipulation, but in terms of telling this object to move up or down."
This could be easily done with *procedural language* + contexts.
Still, I don't see why migrate to OOP.
Because a bat has an immutable Y-position. You cannot do that in a procedural language, because every part of the program can access every piece of data. That's why.
@@SeverityOne Yes, you can do it in a procedural language. Using while loops, and separate variable names representing state for each paddle and the ball. You'd then have a function that specifically accesses each of those variables and changes their values. By having distinct variable names you mimic immutability. PaddleA_posX, PaddleB_posX.
To make the paddles object orientated, you would need data inside the paddle to store the keys for moving up and down and also operations to allow these key values to be set from outside the object. Also an undraw operation would be helpful.
+kranser You don't need undraw, you just redraw the board (but you need the board object).
The keys should not be handled by the paddles but by some input system (what if you wanted to use joystick or Wii?). Which should have its own object.
+Jan Sten Adámek Thanks for the information. If the input is an object in itself, how can the paddle object be duplicated to make 2 objects (same data structure and operations, but unique reference)? I guess the input object would reference the individual paddle objects by unique reference number, correct?
kranser Yes, that are the identities he was talking about. The input object will have two references, one for each paddle's identity.
I program a lot it's easy for me to get my head around it, it actually makes things easier.
Great simplified explanation!
Can you do another video explaining Functional Programming?
Did the Inheritance video he mentioned ever get made? Would love to watch that if it hasn’t!
Very helpful video! Could you please explain the MVC paradigm visually the next time?
+Tai Le MVC is hardly a paradigm... it's just one simple case of OOP... a design pattern.
say this to my college professors
+Tai Le Maybe you didn't listen to your college professors carefully enough, because edgeeffect is right.
+Tai Le Many people (not just college professors) use the word "paradigm" as a synonym for "approach", which is the real problem. Both "design patterns" and "programming paradigms" are "approaches to solving problems"... But they aim to solve different categories of problems. Nevertheless, due to a simplified vocabulary, it's easy for anyone to get confused. It's like how in physics there's "technically" a difference between "speed" and "velocity" (I'm not sure what it was, but I remember a few Sixty Symbols videos about the fact it was a thing...), but in every day speech, we use the two words as synonyms.
+boenrobot Velocity is a vector and speed is its modulus IIRC
Much better than the first video on OOP haha
I taught myself how to program basic C++ and sometimes do stuff for fun. Some time ago I made a basic Pong on the Windows CMD. This video will be interesting!
Noe Alvarez ~16. Does it matter? I just did it for fun! :) It was a challenge to test the limits of the Windows command console... It works pretty well for what it is. I wanted to further improve it, but got bored. Still, it was a nice, short, amateur project with decent results.
Here's a link for the code: dl.dropboxusercontent.com/u/43721327/C%2B%2B/PongOld/Pong.cpp
Or, also, the executable: dl.dropboxusercontent.com/u/43721327/C%2B%2B/PongOld/Pong.exe
You stat the game with the spacebar. W and S control the left paddle, up and down arrowkeys control the right paddle. You have to press repeatedly to move, instead of holding down.
i didnt know you could do this in the command console. what page did you learn this from? i only code maths and strategy oriented programs.
***** Thanks, I'll check it out.
I like to think of objects as something like a television. You interface with the TV through a remote and can change channels etc. However you don't need to know all the work the TV is doing internally to display an image and change the channel etc All you need to know are the functions of the remote..
This has nothing to do with objects or object oriented programming. This is just engineering. You take a complex process, and you create a simple interface for the said process.
I got a youtube error at 4:57, where it talks about crashing and shows a BSOD, and thought it was part of the video.
This is a brilliant explanation.
I think the statement at around 11:50 that the rest of the program doesn't need to know anything about the object's behaviour should be prefixed by "for a single threaded program" ....
+Hemmeligt Navn
I think that's a bit far-fetched, especially for beginners. It should be documented whether a class (or any element of a program) is thread safe.
If it's not thread safe and you use multithreading anyways then all bets are off anyways.
If it's thread safe then the behaviour should be basically the same as without multithreading. Every call to the "move up" operation moves the paddle up. Calling that operation twice on one thread or once each on two different threads won't change that.
Then in base, of Object Oriented Programming, the shapes or models are the objects or shapes inside shapes are objects of other objects and whatever is then in manipulate are the operations on the objects or something, correct if wrong. Where the object is a program in itself as well and each object has its own identity with own set of rules. A class is a blueprint to all of that also and stuff is and then the computer interprets and then does compile if it makes sense or whatnot.
2:35 of course, this is not what this video is about, but I would be interested in a video about that subject.
the way it is shown there, to just adjust the position linearly while the key is pressed, is a kind of naive approach which won't work out as a proper replacement for the paddle controllers where you could turn the knobs and determine yourself how far and how fast you turn it.
however, now you want to make a Pong game that is playable and fun with key presses, which only can be ON or OFF, nothing inbetween.
usually, the way it is attempted to "solve" this, is by adding some kind of acceleration, so if you only tap the key quickly, it moves just a little bit to allow for fine movement, however the longer you hold it down, the faster it will go.
however, what kind of function to use for this acceleration? there are many possibilities.
i think this really is an "unsolvable" problem, meaning there is no "proper" way to solve it, but a lot of ways one can go about it which might be "good enough".
is there one that is the best?
are there differing opinions?
If you want to learn more about OOP, i'd suggest going with a language such as Java, or C#. C++ is fine, but it's not exactly beginner friendly (Considering you are a beginner).
Scratch is the best choice for beginners
sloan boyce Yeap
+Bahadır Onur Güdürü I've only seen one example of scratch, involving a cartoon cat, so I don't know how flexible it is. Would you recommend it for a beginner who wants to make a robot respond to a whistle, for example?
Ray Kent I have made a two-player 2D soyuz docking simulator and a basketball game which uses a physics algoritm also made by me. Without any programming experience I made those in 3-4 hours. I am not sure about what it can do, I am not that experienced but I am sure that no-other program can provide you that easyness. I have read somewhere that an arduino can be programmed by Scratch but again I am not sure. So if you want to make games, yes it's useful but if you want to do other programming things it is not apropriate.
Bahadır Onur Güdürü fantastic! Well done, I'll look into it.
We had to program a version of object oriented pong in my computer class using java. It was good fun, but very difficult, so when I saw this video, I had to watch.
Thanks for putting it into words.
why did it take so long to reach this topic of discussion? it's usually one of the first things CS oriented channels cover.
Excellent video.
I know this wasn't the point of the video, but since both paddles are instances of a single object, how are the controls uniquely defined?
Off the top of my head, the most reasonable solution is to create an operation which prompts for contols (which would probably be passed when the object is created).
And a supplementary question: It seems like letting "draw" be an operation of the individual object would lead to a lot of visual desync and clutter. Wouldn't it be better to let "draw" be a property of the board so that all objects are updated and drawn simultaneously each frame? In essence, the "draw" operation has to erase the old instance and create the new instance, which usually means the background needs to be re-drawn anyways. I get that you don't always want /all/ of your objects drawn all the time for efficiency, but it would be pretty easy to exclude things based on distance (or any number of other factors).
+VinceOfAllTrades in OOP, when you create an object, you get an instance ID. That instance ID essentially contains the pointers to the individual chunks of RAM it's unique variables are stored in. To give each it's own uniqe controls, you'd just load one 'Paddle' id into a 'var_Left' and the other into a 'Var right' and then have Q and Z do the 'Var Left.moveUp()" and 'var_right.movedown()' respectively. ditto for the other paddle.
The thing I've learned about Object Oriented programming over the years, is that the more I do it, the less I find it makes sense. Not only for the program I'm working on at that time, but for any program. It is something that is very attractive to those who do very little programming, because on the surface it makes a lot of sense. When you actually do it, it makes a lot less sense. When you've used OO for a long while, it makes no sense.
+naikrovek how?
naikrovek I see what you're saying now dude. Like there a bunch of arbitrary rules that can hinder development and rarely help eliminate bugs. You just gotta not be so strict, and loosen up a little. Object oriented is just that, programming using objects as the fundamental module, so don't get caught up in the beurocracy that comes with the silly rules and it's great.
+naikrovek I've used object oriented (one might even say object dependent) programming and scripting languages for awhile. It's not that it makes less sense, but you find that it gets used where you're not gaining much in using it.
I'd have a Mesh object, and a bunch of functions in it to load/save/calculate animations, but there are people who'd have objects for the mesh loader, the mesh saver, the animation routines would be their own class...
Well, I'd say that they're doing it wrong. The objects should be made to encapsulate data, and have accompanying functions that operate on that data, not objects that are, in themselves, operations on data stored somewhere else.
DFX2KX Yeah, I do the same, if you're talking about engine architecture. I have a "scene", which contains "entities", and an entity can have a "mesh" (3D vertice data), which can have a "skin", which means textures and shaders.
The "mesh" class does everything mesh-related, like loading from files, and the "skin" class loads texture files, and sets up shaders, and so on.
The only reason I'd make a "mesh loader" class would be to be able to re-use that bit of code for other things. But on the other hand, I can just copy-paste some functions, instead.
Something that puzzles me with this is that for the game of Pong for example - the draw methods associated with Objects specify 'how' this object is supposed to be drawn, since the actual drawing happens outside of the object, by means of the encapsulating program (in this game, the screen/main class); Am I right in assuming that there should be a draw() method in the encapsulating environment that invokes each individual's object's draw method?
Public void Screen() {
public static void main() {
Ball theball = new Ball(x,y,size,...)
Paddle paddle1 = new Paddle(x,y,....)
Paddle paddle2 = new Paddle(x,y,...)
draw();
}
draw(){
theball.draw();
Paddle1.draw();
paddle2.draw();
}
}
Does this make sense? [yeah the draw should be in an updating method that constantly runs, of course]
Yes and no. You could have a board have an array of objects, with a function that draws them all ( like you described but more expandable), but there could also be another class that keeps a board, and an array of objects, and does object.draw(board), then the board does not need to know of the objects
+Jordy Brinks But don't you want the board to be responsible for drawing the pieces onto it? Take for example a chessboard with cell objects that form the grid - the cells themselves are valid X/Y locations that may be occupied by pieces (also objects). How would you organize the drawing of these elements?
How I'd do it is have a main Board Object with a draw method that draws all cells - and each individual cell has a draw that may (if need be) call the draw method of a piece that occupies it (boolean probably), which then drops the X/Y position from that cell into the draw method of the piece.
In essence what I'm struggling with is the drawing itself - should you encapsulate only the 'way of drawing it' rather than 'where to draw it' for each object's draw method; and have the 'where' be specified by some mainframe that assigns locations - possibly via a constructor?
Kevin Cleijne they're both valid, and both have merits. It makes sense to have a piece know if it's location. It makes sense to have a piece know it's "pixels". It makes sense the board instead keeps track of positions, and draws the shapes.
It all boils down to the same actually. You could say a chessboard cell is an object, and the way you describe the board would be the encompassing class making the piece draw on the cell -> IE the piece gets a cell object and draws itself on it. Or you could say the board draws the object instead. It depends on the perspective.
In this video you could say the objects draw themselves onto the board, or you could look at it from the "class that makes this happen" as the main perspective and say it is drawing the objects.
+Jordy Brinks Yeah, in essence it's the same. I just wonder if it wouldn't be best to have an overseer class taking care of some behavior. Should the Ball be aware of it's collisions, or should the overseeing class handle those events instead? The ball shouldn't really know what it collided with since that breaks encapsulation right? Instead I'd want an overseeing class that takes care of collisions, some entity that knows all positions of all elements that are being drawn. It only makes sense then to have that entity take care of the places where objects are drawn.
Directly referencing an object's data without using its interface? That's a paddlin'.
I don’t get it.
@@pumpkinot9900
public int a;
return this.a;
vs
private int a;
public int getA() { return this.a; }
make everything as private as possible
Such a simple game with not as simple code.
Nah it's p. simple
They really did a lot a ground breaking work to make that game. Pong seems simple now but it was a feat of engineering and science back in the day. Really ingenious stuff.
+youdontknowxpand he said "not as simple code". compared to a ball bouncing back and forth it is "not AS simple".
+Alexander Bollbach
It barely qualified as "code" at all. It's like calling a wiring diagram code.
what qualifies as "code" to you
yay for data oriented programming
what other types are out there?
why does the paddle go up at 2:47 ?
having a deterministic size for the objects make garbage collection much easier to automate. IE making them strongly typed objects - especially if all your primitives are derived from a single base object.
Thank you Dr Steve, your video was clear and very helpful. However, there is one thing that is confusing me?
Given that both the paddle and the ball have an X,Y position, does the:-
paddle look out for whether it has hit the ball or
the ball look out for whether it has hit the paddle?
Perhaps they are equally valid?
Many thanks,
Pete
I would say the container object (which was forgotten in the video, and has 'Width', 'Height', and 'ContainedObjects') should look out for any two objects which are contained in it colliding either with each other or the container's wall.
If the ball is below the paddle when you try to move the paddle down, wouldn't the paddle and ball need some logic to avoid one being drawn over the other? Where would that logic go?
Do one on JSON :) that one makes objects really easy. Coming from C++ originally what I like about JavaScript is that the classes are already instances:
pos = {
x: 5,
y: 7,
moveVert: function myMoveVert(n) { this.y += n; }
}
pos.moveUp = function() { this.moveVert(1); }
pos.moveDown = function() { this.moveVert(-1); }
I think that's called prototype based programming rather than class based.
"Its probably not going to be more then a few hundred lines long"
Honestly that sounds like way to much code, even if you'd go completely overboard with OOP
Is this what runs the machine that goes "PING!"?
I
12:34 to which video was the audio in sync with??
The singularity (bottom - right)
@@A0411Prem thanks
> _" The singularity (bottom - right) "_
+Computerphile The jump clips in the endroll are not linked to the videos they show.
How about videos on Protocol Oriented Programming, after this series concludes?
Greater abstraction leads to greater complexity -- more memory consumption and / or more processor time spent running through all the layers of abstraction.
which is exactly why we should write in binary machine code. Pardon the sarcasm, I'm not wanting to be really nasty.
+I. Wyrd the trick is using the least amount of abstraction that you can while still having a modular project. done correctly, it's practically unnoticeable on anything made after the 90's.
Taken to extremes, however, and we get Unity.....
It sounds like OOP has advantages because it allows a kind of modularity in the program itself. On the other hand, it seems like it could be more verbose and maybe not the most efficient way of running a program. I'd think that OOP on really limited hardware might be too slow. Do you think they used OOP on that original pong console?
+isaacc7 Well, it all depends on how strongly the programming language enforces the rules (or in other words: how easily you can break them). E.g. C++ does not check the rules when the programme is running which allows it to have almost no overhead so if you programmed the game in C++, it can run on the original console. By contrast, Java checks the rules all the time which has quite a lot of overhead so it won't be possible to run it on such limited hardware. On the other hand, if you make an error in C++, because the rules are not enforced, it may do very weird things which makes it quite hard to figure out what happened. In Java, the programme will crash just as your code tried to break the rules so it's much easier to debug.
+Mike Meyer ooh, someone mentioned arduino! I love it. in context, you understand, cos I can program the chip (uno) at assembler level, but it's a really pragmatic combination, and, as you say, a bit classic C and a bit OO. Avoiding the megabrain scariness of c++.
***** I forgot to ask... what kind of project?
***** I really don't want to pester you, I assume that if it's an electric motor drone then the energy requirement of the processor is negligeable. I'd be fascinated to hear more, if you have got the time.
+Mike Meyer There's not that much C++ in the Aurdino libs, and plenty of sketch writers avoid classes entirely just to squeeze a tiny bit more out of the abysmally small RAMspace.
I like to the analogy of Space Invaders and Galaxian. Space Invaders could be programmed using a bunch of arrays, x-y values and speed. Galaxian needed a simple AI for the groups to break off and swoop down. That would be far easier using OO.
What is your get opinion of putting get in front of all accessors. This practice comes from Java Beans, but makes the grammar very strange. All of your nouns (and adjectives) turn into verbs: “Get would you like fries with that?“, “What is your get height?”, “if get name equals "root" then …”
Difficult to get your head around it?
I started off with Basic, then QBasic, then i had a long pause from programming (regrettably) and then dabbled some with VB 4, 5, 6.
My interest in programming only ever took off for real when i started messing with VB.Net and later i converted to C# and only now have i come to some sort of grasp with non object oriented languages.
I must say, object oriented programming is what got me into programming for real to begin with.
I feel like this channel needs to have more advanced material. Everything is either a superficial look at stuff being done in the realm of computer science or explanations of super basic concepts. Why can't this channel be more like numberphile where it actually gets into the nitty gritties of things?
nou
Numberphile most cirtianly does not get rigourous with mathematics; maybe it just feels that way because of your skill set? I do agree that computuerphile is shallow as well though. With my ameture understanding of computer science that may show they simplify tghings a little worse here.
By the way, the screen would not be only represented by the computer, because what happens to the ball when it goes off the top/bottom of the screen?
please explain declarative programming
How OOP is related to APIs? On the surface they seem to be very much related concepts, with main difference being scale?
+Vaidas Šukauskas In simple (if not over-simplistic) terms, the word "API" refers to the actual "thing" that everyone sees out of your program/library from the outside ("outside" often being "their program/library"), whereas OOP is one way in which this thing could work on the inside.In slightly more technical terms, an API could be just a set of functions (which is not OOP), whereas OOP is how structures like "classes" and similar ones work (and that's another way to create an API).
+boenrobot and now and again, you'll have APIs that take a bit from both collums, which is arguably more confusing then it needs to be....
This is great, more like this!
*To move player 1 paddle "up":* paddle1._ypos = paddle1._ypos - 1
So much hate for OOP. I actually really like the style of thinking behind oop . Just the fact that you can write a class once and not have to think about the details behind what each method does. It just does what you want it do as an entity.
plus it really helps in organizing your code instead of having each method like a block of 100 lines of code , each method can be less than 20 let's say because you have entities and helper methods that'll take care of most things for you.
It might not be perfect for all use cases , but for most of the things I've made solutions for it's been helpful. Plus unit testing is like a piece of cake when you have classes.
From what I noticed people who hate it , generally are either wanna be pseudo coders who use python to write scripts , functional programmers ( kudos to you and I respect your opinion) , or C/Assembler programs who think that any form of abstraction is nonperformant and slow.
Wouldn't the ball have either a Velocity variable that also stores the balls direction? Or even a separate direction variable alongside speed?
It would probably have a velocity vector. A speed variable could be used as a factor for the velocity, or you'd simply just increase the size of the time-steps to make the ball and paddles move faster
+Willy Goat Speed with direction? That's velocity. You just said my point.
glitchsmasher By speed I mean a speed factor. If you multiply the velocity vector by the speed factor, you can increasing the speed of the ball over time by increasing the speed factor over time. In pong, it's common for the game to get faster and faster.
glitchsmasher
Speed * Direction = Velocity
So maybe we mean the same thing
But how does the ball object interact with paddle object?
Do they share common variables?
+Toni T800 The design Dr. Steve came up with was very minimal. But how it'd be done is via adding another operation (they're in fact technically referred to as methods, not operations) for the pad class; e.g: "handle_collision". In your code, you usually then do:
pad1.handle_collision(ball)
pad2.handle_collision(ball)
The handle_collision method will reach out to see the ball's position and size, and see if the ball intersects with the box its position and size makes. If true, the operation will reverse the x-speed there.
+Toni T800 Definitely not shared variables. One way to do this:
There's object 'Pong' which is in charge of gameplay
1. 'Pong' asks paddle, if it collides with ball
2. Paddle asks ball it's position
3. Paddle now knows if it collided and tells result to Pong
4. If collision happened, Pong tells ball to change it's direction
I don't know much about programming; I just kind of do it. So I'm curious, is this like a class or an object in something like Java?
+Jaddua Jones Java is probably the canonical example of an object-oriented language.
I see! Thank you all for clearing that up!
+Jaddua Jones the difference between Java, and say, C and C++, is that Java more or less enforces you to do things via Classes and methods in said classes, whereas you can program an entire C application and only use structs and methods (functions in C). There's some debate as to which approach is better.
DFX2KX Thanks for clearing that up!
this guy is writing on ancient paper from a time where printers made loud noises.
Forgive me for saying this, but Prof. Bagley reminds me of Bob from the Tekken fighting game franchise.
If you don't have a proper overview and handle of your program, that's the problem, so don't solve it by using OOP; that will obfuscate the overview further and thereby lessen the ease of modifications and complex code writing. OOP breeds carelessness, half-assed code, and worse comprehension of the underlying logic (making assuming facts and solving problems according to that understanding much more difficult/impossible). If you use the same constant several times, define the constant and share it; not doing so is amateurish and counterproductive to begin with. If you have too many variables to keep track of all the names, give the names a prefix fitting their purpose, eg. DB_EntriesNum or GFX_DisplayWidth (notice usage of capitals for easier readability, might tickle your lowercase variables OCD a little; also notice the very specific and non-cryptic naming so you don't have to go bonkers with comments). Finally, always/rigorously use functions instead of repeating the same code over and over within separate code segments. Simply make sure that you only have to change/modify specific constants/functionality in one place (unless it becomes counter productive, like defining a constant for two adjacent obvious usages of the same number), then you remove the problem that otherwise forces the burden of OOP onto you (less control, less overview, less potential, less production efficiency, less comprehension, less skill development).
+TheMrTape
Hear, hear. OOP is a burden unless it's something truly big and complex like an operating system kernel, a game enfine or a desktop environment.
In other words, if there's black box, with a lot of internal state with various relations, then it's worth it, not in an application with internal state equivalent to an elevator controller.
+Tanooki100 so what languages are there for these simpler apps? They all seem to be object orientated
+TheMrTape Completely disagree. OOP massively improves type safety, and in fact I find makes it significantly easier to comprehend programs.
You provide some vague statements at the beginning and end of your post without explaining any of them. How about actually giving an example of how OOP would breed carelessness, or forces you to have less control or less overview. OOP gives you MORE overview, as it's much easier to see how the basic elements of the program interact with each other.
And yes, I do have plenty of experience in both OOP and non-OOP languages. I enjoy programming in C, but I would never make a big end-user desktop application in it. I would in C++, if the low-level access and performance of C++ were desirable.
+TheMrTape In my experience, Object Orientation pays for itself in terms of ease of maintenance. As a program grows, the time wasted by interference between pieces of code that are conceptually unrelated increases and OOP is the best tool to prevent this from being a problem. In fact, I can go a step further and state that object orientation becomes worthwhile for any project that is being developed my multiple people; as simple, well defined interfaces between objects allows two programmers to work completely independently and still create a working product. So, essentially all commercial/academic applications should be written using OOP. The ability to write a program in modules that can be exchanged with one another seamlessly through abstraction is one of the most appealing aspects of object orientation in my opinion; Getting away from having to learn a program before you can improve it is another.
+T Riddle
All the languages. You just try to refrain defining a horde of your own objects and their hierarchy "just in case", unless a truly object like subset starts to emerge in your variables and code. Following YAGNI -principle.
I generally follow principle that small rewrite once a paradigm is emerging is a lesser evil than adhering to a paradigm that's ill-suited or unnecessary.
There's nothing bad in using objects written by others. Done right, they are a fine abstraction for libraries. Even old school languages such as C do OOP on this level all the time.
The difference is that in old school languages one generally doesn't think of inheritance before it truly becomes necessary to.
My teachers and peers always praise OOP and hail it as the "only right way" to code, the moment you take off your training wheels, you'll be doing OOP.
But I can't be the only one who doesn't like this, right? It seems like it limits one's abilities more than it aids them.
I agree. Most of these people don't even know what Functional programming is...
+HOLyPumpgun | Gaming | I don't quite like it, no. I use "OO" languages (I have yet to find a pure OO language, if that says anything about OO) but that's only because I'm extremely used to them. I'm actually designing/writing my own programming language that's procedural, though it MIGHT contain some less OO class kinda things.
Kai Kyouretsu Well hat sure sounds interesting. You have a name for it yet?
take a look at a functional language like clojure, f#, or Scala. there's definitely a steep learning curve to functional languages coming from an OOP background but I promise it's worth learning FP.
HOLyPumpgun | Gaming | calling it Score
geez, what kind of razor does dr bagley use? skin so smooth i thought he was computer generated. 6:54
2:49
It's far more elegant to say:
if key "q" then:
paddle1_ypos += 1
+Deltaexio That would confuse people who don't know what += does in programming.
For the same reason using "paddle1_ypos++;" would not be prudent.
+Deltaexio and Pythonic ;)
+Deltaexio No because once the object is ready you can just say
if key"q" then:
paddle1.go_up
if key"a" then:
paddle1.go_down
***** You'd still use some arithmetic inside your methods.
And those should be called "goUp" and "goDown", by the way :P
@Username and if i find one person that doesn't and bring them to you, are you ready to eat the printout of your comment on a thick A2 paper without ketchup then?
"So many different terms; objects sending messages to other objects... And, well, not much else happening. In fact, that's the only thing"
Is there any advantage of classes over C's object files?
+Vector Hacker I'm aware of the fact that they are not the same, if they were I wouldn't have asked the question. It's just that I've yet to come across an example of something in object oriented code I can't do as easily with what C provides. I presume that these examples are just to simlified for a fair comparison, so I was hoping someone could give me a better example of a situation were object oriented programming has a clear advantage.
+Terrendum here's an example of where it's handy. Doable in C, but a bit handier:
have a class called Quarternion. Has a struct of x,y,z,w. you can also pack in some of the more common math functions into the class so you don't have to search too much
Quarternion QuartA = Vec4(0,0,1,90);
Quarternion QuartB = Vec4(0,1,0,60);
QuartA.MultiplyWith(quartB);
QuartA.normalize();
stuff like that. or being able to pack all of your graphics routines into a Display object, so that if you ever add OpenGL or DirectX to a project built on the other, it'd be possible to just add a single function to change modes, abstract the change inside the class, and leave the rest of your project untouched.
You do pay some for that convenience, however, so it's best to wield it like a scalpel and not a jackhammer.
+DFX2KX Thank you for the example.
In C I would define a Quarternion type as a struct of x,y,z,w. Your code example would be:
Quarternion* QuartA = Vec4(0,0,1,90);
Quarternion* QuartB = Vec4(0,1,0,60);
QuartMultiply(QuartA,QuartB);
QuartNormalize(QuartA);
To keep it all organised I'd put all the Quart functions in a file together.
The Display object becomes a file with a couple of includes and maybe some global variables for things like settings/modes.
Compile it all to an object file and link it to the main project.
Correct me if I'm wrong but other than maybe a pinch of syntactic sugar I don't see the advantage.
I clicked on this video because the thumbnail clearly showed that it was about the old "Simon Says" game from my childhood. I was disappointed.
You neglected to mention an essential property of the ball: its direction of movement, ie, it's a vector. Also, if it were a real ball, it would have mass, momentum, and a surface area with a coefficient of friction, generating a constantly decelerating force that would interact with the downward force of gravity to continuously alter its direction and velocity. And an even more real ball would have rotational inertia, etc. OOP makes it possible to encapsulate all of this data and processing into a single block of code. As you pointed out, OOP may be overkill for Pong, but not for more realistic simulations involving numerous entities with similar properties. For a more immediate example of OOP, the screen image we are reading is generated from literally hundreds of objects each with its own properties and methods.
Could the volume of these videos be ANY lower?
Say I was programming a checkers game in object oriented Design, how could the piece know if it jumped another piece.assuming that the pieces know their location.
You'd have, on a larger scope, a checkers board object holding the position (square) of each piece.
8:28 - not exactly true. In many programing languages, if the attribute is public, you can access the attributes without functions.
But that's why you don't make them public, because it breaks the encapsulation. The language allows it, but the paradigm doesn't.
I'm pretty glad that web front-end development is moving away from OOP to stuff like React and Elm... encapsulated state is pretty nasty to reason about in large scale codebases.
Bad example to choose.
Pong - or at least pong clones - were done with hard-wired TTL logic with a few up-down counters and a clock. It was so simple a copy could be made in a shortish evening on the kitchen table. Nary a computer in sight.
Ironically, the original Pong arcade game was implemented entirely using logic gates. No CPU or software was used in the implementation.
I missed Steve Bagley.
Like most tools, OOP has its occasions when it's the right tool for the job, and others where it doesn't really fit. Some parts of your program might be good candidates for it, others, not really. If it's right for that part, then use it. If not, use some other approach.
Games are an example of where you might use both object oriented and procedural programming. The sound and graphics systems will be procedural, while the myriad of things in the game world will be objects.
+Roxor128 yeah. The engine interface will usually be class based. or the proedural stuff will be buried in the 'private' functions of the renderer object, with only the command functions to tell it what task it should be doing exposed. Game logic itself is a decent candidate: it's pretty common in level editors for triggers and the like.
thank you oop vs functional which is better in what situation
I don't think object oriented programming is conceptually challenging. When you start applying odd scopes and private data things get complex quickly. The programmer must on occasion go to great lengths to fight restrictions they place on their own classes in the paranoia necessary for team based projects. I think the most basic way to look at a class is bundled data with methods to manipulate that data. I believe C++ and the like (inspired by C++) have just kept adding "features" and optional rules to the extent that good OOP design is somewhat difficult. One can model OOP styles easily if their language allows first class functions to be bundled with data in a heterogeneous container with some reference to the collection itself. You could even have a "class" that is made of a container of only functions with member data simply being closures.
It's get interesting when you are compiling OOP into assembly language. It all needs to work like that in the end....
Yes! OOP is about how the human mind works. With optimising compilers it ends up looking, to the machine, not much different to hand written assembler code. Maybe 20% bigger, maybe 20% slower than the very best achievable by a skilled artisan programmer, but for many applications who cares? There are far more important considerations, in many cases.
Hanniffy Dinn yeah, I think I agree with all the points you made. But, forgive me if you think this is irrelevant, but where are the job opportunities? Most of software development is now human to human skills. Arithmetical calculating got mechanised years ago. Next up? Programming. It's just translation from one language to another, and the target language has no ambiguity. Easy. All of this argument for and against oop will vaporise, just like the manual skills of spinning. OOD (design) will last longer because it pays more attention to humans than to their arbitrary inventions.
Hanniffy Dinn Fascinating! Thanks for that. I'm retired, not "in the market" anymore, but when I was I saw a gradual downgrading of programmers, except for very specialist areas, such as cryptography/security, which scared the management so much that they'd pay a fortune for a proven specialist! Personally, I think that the trend away from making humans talk binary towards allowing them to describe their requirements in other ways will continue, but it's not a simple path. Interesting to hear that there's a huge demand for c++ programmers today, and I'd be interested in hearing your guess about 5 years in the future...
Hanniffy Dinn Thanks for all the info. I'll look into swift and nim out of interest, hope they're both open-source, or whatever. In recent years I've only done a bit of hobby arduino stuff (C-like) on microcontrollers. No more big scale dev for me!
Ray Kent NIM is really interesting and cool, as you can have all the modern features and it compiles into C. So it means you can even program micro controllers if you wanted !
;-)
They need to do one in the BSOD. I wonder why it isn't green or red for example. Also the origin of it
I ❤️ OOP