This post is edited from my original blog post. Find it, and other posts by me on kewbish.github.io/blog.
Introduction
Well, it's been a week since I muddled my way through Scratch and the first week of CS50, and I've just about finished Week 1's problem set. This week, I was introduced to the scary world of C, and the basics of how to use it. As well, we went over how to translate common Scratch recipes to C, and some basic information regarding memory and imprecision, as well as some C examples. I'm a complete beginner to these relatively low-level languages, so this was an incredibly eye-opening week.
This week was where I actually started paying attention to things - while the first couple weeks seem pretty easy, I know they're going to become the most useful for laying a proper foundation for the more difficult weeks ahead. So, I sat through the entire hour and forty-six minutes, and delved into the world of C.
Notes
Below are my notes:
- So what - we've established that C is extremely verbose compared to my beloved Python, but now what?
- There are brackets everywhere
- Don't forget semicolons
- style50 demands this terrible bracket style where the bracket is on its own line[^2]
- You initialize variables with a specific type
- C is statically-typed, unlike Python
- can't randomly change types midway through the program
- causes a lot of 'filler' variables to be made, as well as loops to convert between types, like ints to strings
- C doesn't have list comprehension, use for-loops
- By the way, their for-loops are like 'normal' for-loops
- Completely different from Python for-loops
- less intuitive for looping over objects, but easier for array elements
- Can't dynamically append to an array
- need to make a counter of some type to find the length of things
- alternatively, for strings, use
strlen()
- arrays need to be initialized with a certain size, memory allocation things
- We input things with
get_string()
, which is part of the CS50 header library- lots of functionality and sanitization in the CS50 library
- And also, headers are included, not imported
#include something
- if it's in "" quotes, it's a relative import
- if in <> brackets, it's somewhere in the depths of the C library compiler
- Scratch did come in handy, liked the translation examples
- String formatting is extremely weird
- Need to specify the type, and use % formatting
- remember what type the variable is before formatting it
- Imprecision is one of those things that I always forget
- In cash, remember that float imprecision exists
- Make is pretty awesome, complete with commands and all those cool things
- I'm trying to set a custom
cs50make
command in my bashrc instead, but I can't seem to figure it out quite yet
- I'm trying to set a custom
- For problem sets - do your own research
- I get starting blocks, but after, I'm kind of on my own
Problem Sets
In PSET1, you have the option of doing Mario Less or More, and Cash or Credit, based on your experience and comfort with C and programming. I, personally, found the 'more challenging' problems more fun to complete, and found that they taught me more of C's language features, like arrays (even tho we haven't even been introduced to those).
I would recommend doing both the less and more versions of the problem sets. Usually, (like Mario) the 'more' problem sets build off the 'less' sets, so they were more or less required to do anyhow. As well, you get more practise, and I find that practise extremely useful, especially when learning such a new language.
CS50 IDE
For some reason, I just don't like the IDE. Maybe it's just because I'm used to Intellisense and the extension environment that VSCode provides. One example? VSCode allows you to surround things in brackets and quickly use a bunch of keyboard shortcuts to navigate, whereas in the CS50 IDE, doing the same commands just delete and do nothing, respectively.
Setting CS50's CLIs and header files up on WSL were pretty simple, and they're useful for running check50 and other things up on my own system without having to navigate back to the cloud IDE.
So anyway: VSCode, WSL, and Git for the win - CS50 IDE nay. I like how it makes getting started easy for less technically-focused people, and saves a lot of time regarding getting set up, though.
Teaching Style + Misc.
To be honest, I'd kind of skipped over the shorts for Week 0, but for Week 1, they really came in handy. Going through those as well as rereading notes / listening to audio in the background while doing problem sets was how I managed to figure out a bunch of things regarding the problem sets.
They never mention it, but checking out some of the source behind the CS50 libraries and doing a couple Google searches was equally useful. Of course, this probably wouldn't help for people who don't know where to find it, but stalking various GitHub repos was a fun waste of time / help.
And finally, it's time to extol Malan again. Extremely clear, though there's a bit of fluff at times. I love how CS50's staff take their time to make the online CS50x just as wholesome and inclusive as the IRL CS50, even taking the next step to build in a snack chooser in their viewer. (Which, by the way, has a bunch of amazing screenview / normal view, shortcuts, and tonnes of other features. I love it - a great example of a super UX!)
Conclusion
It'll be a fun couple weeks - it takes longer than I thought to properly write up notes, listen to lectures, do problem sets, and write the words you are reading right now. It's a little repetitive, so maybe I'll take a week to speedrun some problem sets, and then write a batch of blog posts at once. Anyway, I'll find a more efficient way to do things, and share my experiences here!
If you've learned C, what are your opinions on it?
C is all about fixed length arrays accessed by indexes called pointers.
C is reasonably simple once you understand that it is:
Point 2 is why C is so wide-spread -- writing a shoddy C compiler is very easy, so there are shoddy C compilers for pretty much everything.
Writing a good optimizing C compiler is quite difficult, so it took considerable time for C implementations to become competitive with assembly.