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.
@@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.
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.
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.
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.
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.
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.
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.
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
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
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)
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.
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? 😄
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.
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?"
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...
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.
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.
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.
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.
Code should be self-documenting. Of course, if you're developing for other users, then your API should be well documented. Other than that comments should be rare, and only used when... well... Uncle Bob puts it best: "[we need] to compensate for our failure to express ourselves in code"
No human thinks in a programming language. The concept of "self-documenting code" is helpful, but also an extreme that can never be met. Code should be designed such that it's as easy to understand as possible, but comments are still highly important and recommended when working with other people, or even when coming back to your code 10 months later. Sure, you could read through the code and follow the functions back and forth and understand it, but you shouldn't have to spend that time when a well-placed comment could explain it easily for you. The main reason comments are so important even with the best coding practices: functions are the programming equivalent of "see page 723, figure A, model IV, then come back and now go look at page 8762, paragraph 3, subsection Q".... we make fun of that kind of jumping around when lawyers do it, but code does it all the time. That's why it's best to comment your code rather than expecting humans to jump around like that.
What's the problem with verbose method names, etc? Is the code too wide for your screen? Wrap it. Is it too long? It probably should be refactored to smaller methods. Sure there are times and places for comments, but I don't often need to put them in the actual code. Does internal code need, e.g. JavaDoc? Not really. Does a library? Of course its external API should have documentation! It's meant to be consumed by others. Perhaps it's because I work on a small team, but I rarely find the need to comment something instead of refactoring code to be more readable.
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.
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.
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).
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 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.
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.
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!
"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.
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!!
The more I watch this series, the more the "a new level of abstraction" animation makes sense to me.
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.
"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.
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.
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.
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.
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.
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.
*Opens 1 year old C program with no comments
Only God knows now. (╬ಠ益ಠ)
The new level of abstraction elevator is my favorite part of the series!
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.
This is quite simply the best you tube series on computer science that there is.
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
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.
On braaaaaaaand!
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
Why is this series so fascinating?!
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)
3:46 watch that beige mini van XD
That feeling when you had an exam on OOP literally one week ago and you still didn't understand it -- until now.
Excellent analogy of car functions into objects --> functions --> loops --< individual instruction statements
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.
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 explanantion on objects and object oriented programming is far more understandable than any explanation I've ever heard.
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.
This was actually really good. The section on Version Control really helps. Thanks Crash Course!
the amount of value this video provides is INSANE 🔥
Oversimplification in all of the covered topics is so, so painful, but I get how it can be a reasonable way to get started.
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?"
I might need to watch this one again. That was a lot of info packed into one video.
Root canal treatment (endodontics), a dental procedure used to treat infection at the centre of a tooth (the root canal system).
These is the better explanation of programing oriented a object .
"Vim is where it's at"
HIT THE DECK!
"Huge pieces of software, that we know and love today... Powerpoint."
In my best and loudest Dwight voice.... "FALSE!"
LOVING this series XD
6:10
No truer sentence has ever been uttered.
Angel Cortes I
Carrie-Anne, you blowing my mind!
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!
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...
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
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
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.
I feel like I should be paying for this series.... high quality course.
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.
There's a lot of software engineering to mention but this is a good a good overview.
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.
Wow! It's not magic... it's computer science. This was a great series 👍
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.
Carrie Anne uses vim, a woman after my heart!
Quality assurance describes the measures taken to prevent defects (process-oriented). Quality control is testing the created product.
This woman reminds of why I love computers!
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. :-)
This whole series has been really helpful! Congratulations on the amazing work :)
"Don't be that person." But I am that person.
I code in college, and I get a lot of stick for it.
Code should be self-documenting. Of course, if you're developing for other users, then your API should be well documented. Other than that comments should be rare, and only used when... well... Uncle Bob puts it best: "[we need] to compensate for our failure to express ourselves in code"
No human thinks in a programming language. The concept of "self-documenting code" is helpful, but also an extreme that can never be met. Code should be designed such that it's as easy to understand as possible, but comments are still highly important and recommended when working with other people, or even when coming back to your code 10 months later. Sure, you could read through the code and follow the functions back and forth and understand it, but you shouldn't have to spend that time when a well-placed comment could explain it easily for you.
The main reason comments are so important even with the best coding practices: functions are the programming equivalent of "see page 723, figure A, model IV, then come back and now go look at page 8762, paragraph 3, subsection Q".... we make fun of that kind of jumping around when lawyers do it, but code does it all the time. That's why it's best to comment your code rather than expecting humans to jump around like that.
What's the problem with verbose method names, etc? Is the code too wide for your screen? Wrap it. Is it too long? It probably should be refactored to smaller methods. Sure there are times and places for comments, but I don't often need to put them in the actual code.
Does internal code need, e.g. JavaDoc? Not really. Does a library? Of course its external API should have documentation! It's meant to be consumed by others.
Perhaps it's because I work on a small team, but I rarely find the need to comment something instead of refactoring code to be more readable.
function printText(text){
console.log(text);
}
function printACountToN(n){
for(let i = 0; i < n; i++) printText(i);
}
the best explanation of oop so far
Awesome video! Being a new "professional" programmer, I relate to this Crash Course episode on so many levels 😅
VIM? VIM?! Emacs is where it's at!!!!!
I like the fact you're talking about instances of women in computing history. Way to go!
I can't believe I just understood software engineering in one sitting.
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.
IntelliJ and Sublime 👌 also, as a technical writer, I was glad that you mentioned documentation 😁🎉
Carrie Anne,
Great speed and quality of the information!
Thank You
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.
i like your graphics works and editing style
Any plans to talk about functional programming?
At 3:48 the guy driving in the center lane flipped you off 😂
The clearest explanation ever
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).
The code is the documentation. :) Thats why clean code is important.
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.
Awesome!, I wait every week to watch this. Thank you!
Shoutout to Vim, nice 👍
YOU CAN NEVER GO TO FAR WITH VIM YOU TAKE THAT BACK
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.
It would be awesome if you uploaded a course of mathematics, like Calculus
Please put this video into the playlist, please
It should be noted that OOP is sometimes criticized
Love the Assassins Creed graphic at 9:18. Great example there.
favorite episode, helped explain what i want to do with my life
Loved the Vim shout out!!
love the raspberry pi shirt. Carrie Ann you're awesome!
Complete intro to OO in about two minutes - amazing :-D
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.
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.
Vim for life from now on baby!!!
Great overview! Opened my eyes!
6:10 not if you use an FP language with a good type system.
SE in the future practice might be centered around types (hopefully dependent ones) to describe the domain.
yay you finally made one for software angineering
So I will enter the University and take software engineering as major . It is breathtaking when your big project works.
This brought up memories of playing the Minecraft Alpha. First time I ever encountered such a thing 😂
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
No one can argue that visual studio is the best ide out there... As a php developer, I miss VS...
All the cool kids are using PHPStorm these days.
I love PHPStorm, but the performance is just bad ... I had to switch to VS Code ...
"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
Please do a segment on other programming paradigms.