As I mentioned in this post, I’ve been learning from a book. This particular book is called “Sams Teach yourself the C# language in 21 days” by Bradely L. Jones.
I had gotten to chapter 11 (day 11) and while some items I’d picked up really quickly, others were left in the vacuum of Michelle’s brain known as “things that make me go WTF”.
So, I’ve decided that, along with writing up my progress in this blog, I’ll start this book from the beginning again and not leave a chapter unless I can explain every single crazy techno babble term in plain English. And by techno babble, I mean each time the book screams “new term” with a big black blob.
This, of course, may end up with my stating the obvious a lot of the time but hey, if I can explain things in plain English, it must mean I understand it. So I’m going to take that as a positive.
It may also mean that I spend weeks on one chapter. You’ll just have to bear with me – I can be a little “blonde” sometimes.
This chapter is so *very* dry. It’s about the only part in the book I’ve found so far that completely patronises you, going into more detail about what an editor is rather than what you actually type into it. It also doesn’t really do anything code wise; just the basics about the language and how it works.
A program made in C# needs a .NET Common Language Runtime (CLR). In my source code explanation below, this would be part of the translator. You compile your code, translating it into a form the CLR can read, then the CLR takes the instructions you’re writing in C# and translates them into computer speak. If you don’t have a CLR on your computer, the program you’ve made won’t execute (it won’t work).
The benefit of using a CLR is that you only need to make one version of your program. So, if you wanted your program to run on a Windows machine and a Linux machine, you’d need two programs. I’d say that is why you often have two different install programs for Spotify, one for Windows machines and one for Macs. There’s probably more reasons, of course, but I’ll roll with this explanation for now. Kinda like how each year you went up in physics class, they told you that the stuff you learnt last year wasn’t technically true. No doubt I’ll find out I’m completely wrong later on.
C# is a modular language. You write it in little chunks, each chunk working with the other. So, if you were writing a program to make breakfast, you’d have one chunk to make the coffee, one to make the toast and the other to make a bowl of cereal.
Another cool thing about C# is that it was written for object-oriented programming. This is a rather nifty little idea that code can: adapt to whatever is thrown at it (polymorphism); be recycled (reuse); using existing code, and adding to it (inheritance) and have chunks of code for each of the tasks it needs to perform (encapsulation). Funnily enough, despite it being quite complex, this is about the only thing I actually learnt at uni.
OOP’s chunks of code are referred to as classes, and these classes create objects. The book actually shocks me here and uses a reasonable explanation of how objects and classes work. A class is the definition and the object is the item that is created. The example the book uses is that a class is a cookie cutter, and the object is the cookie itself.
These terms are written as I understand them at the time of writing this blog. I may come to expand on them, or change them completely as I learn more about programming. You can find an up-to-date list of the terms on my programming terms page.
Source code – Your written instructions that tell the computer what to do. These instructions need a lot of translating for your computer to actually know what you’re typing about, but you don’t have to worry about that.
Like telling a translator how to make a cup of tea, and then them relaying those instructions to someone else in another language. You writing the source code is the instructions to the translator, and the these terms are then translated into something your computer can understand (by some sort of magical technomancy from what I can tell at the moment… we’ll find out later – I hope!).
Basically, source code + translator = program.
Editor – A program that you enter your source code into. This is a silly term. I don’t know why they defined it in the book but hey ho. I’m using Sharp Develop because it came with the book and makes my code have pretty colours. I could very well use Notepad if I wanted but I’m like a magpie with my like of shiny things so Sharp Develop it is.
Execute – A fancy word for starting your program. For example: at 7:30am, double click on Michelle.exe file, executing the program to get my ass out of bed (which usually would involve copious amounts of coffee) and into work.
Executable – A program that tells the computer what to do.
True executable – A program that tells the computer what to do in its own language. C# doesn’t do this, however, it uses .NET CLR to translate your instructions into the computer’s language. This is called an Intermediate Language (IL).
Compile – Turning your instructions into an executable. (Oh, oh… using technical terms to explain other technical terms. I’M BECOMING A MONSTER) It’s basically a fancy way of saying it translates what you’re writing into something the .NET CLR can read. The .NET CLR then translates this into something the computer can use when you double click the executable. So, changing my little example earlier, we now have: source code + compiler = program/executable.
Assembly – From what I can tell, this is just another name for an executable. Source code + compiler = program/executable/assembly. The use of different words for the same thing that happens a lot throughout this book.
Modular – The idea that you write things in little chunks. Makes reading the code a whole lot easier in my opinion!
Class – A chunk of code. It performs a certain function within your program. So, you could have a class that deals with everything to do with making toast in a program that makes your breakfast.
Object-oriented programming (OOP) – This is, at a *very* basic level, the idea of splitting your code up into chunks and having these chunks interact with one another. One of the benefits of this is that it makes changing the chunks easy to do without them affecting the rest of the program.
Encapsulation – The “making chunks” part of OOP. In theory, it means that the user of your program can do what they want without having to worry about how the chunk works – just that it does.
Polymorphism – This refers to your program being able to adapt to the situation it’s in. Basically you write your code to allow multiple ways of doing things, but all those things still produce the answer. A simple maths explanation is that there are a few ways to get the number 10.
- 2 x 5 = 10
- 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 = 10
- 1 x 10 = 10
- 5 + 5 = 10
Polymorphism is the idea that your class would be able to cope with that without the user noticing.
Inheritance – I like to explain this by an example. Think of dogs. All dogs have fur, legs, tails, eyes etc. But you also have different breeds of dog, with all of the previously listed things but slight changes such as some having long fur, and others short, for example. So, if you have a class called
dog, the class called
jack_russell_terrier would inherit the properties of
dog, but would have extra features.
Reuse – Reuse is the idea that once you’ve written a class, tested it and know it works, that you can use this in another program without having to test it. You only have to check that you are using it in the correct manner.
Something that the book covers in this chapter, but isn’t really applicable at this stage is that one of the advantages of C# and its use of CLR is that it only compiles the parts of the program that are being used. This makes the program faster in the long run. This is known as Just In Time (JIT) compiling (or “jitting” but, to be honest, that just sounds silly).