CS101: Introduction to Computing Principles
web.stanford.edu
web.stanford.edu
It is easily the most engaging course I have ever taken and it's available for free on edx.org or you can take the "real" class from Harvard extension for a couple grand. You can go into this class as an underwater basket weaver or a strong coder and get a ton out of it.
The course has 2 tracks which are graded the same: "regular" for those new to cs/programming and "hacker" which has a bit more of a challenge to keep it interesting, and you just do whatever one you want to do that week.
Each assignment has additional optional material explaining and reinforcing the concept so if you are a little opaque in an area you can go and study that a bit more before returning to the assignment. Ultimately, there is a walkthrough for each week that gives you about 95%+ of the answer in case you get really stuck. If you understood the concept well enough from the lecture or your own background, you can just blast right through the assignment, or put your own spin on it.
Supposedly this course is responsible for hundreds (if not thousands) of people changing their planned field of study to be more technical due to the huge accessibility of the material to what they call "less comfortable" students.
They also teach you a few adjacent things that are relevant and probably wouldn't be covered by most modern programming courses. They teach you how to use desktop VMs for your IDE. They teach you how to use a basic IDE. They teach you the basics of Linux command line. They teach you what memory leaks are and how to find them. You're graded on style, there is an automated style checker.
For me, I got a kick out of all the sorting algorithms and how it applied to big O notation and software complexity. Previously I understood roughly how it worked but the course went deep enough where I tried implementing some of them on my own "for fun" to see if I could do it.
For my final project, I built a native android app, and although they didn't teach anything specifically about mobile app design, I had enough confidence at that point to knock it out.
On top of all those items, production value of the course seemed huge, very well done.
I don't remember if there were suggestions (like factorial for recursion or a summation formula for induction).
At that time it was taught by Brian Harvey. I liked him a ton. I know there have been other excellent 61A teachers, too.
If there's a kind of instruction that reliably teaches students as a whole to write recursive functions successfully in just an hour, that will be a great advance for computer science education.
Learning Programming != Learning CS
- it's not about learning a language
- I don't think it's crammed either - it covers a lot but everything is explained in a very accessible way from first principles
- if an introductory course was using only one language, you still wouldn't master the language
- being exposed to different ways to do the same thing is very valuable and very underrated for beginners imo because it teaches you to abstract over concepts - when you learn how to read a file, write a loop, sort an array in each one of C/Python/JS, you develop better understanding of the concept of reading/looping/sorting instead of thinking that the only way to do it is the way your first language does it; you begin to develop a sense of which concepts are language-specific and which ones carry over across languages. I think it's better if this understanding happens early instead of late.
Master of a single programming language is a moot concept, it either boils through to other languages or you just memorized the syntax really well.
This is exactly the point of any introductory college level course. They're never intended to be the end of your education, they're designed to be a broad introduction to most of the different concepts that you will be learning throughout the program.
Even if you're not taking the rest of the program, having a broad overview as a starting point is valuable. You won't "master" anything in 3 months no matter what you do, so starting by going deep just needlessly limits your perspective on how much there is to learn.
This is one of the most common misconceptions in general with educational institutions and the general software engineering job market.
Programming is not Computer Science.
Computer science teaches you how computers work, concepts of how encryption works, concepts of security, concepts of memory management, and so forth. More recently computer programming has been added as a part of Computer Science degrees, but actually just a decade or so ago (when I was going through it), you could graduate with Computer Science degree without programming experience at all.
There is no doubt that learning computer science makes you a better programmer, but it is different and it is possible to be a good programmer without it.
Programming is one of the practical applications that benefit from strong computer science knowledge. Just like how taking a human anatomy course or a biology course doesn't train you to become a doctor. But it's pretty important knowledge needed for doctors to be good at their jobs (so much so that we don't let people practice medicine without it).
> Harvard’s course seems to be aimed at people who are coders or want to be better at coding, so you learn about different languages, algorithms/data structures, SQL and such.
CS50 is definitely somewhere between "comp sci course" and a "get coding quick" bootcamp.
The future has pointers and memory allocation, even if you want to pretend it’s to there and leave the complexity to other smart folks.
> You don't need low level details to program well--you need a good language like APL, to truly learn how to program
We’re not talking about a programming degree. We’re talking about a computer science degree.
In my own experience working with a lot of brand new programmers, making the subject entertaining is 80% of the battle. Most introductions to CS are unbearably dry and do a very very poor job of motivating further study. The job of an introductory course is to give an overview of what you'll learn going forward and make you want to learn those things, and by all accounts (even yours) CS50 does that.
In other words, CS50 is probably great if it is the one and only course a new person would take. This is due to the broad focus on so many concepts.
However, if it is the first out of many courses, I would not choose such broad focus. I would (and have done many times) create a curriculum based on the student's needs and desires.
That's why I don't like CS50. It's not because I'm not the target audience necessarily, it's that CS50 is overhyped and, in my humble opinion, not suited to be the first course for serious self learners.
By not suited, I mean that there are a number of specifications on Coursera that are a) also free, and b) will lead one better to the goal if the goal is known (which is where most newbies need a mentor). I do not mean that CS50 is unsuitable; I mean that it is suboptimal. In my experience, that is.
I think you may be right about it being suboptimal for self learners. It was, after all, not really designed for that. I disagree that the breadth of the course is a flaw.
One major problem I consistently see with self-taught individuals (including myself before college) is that they have major blind spots, places where they don't know what they don't know. A broad introductory course that intentionally doesn't restrict itself to topics the student is already interested in is the best way I know to quickly turn those unknown unknowns into known unknowns. Whether or not the student chooses to fill those gaps in later with further courses, they'll be better for knowing where the gaps are.
CS50 got me interested enough in programming to pursue it as a career. I have a CS degree now, and work at a well known tech company.
I don’t think the audience is “people who know some programming already.” It is designed for absolute beginners and assumes very little about your prior programming knowledge. I recommend it to any beginner looking to see what computer science is about.
The Stanford course, especially the second half, appears to be more in the spirit of liberal arts. It covers high-level concepts in CS (server vs client, how does the internet work, what is encryption) that even someone who never writes code professionally will be able to use. They’ll be better able to read newspaper articles on tech topics, or perhaps more to the point, better equipped to be a PM/lawyer/BD in the tech space.
https://web.stanford.edu/class/archive/cs/cs106a/cs106a.1228...
Hard disagree on this one. I learned how to program from CS50 with no prior experience. That introduction got me interested enough to pursue it as a career. I would highly recommend it for anyone who just wants to see what the whole programming thing is all about.
How To Design Programs: [https://htdp.org]
A Data-Centric Introduction to Computing: [https://dcic-world.org]
If the person is ambitious, that is the minimum required to begin, and it might be worth seeing just how far they can get in Nand2Tetris[0] where a person simulates building elementary logic gates and circuits leading to an also very basic Arithmetic logic unit and simple ram from nand gates.
I wouldn't expect the person with just a few weeks of CS101 to do week 4 of Nand2Tetris where they try out machine language on their machine that leads to building an assembler, and then a compiler, as this eventually requires knowing Java or a similar language, but more power to them if they preview the course and see how much they can understand.
1. Organize data 2. Transform the data according to some input. 3. Output a result.
Once you’ve very clearly mapped out your data structures, everything else becomes fairly trivial. Functions are nothing more than turning data from one form into another. Outputs are just data in some new structure that can be easily consumed for some other purpose.
I challenge anyone to find a problem that doesn’t fit this formula.
Some years ago I was working full-time in a molecular biology lab, and part of the job involved using a lot of computational bioinformatics tools. I knew a couple of CS people who were writing bioinformatics software and they showed me pages of code, and I asked "realistically, how long would it take me to learn to write these kinds of programs" and the answer was always "at least two years of full-time effort" (It was mostly C code they were working with at the time, plus Java for the user interfaces). My personal experience finally learning to program over the past few years is right in line with those estimates.
There aren't really any shortcuts, you just have to put in the hours of work, week after week, month after month, year after year. As with most fields, a lot of the introductory material is outdated for modern industry but since the more advanced technology relies on an understanding of the basics, you can't just leapfrog it, that's like trying to learn calculus without ever taking any algebra, or trying to grok CRISPR without knowing how basic DNA replication works.
I very much enjoy introducing my pupils to functions. It is the first time they really get to use the computer as a tool for accelerating their abilities. Up until then, their code has utility in the order of how much they wrote. Functions can let you write a page of code that does so much more.
[1] https://www.youtube.com/playlist?list=PLE18841CABEA24090
For instance, are "For Loops", "If Statements" and "Spreadsheets" really essential to computing, can these concepts be considered "computing principles"?
What about logic? I note there is a reference to "Boolean Logic" as one part of the "Spreadsheets and Data" lecture. What about models of computing, or defining what we even mean when we say "computing"? The lecture notes hint at some of these topics in the final lecture ("Theory and Conclusions"), almost like an afterthought.
> What about models of computing, or defining what we even mean when we say "computing"?
... I found all I've learn is worth nearly nothing in industry. Which saddens me and it shouldn't be, but it is so. Really basic principles get useful but only in very high-end areas, stuff that I can barely comprehend (eg. automata for model checkers etc).
It really depends what you work on. Doesn't even have to be high end. When working on performance critical code I was glad about my computer science and math education more than once. And performance can get interesting even at a few million users or regardless of user-count in realtime applications. When writing business logic without performance and scalability in mind, yea, all that knowledge remains dormant. Reality is that there is simply far more business logic work out there than performance critical code.
Can you give me an idea of what your CS & maths education gave you that you found so useful for tuning code? Maybe I'm missing something important.
all of this was an integral part of my formal education. Algorithms and datastructures and complexity analysis was mandatory in the undergraduate studies, the lower-level stuff mostly in elective postgraduate classes of my computer science program. From the top of my head also things like operating systems, compilers, networking, vectorization (SIMD), instruction pipelining, branch prediction, threading, NUMA, thread-pinning/affinity that help understanding how my code is actually executed. On the math side set theory, probability theory and analysis also came in handy more than once. Linear algebra I guess if I had to deal with matrices, which is probably relevant in the AI/machine learning fields (not my area of expertise). All of my math education was mandatory undergraduate classes.
Sure, it's well established that you don't need formal education to learn all these things (which applies to most fields, not just CS), but they are certainly part of computer science and taught as part of formal education at I would assume most good universities.
From my experience (which is Germany and Japan, not the US) especially postgraduate degrees are what you make of them. You can learn nothing relevant for performance critical engineering or you can learn a ton.
> all of this was an integral part of my formal education.
Other than algos, we got none of this.
> the lower-level stuff mostly in elective postgraduate classes of my computer science program. From the top of my head also things like operating systems, compilers, networking, vectorization (SIMD), instruction pipelining, branch prediction, threading, NUMA, thread-pinning/affinity that help understanding how my code is actually executed.
We got compilers. Otherwise none of this - in fact these are not computer science by some definitions. It was pretty much maths at the end. I don't think we were well served in some ways.
> which is Germany and Japan, not the US
I'm in the UK.
Did you have the option to take the relevant classes as electives in your postgraduate studies? My postgraduate had a single mandatory course and otherwise just required that I spread my classes among 3 of ~7 major focus areas. One of these areas was computer architecture, which taught me most of the low-level things I listed above.
Another thing I forgot above was formal education in distributed systems and databases, especially the postgraduate databases class that covered the inner workings (like transactions, WAL, dependencies, rollbacks, etc.) and distributed databases, which nicely connected with the distributed systems lecture (which dealt a lot with CAP theorem and consensus, e.g. paxos). That's also something you can learn on the job, but the formal education gave a pretty broad background that I would think is hard to learn on the job.
> computer science by some definitions
I guess if there is a distinction between computer science and for example computer engineering they would mostly end up on the computer engineering side of things, which sits somewhere between computer science and electrical engineering. Though the level on which I studied these concepts in our computer science department was to understand how it works, history and state of the art and it's implications on software. It was less about how to create such a system from the electrical engineering side of things.
Dunno. It was a long time ago. To be fair, a lot of the stuff you mention learning just didn't exist back then - it was a long time ago. Then again, we did a database course and we got no hands-on with a real DB at all. It was all random guff about functional dependencies etc. I learnt literally nothing useful. I know about WAL etc from learning after.
> I guess if there is a distinction between computer science and for example computer engineering
You nailed it. Engineering vs science. The science was taught purely in the abstract, application of it to real problems was even held somewhat in contempt by one lecturer. It could and should have been so much better.
(oxbridge)
It's all business-oriented work, as in, we need this ASAP. I'd like to do more research-oriented work, or at least cutting edge. Something that's solving longer term business problems, not just 'get it done yesterday'.
MIT tried to do an intro course which was actually an introduction to principles, but the effect was so harsh that undergrads without previous background in programming were often advised to take a more conventional "intro to programming" couse first. The textbook, "Structure and Interpretation of Computer Programs", is still available -- but the course is no longer taught at MIT, after they decided it was no longer serving the needs of the students.
IMO starting with that is the worst possible way to introduce CS to students who are (statistically) far more interested in programming and software engineering than in CS. Hell, most students in this class are probably there only because it’s a prereq for the class they actually want to take.
Same reason we wait until Real Analysis to teach delta-epsilon limits while the engineers are off taking PDEs.
This is very country dependent, we were taught delta-epsilon limits in high school. Maybe not with the same depth, I don't know.
Just do this instead: https://dcic-world.org/