This series is very well done. As most developers (myself included) have tried and failed to explain our field it is wonderful to see you succeed. Keep it up.
Software Engineer here, great overview of what I love to do everyday! However, one critique on the video would be that often programmers do "check out" the same code (or file) and are able to both commit their code after they've safely merged their changes together. We use text/code merging software to make our jobs easier such as the popular Beyond Compare or many other great tools. Keep up the awesome videos!
I'm not sure that would be ideal. Yeah, sometimes there's some nasty merge conflicts that take a little while to work out, but the alternative is having to delay changes, and possibly running into times where someone on the team can't do anything because their locked out of all the files they need to change. Then again, explaining how pull-requests, merging and conflict resolution works might be a little do in-depth for a "crash course" video.
Absolutely, to your latter point. It took me quite a while before I felt I really had a good handle on pulling and merging and pushing and all in a repository. Though half of that I'd argue is because Perforce is good at getting confused (Like when I merge changes down to my stream and find out that apparently I made all of those changes myself and need to push them upwards)
The first priority should be making sure the code itself is clear. As in, things are named clearly, it's clearly formatted, things are done in a way that's obvious to readers. If the task at hand can't be done that way, then a comment explaining WHY the code is that way is good practice. There may be historical or institutional reasons some code had to be written a certain way that's won't be obvious in the code itself. Also, if you're writing a library, usage docs and examples are really helpful, as well as the intent of the library. TLDR; comments should focus on WHY not how, and should not be a cover for poor coding practices, but illuminate things that one would not be able to ascertain from reading the code itself.
comment EVERYTHING, you don't have to repeat comments but every unique line, block, function ,object etc should be commented. Think of it this way, there are a hundred ways to take in user input, and a hundred more to manipulate that data, you can never be sure anyone has used the method you have before however if you explain it once you don't need to worry about it after that. Anyone can sit and nut out your code, it's just not time efficient, this is the main purpose of comments.
Version control software comes in many forms, and historically were mostly centralized in the way that darthjoey91 described, and does indeed sometimes involve "checking out" files. Only one user at a time is allowed to have a file "checked out", and after they check it back in, the next person who checks it out is expected to start by editing what the last user checked back in. Such systems are getting rarer all the time because it makes concurrent work on the same file very difficult, and now Git, a distributed (rather than centralized) version control system, is the most popular. Unfortunately Git was originally developed solely to manage the Linux kernel, and many of its commands were not thought through with immense care about usability or sense to the general programmer population, so the old term "checkout" was grandfathered into it even though nothing is occurring which is analogous to checking a physical item out of a physical repository - whether "checkout" was chosen because of its similarity to a similar operation in more centralized systems, I can only speculate. Source: I work on GitKraken, a git client that tries to make those commands less confusing.
@@tony91200211 A fair point. Comments could be overly verbose if the functions are small, and use descriptive language. However, as a rule, people do quick things and end up leaving them (i.e. "var test"). I tend to write comments when I feel that the code I'm writing can't describe itself well due to other constraints. However, sometimes going without docs can get you into situations like Dan mentioned.
If you think that’s funny, you should see what I did in my sisters wedding photos. I subtly flicked off the camera in every picture I was in. It got quite the laugh.
Is it just me, or to real software engineers see the comments to this video as mostly a bunch on in-experienced newbies who have learned some buzz-terms and see this an an opportunity to argue theory or what IDE/language is best? As someone who has been designing and building software applications for 15 years, I can tell you that, professionally, what matters is results and the ability to problem solve. For those of you looking to get into software engineering, stop getting so hooked up on ideological debates, language debates or buzz-terms. I don't care if you bought a book that teaches you how to answer 150 programming interview questions that you won't be asked! I'm not going to hire you if you can't demonstrate ability to problem solve and deliver a product. Engineering is all about solving problems that someone else hasn't solved yet, it's about learning how to make the code do what you want it to do, with some opportunity to refactor and improve along the way. I look at code I wrote 5 years ago and I think most of it's ridiculously ammature, and yet 5 years ago I was still a senior software developer making over 120k because I was able to solve problems. In the end, business does not deliver software, it delivers service and software drives the service. If you can master the creation of software that does the job and does it well, then you are valuable, you bring value to the cause and you will make a lot of money, and 95% of everything people are saying in the comments will never matter - ever!
Unfortunately, I think what's driving the discord in the comments is that Computer Science (the name of the topic at hand in this series) doesn't really have much of a relation to software engineering in a practical sense. Most of the comments I've read are from a perspective of computer scientists that will spend their entire lives in academia. My guess is that this series has probably attracted the academic computer scientists (the types that don't much care for electronic computers much like Edsger Dijkstra) that would rather discuss the merits of specific programming language characteristics than programmers or software engineers that would simply pick up the languages and use them to solve problems. That's not to say that CS academia is bad. I have great respect for the theoretical CS work that ultimately impacts the lives of the programmers and software engineers. But it does seem to be the perspective of a lot of the comments on this video.
Another real-life software engineer here. This series is great! It's good to finally have a resource I can point people to that explains what I do for a living. That said, I am a bit disappointed that this episode seems to equate "Software Engineering" with OOP. OOP is very popular, yes, but it is only one way of thinking about building complex software systems. One person's class is another person's module, or abstract data type, or closure. If there's going to be a future episode that digs deeper into programming languages, I hope you give a shoutout to functional programming. Its usefulness as a paradigm is evident in the fact that many popular languages support it in some form, so I think it's worth talking about.
6:12 Yes! Anyone new to programming should know that having lots of bugs to fix doesn't mean you're not learning anything, and in fact, helps a lot with the learning experience.
I've been a polyglot developer for some time now and I gotta say, this course is so on point, from the T-shirt easter eggs to the cool Thought Cafe animations, I wish i had this kind of material when I was starting up. good job
At this point I've resigned to just get good at/get used to reading through code to learn what it does. yes it sucks, but this problem isn't going to go away, might as well learn how to live with it eh? At least self-documenting code can make stuff like this easier.
While comments are great, code should be self explanatory. Really only put comments to give a high level overview. Because if you end up commenting every function then that will be 2 things to maintain. When you change the code, you'll have to change the comment as well. And when, not if, you don't then that'll cause confusion that could result in a number of bad things happening.
Something to note about Alpha versions is that it's a lot more common for indie developers to release alphas as they often don't have the resources to do rigorous testing and (especially for game developers) often want feedback from their communities on the direction of the project.
The best programming environment is obviously atom. :) Please note: Be careful when discussing what programming environment you prefer with software developers. It is a quick way to get into long heated arguments. Carry Anne didn't mention this, but in addition to documentation, you should also use good variable names. Instead of calling a list of letters "a", or "list", you should call it "letters", or even better "listOfLetters". If you don't name you functions well, when others go to debug something in your code, they will get a headache. Documentation tells users what a function/object DOES, but good naming conventions will let others know HOW IT WORKS.
I'm really enjoying this Crash Course! Thanks for all the hard work you guys are putting into these, it really shows. Can't wait for more episodes. Cheers
You are wonderful I am a software engineer for 10 years and listening to you explain things so clearly and so sicsintly makes a lot of things fall i n to place. Did I mantion you are wonderful? 😄
This is the most important video in computer science! This and the old "warriors of the net" routing animation should be mandatory viewing in computer classes throughout the nation.
After trying many, and slowly getting the idea, I finally have the best explanation of WHAT , OOP is and WHY, it is used. Thanks Carrie Anne. My kind of teacher.
Great stuff! But what was described is Modular Programming. Everything shown could be done in Ada or Modula-2. As someone already commented, for Object-Oriented Programming you also want polymorphism (different objects implementing methods with the same name, unlike functions where there is one code for one name) and inheritance (where just what an object adds to another object has to be described). The original Simula I, Smalltalk-72 and -74 didn't have inheritance but Simula 67 and Smalltalk-76 added it and this has been a feature of every object-oriented language since.
If it compiles and works, it's all good imho! The only thing that gets my goat with other peoples code is the total lack of comments! and non logical naming!
Dude the non logical naming drives me insane. My friend would sometimes ask me for help with his first two COSI classes in college and it seemed like he intentionally made the names as confusing as possible. Like he's have to do a program that worked with images, then he'd write a for loop and use x as the increment variable, HEIGHT as the x coordinate (no not the y coordinate, and yes i mean coordinate not the total height of the screen) and i for the y coordinate. I'm like are you serious? lol
Just use git filter and clean all \t with space. How many? Doesn't matter - just have a company wide style guide (per language or project - not necessarily universal)
Just a tip: use comments sparingly; your code should be able to stand alone even without comments. Use comments only when there is something that is hard to communicate with the code, there are things to watch out for, etc.
I enjoyed the programming humour in this episode. :) Carrie Anne making it clear she's a vim advocate, and makes a fair point that it's not bad as long as you know how to quit, hehe...
How to generate a random string: Plop a new user in vim and tell them to quit, just throw away the first 15 inputs or so (the alt+F4, esc, ctrl+w "standard" exit commands)
Ah the editor wars. I've used all of these and more... * Turbo Pascal IDE (with WordStar keybindings) * DOS Edit (just a wrapper for QBasic) * Windows Notepad * Emacs/XEmacs * Vi/Vim * Pico/Nano * jEdit * Notepad++ ...and on it goes.
I am have been pretty happy with this series, especially as a way to help explain concepts to my non-software engineer friends. But, this video hits a gripe I have had with the way we teach software engineering and development. OOP is not the same and software engineering. Functional programming and non-hierarchical program organization methodologies exist and are being used pretty pervasively in the industry. Modern Javascript is functional and composable while Haskell, Erlang, and Scala all see use right now in the industry back ending some of the largest sites on the web. As someone who enjoys this type of programming, it is a shame that we don't see it taught enough. Thank you again for making these videos and I hope that you are able to find time in your series to hit on these different methods of abstracting.
One of my colleagues had the philosophy of never documenting code. When asked why, he said it was because programmers are so lazy that when they change the code, they do not change the comments, and inaccurate comments are worse than no comments at all. Also, he and his team handed over their product for porting to another language (Pascal to C) and we asked, "where are the comments?". He replied, "there are 300,000 lines of comments in this code."
Brion Emde So you run P2C and you're done. And by the way, still no comments, except this time they're all wrong because they were written by computer.
I've been writing code for 15 years and that's no excuse to "never" comment. Programmers are not lazy, they are focused - they fix the code because that fixes the problem, if the comments don't get updated then they will get updated or removed in the next refactor. And if you know what you're doing, you're not commenting everywhere anyway. A programmer doesn't need a comment to know what the code does (only students rely on comments) a programmer looks at the code first anyway so see what it's doing, and he may glance at the comments to see what the previous programmer (often himself) was thinking. I tend to comment when I want to tell someone "why" I wrote this code, not what the code does. Rule of thumb, if there's a code-smell add a comment to explain why you wrote it that way, otherwise if the methods/variables are named effectively and you're code isn't bloated, then no comment is really needed.
This was over 30 years ago. We first used an automatic tool by Tata Consulting that automatically translated a huge proportion of the code automatically, but produced code that was judged as unreadable the original authors, so while it became the basis of a product release on one platform, the code was not maintained and another solution to the translation problem was found. That one wasn't able to deal with nested functions in Pascal, so the code had first to be un-nested manually. The tool probably did 60% of the work and the rest was done manually. I forget the names of either tool. No doubt such tools have improved. That Tata tool was actually quite brilliant.
+seasong Documentation is highly dependent on your audience. The Linux kernel only needs documentation for people who want to make changes. Users of the Linux kernel generally do not care how the code works, just that it compiles and they can boot it. Conversely, consider the `git` source control tool. There the interface needs to be clearly documented because of the way users interact with it. It is also much more likely that a user of `git` will want to make a change to the core functionality.
Great overview but I do disagree on one point, commenting code. Your aim is to write code that is self documenting without the use of comments. The reason for this is that as code can change and it can be easy for a bit of code to be changed while the associated comments aren't. The one thing worst then no comments are wrong comments. There are places to put comments, like when describing an API or why your little bit of code looks like it could win a Rube Goldberg competition. But usually, making the code itself clean and concise is the best way to make it understandable. If you want to know more, I recommend Clean Code, The Pragmatic Programmer, or Code Complete 2 and great books to read.
Ohhh, I never really got why I would want to use objects,but in the context of a massive project like office, I suppose it would make it a lot more manageable.
I love the detail in the car example, that we actually see Steve Jobs, standing next to precisely the type of car he drove including his signature missing licence plate (he switched the car every six weeks so he would not need to install a licence plate).
OOPS is called OOPS because of the reasons that you stated here. Thanks for the Series though . . . And one more thing Your Clock Speed needs to be reduced or the voice software code in you has to be calibrated for a little slow output. . . body(Carrie Ann).human.throat.larynx.muscle.speed(......needs to reduce the muscle vibrating speed) //Talking speed . . Remember we humans cannot match the clock speed of the Computer :oD .... Thanks a Ton for such lucid and detailed explanation of so many levels of abstraction.
"Don't be that person" That also applies to over-commenting, I run into too many devs that over-comment their code and comment every public variable and function, it quickly becomes a mess, comments become outdated, and it becomes very hard to read. Seriously, GetPlayerName(Player p) doesn't need a comment, it should be pretty self explanatory. Now, that said, a weird workaround you had to do because of a bug with a compiled library DOES need a comment so it isn't confusing to read.
You guys forgot to talk about process which is another major part of software engineering. Plus you forgot to mention visibility, and Dennis Ritchie, the father of C and all of its derivative languages. Will we ever get at least a nod to the gang of four?
"You guys forgot to talk about process which is another major part of software engineering." Process? Which process? "Plus you forgot to mention... Dennis Ritchie, the father of C and all of its derivative languages." Dennis Ritchie is more well-known for his contributions to operating-systems and programming-language development than software engineering. But I think they did mention him in the OS episode. "Will we ever get at least a nod to the gang of four?" It's called CRASH COURSE computer science for a reason. Most newcomers may not even be familiar with the term "Object-oriented programming", let alone gang-of-4. You can't cover everything.
PSA: In response to the comment at 6:45 ... Please don't "ignore" invalid values in a function. Throw an exception or raise an error so that those of us who use your code don't spend hours trying to find out why nothing works. :)
Yeah wtf was that? :D "Oh you want me to do something, sure, I'll do it!" Later... "- So, did you do the thing?" "-Naaah I didn't, because I couldn't." "-And you were planning on telling me... when?"
In a large company, even when split into smaller teams, you can seldom assume that only you are editing a certain file. Merge conflicts are a commen and natural occurence.
Yeah the "checking out code, just like a book from a library" remark reeks of centralized and concurrent version control, which everybody is (or should be) moving away from. Apart from that, enjoying the series!
While I understand the process of development was generalised for educational purposes, I believe it would have been nice to note that there are a myriad of different ways that code can be stored, affecting the process of collaboration between the developers. Also automated testing for the win.
Software Engineer here, love the series. I have to disagree about comments. Code should be clean and self-documenting. Comments should only be used when the code is not capable of expressing itself, or for APIs being distributed/used off-team. If you think you need a comment, then reevaluate and try refactoring the code. The intention and behavior of code should be described by the tests, methods names, variable names, and class names Domain knowledge should be taught to new team members upon joining via minor documentation outside the code.
“Pretty much every piece of software on your computer, or game running on your console was built using an Object Oriented language” It’s true that many are, but it’s a fiction to think that all are, or that all were designed in an OOP way. Games especially may use C++, but are sometimes written much more closely to C. Especially in large, resource demanding programs. See talks by Jonathan Blow, Casey Muratori, Mike Acton for examples of alternatives. In data science especially functional programming and other paradigms are highly used.
The main ( core ) technology of the age seems to be born from the related ( peripheral ) technology of the former age. For example , agriculture from tool-making , engines from metalworking , and computers from electrical engineering are cited. Then , what will be the mother technology of AI , which is going to mark a next epoch ? I suppose light / quantum computer , neurocomputer or software engineering are the candidates.
4:57 "This ability to hide complexity, and selectively reveal it, is the essence of Object Oriented Programming." -- What?! This series has shaky writing at times, and everyone seems to have a different definition of OOP, but this is about as bad as you could get. One of their own examples, Python, is a counterexample. Not only does Python /not/ strictly enforce a public/private distinction, the mechanism that it does provide (the double underscore) is also available at the module level, where it serves exactly the same purpose in non-OO code.
2019: Just wrote this magnificently sophisticated code. Only two know how this works: Me and God.
2020: Now only god knows.
😂😂
hahahhahaah
I know the struggle wrote some code last month came back to finish.. didn't even recognize it felt like someone else came on my ide and wrote it
Wow! Object Oriented Programming has never been explained so well and in such a short time. Crash course rocks!!
This series is very well done. As most developers (myself included) have tried and failed to explain our field it is wonderful to see you succeed. Keep it up.
The more I watch this series, the more the "a new level of abstraction" animation makes sense to me.
Software Engineer here, great overview of what I love to do everyday! However, one critique on the video would be that often programmers do "check out" the same code (or file) and are able to both commit their code after they've safely merged their changes together. We use text/code merging software to make our jobs easier such as the popular Beyond Compare or many other great tools. Keep up the awesome videos!
I'm not sure that would be ideal. Yeah, sometimes there's some nasty merge conflicts that take a little while to work out, but the alternative is having to delay changes, and possibly running into times where someone on the team can't do anything because their locked out of all the files they need to change.
Then again, explaining how pull-requests, merging and conflict resolution works might be a little do in-depth for a "crash course" video.
Absolutely, to your latter point. It took me quite a while before I felt I really had a good handle on pulling and merging and pushing and all in a repository. Though half of that I'd argue is because Perforce is good at getting confused (Like when I merge changes down to my stream and find out that apparently I made all of those changes myself and need to push them upwards)
The first priority should be making sure the code itself is clear. As in, things are named clearly, it's clearly formatted, things are done in a way that's obvious to readers. If the task at hand can't be done that way, then a comment explaining WHY the code is that way is good practice. There may be historical or institutional reasons some code had to be written a certain way that's won't be obvious in the code itself. Also, if you're writing a library, usage docs and examples are really helpful, as well as the intent of the library.
TLDR; comments should focus on WHY not how, and should not be a cover for poor coding practices, but illuminate things that one would not be able to ascertain from reading the code itself.
comment EVERYTHING, you don't have to repeat comments but every unique line, block, function ,object etc should be commented. Think of it this way, there are a hundred ways to take in user input, and a hundred more to manipulate that data, you can never be sure anyone has used the method you have before however if you explain it once you don't need to worry about it after that. Anyone can sit and nut out your code, it's just not time efficient, this is the main purpose of comments.
Version control software comes in many forms, and historically were mostly centralized in the way that darthjoey91 described, and does indeed sometimes involve "checking out" files. Only one user at a time is allowed to have a file "checked out", and after they check it back in, the next person who checks it out is expected to start by editing what the last user checked back in.
Such systems are getting rarer all the time because it makes concurrent work on the same file very difficult, and now Git, a distributed (rather than centralized) version control system, is the most popular. Unfortunately Git was originally developed solely to manage the Linux kernel, and many of its commands were not thought through with immense care about usability or sense to the general programmer population, so the old term "checkout" was grandfathered into it even though nothing is occurring which is analogous to checking a physical item out of a physical repository - whether "checkout" was chosen because of its similarity to a similar operation in more centralized systems, I can only speculate.
Source: I work on GitKraken, a git client that tries to make those commands less confusing.
"Don't be that person" @7:08 also applies when you revisit YOUR OWN code months later and don't remember wtf is going on
Dan I revisited my code after the two years and now I need it for a competition and I remember what I did....
@@tony91200211 A fair point. Comments could be overly verbose if the functions are small, and use descriptive language. However, as a rule, people do quick things and end up leaving them (i.e. "var test"). I tend to write comments when I feel that the code I'm writing can't describe itself well due to other constraints. However, sometimes going without docs can get you into situations like Dan mentioned.
3:47 Can you spot the guy who puts up the middle finger? I'm serious, he's there and it's funny as hell. XD
lol
It's actually a drink. Looks like a starbucks iced coffee. The "middle finder" is actually the straw.
The guy in front of the blue Ford. Also, the footage is quite blurry, so yeah.
Lol, I thought I saw someone flip the bird, but I didn't think much of it. xD
If you think that’s funny, you should see what I did in my sisters wedding photos. I subtly flicked off the camera in every picture I was in. It got quite the laugh.
Is it just me, or to real software engineers see the comments to this video as mostly a bunch on in-experienced newbies who have learned some buzz-terms and see this an an opportunity to argue theory or what IDE/language is best? As someone who has been designing and building software applications for 15 years, I can tell you that, professionally, what matters is results and the ability to problem solve. For those of you looking to get into software engineering, stop getting so hooked up on ideological debates, language debates or buzz-terms. I don't care if you bought a book that teaches you how to answer 150 programming interview questions that you won't be asked! I'm not going to hire you if you can't demonstrate ability to problem solve and deliver a product. Engineering is all about solving problems that someone else hasn't solved yet, it's about learning how to make the code do what you want it to do, with some opportunity to refactor and improve along the way. I look at code I wrote 5 years ago and I think most of it's ridiculously ammature, and yet 5 years ago I was still a senior software developer making over 120k because I was able to solve problems. In the end, business does not deliver software, it delivers service and software drives the service. If you can master the creation of software that does the job and does it well, then you are valuable, you bring value to the cause and you will make a lot of money, and 95% of everything people are saying in the comments will never matter - ever!
Unfortunately, I think what's driving the discord in the comments is that Computer Science (the name of the topic at hand in this series) doesn't really have much of a relation to software engineering in a practical sense. Most of the comments I've read are from a perspective of computer scientists that will spend their entire lives in academia.
My guess is that this series has probably attracted the academic computer scientists (the types that don't much care for electronic computers much like Edsger Dijkstra) that would rather discuss the merits of specific programming language characteristics than programmers or software engineers that would simply pick up the languages and use them to solve problems.
That's not to say that CS academia is bad. I have great respect for the theoretical CS work that ultimately impacts the lives of the programmers and software engineers. But it does seem to be the perspective of a lot of the comments on this video.
How does one improve their ability to 'problem-solve'?
@@letsfly662 solving problems.
Another real-life software engineer here. This series is great! It's good to finally have a resource I can point people to that explains what I do for a living.
That said, I am a bit disappointed that this episode seems to equate "Software Engineering" with OOP. OOP is very popular, yes, but it is only one way of thinking about building complex software systems. One person's class is another person's module, or abstract data type, or closure.
If there's going to be a future episode that digs deeper into programming languages, I hope you give a shoutout to functional programming. Its usefulness as a paradigm is evident in the fact that many popular languages support it in some form, so I think it's worth talking about.
6:12
Yes! Anyone new to programming should know that having lots of bugs to fix doesn't mean you're not learning anything, and in fact, helps a lot with the learning experience.
I've been a polyglot developer for some time now and I gotta say, this course is so on point, from the T-shirt easter eggs to the cool Thought Cafe animations, I wish i had this kind of material when I was starting up. good job
I've never encountered a programmer who documents their code enough.
Including myself.
At this point I've resigned to just get good at/get used to reading through code to learn what it does. yes it sucks, but this problem isn't going to go away, might as well learn how to live with it eh?
At least self-documenting code can make stuff like this easier.
Really good code doesn't need comments. It takes years to get good at writing simple and easy to understand code.
While comments are great, code should be self explanatory. Really only put comments to give a high level overview. Because if you end up commenting every function then that will be 2 things to maintain. When you change the code, you'll have to change the comment as well. And when, not if, you don't then that'll cause confusion that could result in a number of bad things happening.
The new level of abstraction elevator is my favorite part of the series!
This is quite simply the best you tube series on computer science that there is.
*Opens 1 year old C program with no comments
Only God knows now. (╬ಠ益ಠ)
Something to note about Alpha versions is that it's a lot more common for indie developers to release alphas as they often don't have the resources to do rigorous testing and (especially for game developers) often want feedback from their communities on the direction of the project.
Excellent analogy of car functions into objects --> functions --> loops --< individual instruction statements
On braaaaaaaand!
Why is this series so fascinating?!
The best programming environment is obviously atom. :)
Please note: Be careful when discussing what programming environment you prefer with software developers. It is a quick way to get into long heated arguments.
Carry Anne didn't mention this, but in addition to documentation, you should also use good variable names. Instead of calling a list of letters "a", or "list", you should call it "letters", or even better "listOfLetters". If you don't name you functions well, when others go to debug something in your code, they will get a headache. Documentation tells users what a function/object DOES, but good naming conventions will let others know HOW IT WORKS.
Notepad++
You're all wrong, clearly the supreme programming environment is Windows' Notepad.
im not going to read the other comments I'm just here to say that Intellij is the best IDE and if I have to ill use VIM (emacs can gfy)
No, clearly the best IDE is a cunning combination of echo, cat, and less
I prefer hard coding my code with transistors
I'm really enjoying this Crash Course! Thanks for all the hard work you guys are putting into these, it really shows. Can't wait for more episodes. Cheers
You are wonderful
I am a software engineer for 10 years and listening to you explain things so clearly and so sicsintly makes a lot of things fall i n to place.
Did I mantion you are wonderful? 😄
This is the most important video in computer science! This and the old "warriors of the net" routing animation should be mandatory viewing in computer classes throughout the nation.
That feeling when you had an exam on OOP literally one week ago and you still didn't understand it -- until now.
This explanantion on objects and object oriented programming is far more understandable than any explanation I've ever heard.
This was actually really good. The section on Version Control really helps. Thanks Crash Course!
After trying many, and slowly getting the idea, I finally have the best explanation of WHAT , OOP is and WHY, it is used. Thanks Carrie Anne. My kind of teacher.
Great stuff! But what was described is Modular Programming. Everything shown could be done in Ada or Modula-2. As someone already commented, for Object-Oriented Programming you also want polymorphism (different objects implementing methods with the same name, unlike functions where there is one code for one name) and inheritance (where just what an object adds to another object has to be described). The original Simula I, Smalltalk-72 and -74 didn't have inheritance but Simula 67 and Smalltalk-76 added it and this has been a feature of every object-oriented language since.
But you did not specify whether I should use Tabs or Spaces to indent my code!!!
oOMonkeyMagicOo Surely you've picked a programming language that specifies?
Tabs. 4 spaces. Curly bracer on the same line as the function declaration, if/while/for branches.
Come at me bro
If it compiles and works, it's all good imho! The only thing that gets my goat with other peoples code is the total lack of comments! and non logical naming!
Dude the non logical naming drives me insane. My friend would sometimes ask me for help with his first two COSI classes in college and it seemed like he intentionally made the names as confusing as possible. Like he's have to do a program that worked with images, then he'd write a for loop and use x as the increment variable, HEIGHT as the x coordinate (no not the y coordinate, and yes i mean coordinate not the total height of the screen) and i for the y coordinate. I'm like are you serious? lol
Just use git filter and clean all \t with space. How many? Doesn't matter - just have a company wide style guide (per language or project - not necessarily universal)
the amount of value this video provides is INSANE 🔥
Root canal treatment (endodontics), a dental procedure used to treat infection at the centre of a tooth (the root canal system).
I might need to watch this one again. That was a lot of info packed into one video.
6:10
No truer sentence has ever been uttered.
Angel Cortes I
Oversimplification in all of the covered topics is so, so painful, but I get how it can be a reasonable way to get started.
These is the better explanation of programing oriented a object .
"Vim is where it's at"
HIT THE DECK!
I think I can hear Linus screaming in the distance "SCREW OOP!".
Linus OOP Tips
lmao
coding is like writing a love poem to your lovely one, I mean yourself!
Carrie-Anne, you blowing my mind!
Just a tip: use comments sparingly; your code should be able to stand alone even without comments. Use comments only when there is something that is hard to communicate with the code, there are things to watch out for, etc.
09:23 LOL @ the Assassin's Creed face bug.
The vim joke had my dying qq
Nick McKenzie q!
!q
DearLuck :q
Zrelok Had to use :q!, but thanks.
DearLuck don't forget to save :w
Nick McKenzie :wq
Quality assurance describes the measures taken to prevent defects (process-oriented). Quality control is testing the created product.
I enjoyed the programming humour in this episode. :)
Carrie Anne making it clear she's a vim advocate, and makes a fair point that it's not bad as long as you know how to quit, hehe...
How to generate a random string: Plop a new user in vim and tell them to quit, just throw away the first 15 inputs or so (the alt+F4, esc, ctrl+w "standard" exit commands)
Ah the editor wars. I've used all of these and more...
* Turbo Pascal IDE (with WordStar keybindings)
* DOS Edit (just a wrapper for QBasic)
* Windows Notepad
* Emacs/XEmacs
* Vi/Vim
* Pico/Nano
* jEdit
* Notepad++
...and on it goes.
I learnt so much in about 10 minutes. these series is recommendable to people who is new to cs
I love computer science
longcat tacgnol
Hey, I love my dad's spaghuetti, what a coincidence!
I love this Crash Course...
I love Mathematics
I love Roblox and Crash Course
I love donuts. Computer science is a close second tho
There's a lot of software engineering to mention but this is a good a good overview.
"Huge pieces of software, that we know and love today... Powerpoint."
In my best and loudest Dwight voice.... "FALSE!"
LOVING this series XD
3:46 watch that beige mini van XD
I am have been pretty happy with this series, especially as a way to help explain concepts to my non-software engineer friends. But, this video hits a gripe I have had with the way we teach software engineering and development. OOP is not the same and software engineering. Functional programming and non-hierarchical program organization methodologies exist and are being used pretty pervasively in the industry. Modern Javascript is functional and composable while Haskell, Erlang, and Scala all see use right now in the industry back ending some of the largest sites on the web. As someone who enjoys this type of programming, it is a shame that we don't see it taught enough. Thank you again for making these videos and I hope that you are able to find time in your series to hit on these different methods of abstracting.
One of my colleagues had the philosophy of never documenting code. When asked why, he said it was because programmers are so lazy that when they change the code, they do not change the comments, and inaccurate comments are worse than no comments at all. Also, he and his team handed over their product for porting to another language (Pascal to C) and we asked, "where are the comments?". He replied, "there are 300,000 lines of comments in this code."
Brion Emde So you run P2C and you're done. And by the way, still no comments, except this time they're all wrong because they were written by computer.
I've been writing code for 15 years and that's no excuse to "never" comment. Programmers are not lazy, they are focused - they fix the code because that fixes the problem, if the comments don't get updated then they will get updated or removed in the next refactor. And if you know what you're doing, you're not commenting everywhere anyway. A programmer doesn't need a comment to know what the code does (only students rely on comments) a programmer looks at the code first anyway so see what it's doing, and he may glance at the comments to see what the previous programmer (often himself) was thinking. I tend to comment when I want to tell someone "why" I wrote this code, not what the code does. Rule of thumb, if there's a code-smell add a comment to explain why you wrote it that way, otherwise if the methods/variables are named effectively and you're code isn't bloated, then no comment is really needed.
This was over 30 years ago and things have changed. I doubt that his attitude has changed, though.
This was over 30 years ago. We first used an automatic tool by Tata Consulting that automatically translated a huge proportion of the code automatically, but produced code that was judged as unreadable the original authors, so while it became the basis of a product release on one platform, the code was not maintained and another solution to the translation problem was found. That one wasn't able to deal with nested functions in Pascal, so the code had first to be un-nested manually. The tool probably did 60% of the work and the rest was done manually. I forget the names of either tool. No doubt such tools have improved. That Tata tool was actually quite brilliant.
+seasong Documentation is highly dependent on your audience. The Linux kernel only needs documentation for people who want to make changes. Users of the Linux kernel generally do not care how the code works, just that it compiles and they can boot it. Conversely, consider the `git` source control tool. There the interface needs to be clearly documented because of the way users interact with it. It is also much more likely that a user of `git` will want to make a change to the core functionality.
I feel like I should be paying for this series.... high quality course.
"Programmers spend about 70 to 80% of their time running and debugging, not writing new code."
*This hits so close to home it hurts.*
Great overview but I do disagree on one point, commenting code. Your aim is to write code that is self documenting without the use of comments. The reason for this is that as code can change and it can be easy for a bit of code to be changed while the associated comments aren't. The one thing worst then no comments are wrong comments. There are places to put comments, like when describing an API or why your little bit of code looks like it could win a Rube Goldberg competition. But usually, making the code itself clean and concise is the best way to make it understandable. If you want to know more, I recommend Clean Code, The Pragmatic Programmer, or Code Complete 2 and great books to read.
Carrie Anne uses vim, a woman after my heart!
This woman reminds of why I love computers!
Any plans to talk about functional programming?
The code is the documentation. :) Thats why clean code is important.
Please put this video into the playlist, please
Wow! It's not magic... it's computer science. This was a great series 👍
Ohhh, I never really got why I would want to use objects,but in the context of a massive project like office, I suppose it would make it a lot more manageable.
I love the detail in the car example, that we actually see Steve Jobs, standing next to precisely the type of car he drove including his signature missing licence plate (he switched the car every six weeks so he would not need to install a licence plate).
OOPS is called OOPS because of the reasons that you stated here.
Thanks for the Series though .
.
.
And one more thing Your Clock Speed needs to be reduced or the voice software code in you has to be calibrated for a little slow output.
.
.
body(Carrie Ann).human.throat.larynx.muscle.speed(......needs to reduce the muscle vibrating speed) //Talking speed
.
.
Remember we humans cannot match the clock speed of the Computer :oD .... Thanks a Ton for such lucid and detailed explanation of so many levels of abstraction.
"Don't be that person" That also applies to over-commenting, I run into too many devs that over-comment their code and comment every public variable and function, it quickly becomes a mess, comments become outdated, and it becomes very hard to read. Seriously, GetPlayerName(Player p) doesn't need a comment, it should be pretty self explanatory. Now, that said, a weird workaround you had to do because of a bug with a compiled library DOES need a comment so it isn't confusing to read.
I think over-commenting is still better than under-commenting
After taking my first programming class, I realize now how much this video helped me understand the importance of comments.
Thank you so much, Carrie Anne! Such a clear and concise explanation of OOP, IDEs, and APIs deserves a round of applause. :-)
YOU CAN NEVER GO TO FAR WITH VIM YOU TAKE THAT BACK
I like the fact you're talking about instances of women in computing history. Way to go!
It should be noted that OOP is sometimes criticized
It would be awesome if you uploaded a course of mathematics, like Calculus
IntelliJ and Sublime 👌 also, as a technical writer, I was glad that you mentioned documentation 😁🎉
Awesome video! Being a new "professional" programmer, I relate to this Crash Course episode on so many levels 😅
You guys forgot to talk about process which is another major part of software engineering. Plus you forgot to mention visibility, and Dennis Ritchie, the father of C and all of its derivative languages. Will we ever get at least a nod to the gang of four?
"You guys forgot to talk about process which is another major part of software engineering."
Process? Which process?
"Plus you forgot to mention... Dennis Ritchie, the father of C and all of its derivative languages."
Dennis Ritchie is more well-known for his contributions to operating-systems and programming-language development than software engineering. But I think they did mention him in the OS episode.
"Will we ever get at least a nod to the gang of four?"
It's called CRASH COURSE computer science for a reason. Most newcomers may not even be familiar with the term "Object-oriented programming", let alone gang-of-4. You can't cover everything.
PSA: In response to the comment at 6:45 ... Please don't "ignore" invalid values in a function. Throw an exception or raise an error so that those of us who use your code don't spend hours trying to find out why nothing works. :)
Yeah wtf was that? :D "Oh you want me to do something, sure, I'll do it!"
Later...
"- So, did you do the thing?"
"-Naaah I didn't, because I couldn't."
"-And you were planning on telling me... when?"
The clearest explanation ever
dont think we missed that guy in the traffic footage flipping us off :D
Love the Assassins Creed graphic at 9:18. Great example there.
VIM? VIM?! Emacs is where it's at!!!!!
In a large company, even when split into smaller teams, you can seldom assume that only you are editing a certain file. Merge conflicts are a commen and natural occurence.
This whole series has been really helpful! Congratulations on the amazing work :)
Carrie Anne,
Great speed and quality of the information!
Thank You
the best explanation of oop so far
That was a good explanation of 1990s version control.
Yeah the "checking out code, just like a book from a library" remark reeks of centralized and concurrent version control, which everybody is (or should be) moving away from.
Apart from that, enjoying the series!
What do you suggest everybody is (or should be, at least!) moving toward?
@@ConorJTobin Decentralized version control - AKA - Git
At 3:48 the guy driving in the center lane flipped you off 😂
Composition over inheritance.
Verbs > Nouns
Write code like you're going to change all of it next week.
Simplify your code before you comment it.
Shoutout to Vim, nice 👍
So I will enter the University and take software engineering as major . It is breathtaking when your big project works.
While I understand the process of development was generalised for educational purposes, I believe it would have been nice to note that there are a myriad of different ways that code can be stored, affecting the process of collaboration between the developers.
Also automated testing for the win.
i like your graphics works and editing style
This brought up memories of playing the Minecraft Alpha. First time I ever encountered such a thing 😂
Thank u every body
Awesome!, I wait every week to watch this. Thank you!
Software Engineer here, love the series. I have to disagree about comments.
Code should be clean and self-documenting. Comments should only be used when the code is not capable of expressing itself, or for APIs being distributed/used off-team. If you think you need a comment, then reevaluate and try refactoring the code.
The intention and behavior of code should be described by the tests, methods names, variable names, and class names
Domain knowledge should be taught to new team members upon joining via minor documentation outside the code.
“Pretty much every piece of software on your computer, or game running on your console was built using an Object Oriented language”
It’s true that many are, but it’s a fiction to think that all are, or that all were designed in an OOP way. Games especially may use C++, but are sometimes written much more closely to C. Especially in large, resource demanding programs. See talks by Jonathan Blow, Casey Muratori, Mike Acton for examples of alternatives. In data science especially functional programming and other paradigms are highly used.
The main ( core ) technology of the age seems to be born from the related ( peripheral ) technology of the former age.
For example , agriculture from tool-making , engines from metalworking , and computers from electrical engineering are cited.
Then , what will be the mother technology of AI , which is going to mark a next epoch ?
I suppose light / quantum computer , neurocomputer or software engineering are the candidates.
Please do a segment on other programming paradigms.
4:57 "This ability to hide complexity, and selectively reveal it, is the essence of Object Oriented Programming." -- What?! This series has shaky writing at times, and everyone seems to have a different definition of OOP, but this is about as bad as you could get. One of their own examples, Python, is a counterexample. Not only does Python /not/ strictly enforce a public/private distinction, the mechanism that it does provide (the double underscore) is also available at the module level, where it serves exactly the same purpose in non-OO code.
Complete intro to OO in about two minutes - amazing :-D