
The missing semester of CS education - anishathalye
https://missing.csail.mit.edu/
======
Jonhoo
Over the years, we (@anishathalye, @jjgo, @jonhoo) have helped teach several
classes at MIT, and over and over we have seen that many students have limited
knowledge of the tools available to them. Computers were built to automate
manual tasks, yet students often perform repetitive tasks by hand or fail to
take full advantage of powerful tools such as version control and text
editors. Common examples include holding the down arrow key for 30 seconds to
scroll to the bottom of a large file in Vim, or using the nuclear approach to
fix a Git repository ([https://xkcd.com/1597/](https://xkcd.com/1597/)).

At least at MIT, these topics are not taught as part of the university
curriculum: students are never shown how to use these tools, or at least not
how to use them efficiently, and thus waste time and effort on tasks that
should be simple. The standard CS curriculum is missing critical topics about
the computing ecosystem that could make students’ lives significantly easier.

To help mitigate this, we ran a short lecture series during MIT’s Independent
Activities Period (IAP) that covered all the topics we consider crucial to be
an effective computer scientist and programmer. We’ve published lecture notes
and videos in the hopes that people outside MIT find these resources useful.

To offer a bit of historical perspective on the class: we taught this class
for the first time last year, when we called it “Hacker Tools” (there was some
great discussion about last year’s class here:
[https://news.ycombinator.com/item?id=19078281](https://news.ycombinator.com/item?id=19078281)).
We found the feedback from here and elsewhere incredibly helpful. Taking that
into account, we changed the lecture topics a bit, spent more lecture time on
some of the core topics, wrote better exercises, and recorded high-quality
lecture videos using a fancy lecture capture system (and this hacky DSL for
editing multi-track lecture videos, which we thought some of you would find
amusing: [https://github.com/missing-
semester/videos](https://github.com/missing-semester/videos)).

We’d love to hear any insights or feedback you may have, so that we can run an
even better class next year!

\-- Anish, Jose, and Jon

~~~
fuzzy2
That’s cool. Now, on to my possibly unpopular opinion: This isn’t what
computer science is about. In fact, you don’t even need to use a computer to
do computer science.

Sure, some stuff you learn in CS can make you a better software engineer. CS
cannot make you a software engineer.

CS can definitely not make you adept at using computers and neither should it.
That’s something earlier education institutions must tackle.

It’s always good to have optional courses for various topics of interest.
_Requiring_ students to learn, say, MS Office (I had to), is just plain
ridiculous.

~~~
Nitramp
Science doesn't abstractly drop from the heavens, fully formed. Every science
has practical enablers that are required to get stuff done. Astronomers use
telescopes, physicists/chemists/etc use lab equipment, Mathematicians use
various notations and other tricks (and nowadays proof assistants) to make
their job easier.

MS Office might not be practical for computer science (also note how the OP
doesn't list that), but learning how to write your papers in latex might, and
knowing how to use a shell certainly is.

E.g. if you'd like students to learn about type theory, they will need to
experiment with your compiler. You cannot expect students to miraculously be
proficient in this, and explicitly teaching them (and requiring it as a
prerequisite course to signal that yes, it's important) can turn weeks of
frustration followed by a huge dropout rate into a productive course.

~~~
swiley
They should be writing them in asciidoc (or even markdown) and using style
sheets if they really need complex formatting!!! (although at least latex is
decent at typesetting and has nice defaults.)

~~~
whatshisface
Does asciidoc have equation typesetting support? I don't really care what I
use to write my words, everything is equally good (except for LaTeX which is
abnormally good at typesetting), but I care a lot about the user experience
for equations, which varies widely between programs.

~~~
swiley
I always use LaTeX style equations although I think it supports MathML if you
want a WYSIWYG. The LaTeX math is the main argument for it, mathtype is kind
of miserable.

The reasons I prefer asciidoc to straight LaTeX are:

1) the formatting is completely seperated from the text

2) you’re insulated from the specific rendering engine (you can use PDFLaTeX
or WebKit+MathJax etc.) while still getting decent equation syntax and BibTeX.

------
xzel
I took a Unix half credit course randomly where you basically did bash
scripting, a huge bunch of command line tools and then eventually use all that
to build your own linux distribution. I swear I learned more in the half
credit class, and way more if you try to count it as useful information, than
90% of my other CS courses.

Edit: And since this got some traction, here is the current version of the
class:
[https://www.cis.upenn.edu/~cis191/](https://www.cis.upenn.edu/~cis191/) it
looks pretty similar to what I took but they added a little bit of Python.

~~~
kbenson
Going through Linux From Scratch[1] manually and reading each component, while
allowing yourself the time to look into interesting bits of each, is
essentially this. I did it back in the early 2000's, and view it as one of the
most useful educations I've ever gotten on how a Unix-like system functions
(even if a lot of the knowledge is somewhat obsoleted now for many Linux
distros with the introduction of systemd). I was doing it as research for how
to ship a custom distro for a small purpose-built device, and while that never
panned out, I've never once regretted spending the time to go through the
process.

1: [http://www.linuxfromscratch.org/](http://www.linuxfromscratch.org/)

~~~
HPsquared
This - it methodically takes you through all the little details inside the
system that are usually taken for granted and hugely improved my confidence
working with Linux. It also taught me a lot of what's in this class (e.g.
editors, shell scripting, even a fair bit of troubleshooting)

------
lkbm
In the lab for my second or third CS course, the professor was walking us
through intro Unix usage, but he didn't take attendance so it ended up being
just 2-4 of us showing up. After a few weeks, he cancelled the lectures and
told us he'd just be around to answer questions, help with homework, etc.

The last lecture before he cancelled things was an intro to Vim. The next
would've been Emacs.

And that's the story of how I became a life-long Vim user. :-)

~~~
Aperocky
Life long vim user that was initiated by the terminal here, vim has a special
place in my heart, not because the amount of customization that I was able to
add, but because it enabled me to write actual diary.

Here's the script.

[https://github.com/Aperocky/termlife/blob/master/diaryman.sh](https://github.com/Aperocky/termlife/blob/master/diaryman.sh)

All I had to do was to type $diary in the terminal and I'm writing my diary in
vim. I had never had more extensive record of my life. My distracted ass would
never have managed this without that kind of access.

~~~
eqmvii
I love this! I've been looking for a lighweight diary tool, and this is giving
me serious inspiration.

~~~
read_if_gay_
Check out Vimwiki, it has similar functionality and allows hyperlinks to other
documents + index page generation

------
Nikaoto
There are two sides to this kind of teaching. If you're MIT, you can afford to
hire great lecturers who know to teach the students fundamental and deep
truths about the tools they're using and not trivia. That way, they can
generalize onto other tools, so anyone who studied git can quickly adapt to
using cvs or svn. My university (in a developing country) is on the other
side. Last semester was a disaster.

We had an AWS course, half of which was memorizing information about pricing
and S3 tiers. If I were going into a job as an AWS guy, I'd definitely have to
know that, but this is just third year of undergrad in CS :-/ and not a
training course. The quizzes also had deliberately deceiving questions, which
is the worst type of trivia!

Even better example. The Windows Server course was also compulsory (just like
the AWS course) and mainly consisted of memorizing trivial information about
context menus, which buttons to click and the licensing terms/durations/prices
for different Windows Server versions. I'm jaded from the experience. Got my
first two Cs in both since I spent time learning stuff described in the post
instead of that nonsense.

~~~
kabes
I find it very weird to see something like an AWS course in a university-level
CS curriculum.

~~~
slumdev
AWS and Windows Server courses are definitely not university-level CS courses.

~~~
Nikaoto
Yep. And the sad part is that some of the students I met here don't realize
what they're learning is not CS. I only applied to avoid the compulsory
military service, I was already learning a bunch on my job.

On the bright side, the local job market demands match what they teach here
very well. According to my anecdata, lots of students who had no knowledge or
experience working as programmers now have full-time jobs mostly as web
developers. Looks like the university's doing its job and I'm just a whiny C
student.

------
gen220
I graduated a top 50 school, that gave us an “engineering” degree but had no
such similar course. There were no more than 20 students, out of 300ish, who
understood the material of this course well enough to teach it. From my
perspective, this knowledge was generally inversely correlated to GPA and
strongly correlated to postgrad performance.

Take my anecdata for what it is, but I think these skills are strongly
underrated by universities and students alike. Kudos to MIT for publishing
this online; I know I would have benefitted from exposure to these topics in
my first couple of years.

~~~
jldugger
> these skills are strongly underrated by universities and students alike.

Universities believe their focus should be on timeless principles, and expect
that students will supplement their instruction as needed. For example,
teaching students the Bourne Again shell isn't useful on Windows, and
declining in importance in macOS. Same logic applies to editors, but even more
wildly varied. Rather than build 20 courses, one for every IDE, and then
revisit the pedagogy every year as software changes, they basically lean
heavily on 'you're smart enough to figure this out on your own.'

Some of this is obviously motivated post-hoc reasoning but still makes a
modicum of sense -- anyone with 5 years exp could probably teach undergrads
bash and git (with maybe 40 hours of prep), so university instructors with
PhDs should be focusing on knowledge gained from research findings that
wouldn't find their way into industry via other means.

~~~
Retric
It takes no great skill to teach any undergraduate CS class. If you’re talking
about skills that are still going to be useful in 50 years, Unix scripting is
probably one of the strongest competitors. More critically, the basic model of
piping commands through a set of simple programs is extremely powerful and
widely applicable.

~~~
jldugger
Perhaps my experience was atypical, but freshman year included a course on
proofs of correctness, starting from propositional logic and ending with LTL
(comparable in concept to the system Lamport published as TLA+). Upper level
course often included a hands-on section on PROMELA. These are not something I
would expect a rando practitioner to know about or teach, and only rarely put
into practice (albeit to good effect -- amazon uses TLA+ to formally verify
their AWS services: lamport.azurewebsites.net/tla/formal-methods-amazon.pdf).

And that's really the value of an undergraduate degree: learning stuff
industry hasn't yet widely adopted from the people who helped invent it.

~~~
gen220
I'm not trying to be cheeky, but you're proving the point: I'd argue that UNIX
systems and tools are the foundation of AWS, not TLA+. Amazon was famous for
being held together with Perl, back in the day.

If your service or company survives long enough for the marginal cost of
applying TLA+ to it to be worthwhile, you can afford to hire postdocs to work
on it. They probably have 10 people using TLA+ on it. There are probably 500
software engineering teams in the world that are mature enough where the
payoff is worth it.

It's not to say that TLA+ isn't useful, or that it isn't worth learning. It's
just that TLA+ is never going to be a bedrock tool in the same way that UNIX
systems knowledge is.

~~~
jldugger
> If your service or company survives long enough for the marginal cost of
> applying TLA+ to it to be worthwhile, you can afford to hire postdocs to
> work on it.

Judging from the Amazon open reqs I've seen, it's their SRE team writing TLA+.
So like, both topics are useful; I just don't think it's worth paying a
professor to teach you how to use computers when there are so many other
resources available. This is why I support things things like LUGs and student
jobs -- I spent like 5 years supervising student SREs for the OSU Open Source
Lab, speaking at Barcamps, presenting and advising at LUGs, etc. And why a
couple of PhD students are running a one month session and recording it for
posterity.

------
ameixaseca
Metaprogramming has an actual meaning and it means something completely
different from what it is used for on this website:

"Metaprogramming is a programming technique in which computer programs have
the ability to treat other programs as their data." [1]

i.e.: it's a programming technique and not something related to any process
related to building code.

I understand the idea of giving some more practical side of using computers in
a "missing semester", but please pay attention to the nomenclature. It can be
really confusing for someone studying CS that does not yet grasp the concepts
that well.

[1]
[https://en.wikipedia.org/wiki/Metaprogramming](https://en.wikipedia.org/wiki/Metaprogramming)

~~~
Galanwe
“Meta” means “one level of abstraction above”. I find it perfectly okay to use
it in this context.

~~~
MereInterest
The point isn't whether a word fits a definition, but whether that word
already has a definition with which the new definition will be confused.

~~~
rudedogg
And the word is specific to programming! The usage in the course seems
incorrect to me too.

Everything else looks great though!

------
wes1350
This course is wonderful! I've read through all the material and watched all
the lectures and I can say it has helped me tremendously thus far. I'm still
trying to master all the tools they've mentioned but I already feel much more
proficient with e.g. version control, vim, using the command line, etc. If
you're an experienced dev then you might already know all of these things, but
if you feel that you have some gaps in your knowledge with some of these
tools, this course will likely point you in the right direction.

~~~
floatrock
If you're an experienced dev, you use all these every single day.

God save me if I'm asked to implement quicksort though... theory is nice, but
for me, academia largely forgot about this practical stuff.

~~~
pfranz
I missed out on a formal CS education. I found my way, but I always saw it as
all of those things you never had time to research deeply. Otherwise, it's
just a trade school. For example, you've implemented a few basic sorting
algorithms so you feel confident in choosing one or kicking the tires on a new
one you've never heard of. Knowing how an OS is put together gives you an idea
where things should go.

------
jsd1982
I think the reason you don't see this kind of course offered is because it is
primarily concerning training and not education.

Imagine if your training course 25 years ago focused on the Turbo C IDE and
that's all the University offered. You would be amazingly proficient at Turbo
C and know all its keyboard shortcuts but that wouldn't be too relevant in
today's market.

Keeping such training material up to date with the latest trends is exhausting
work and not worth maintaining, especially given how difficult it is to
predict what may be the next tool de jure. Contrast this with more timeless
educational topics and it starts to be clearer why this sort of thing is
explicitly not taught.

~~~
kyralis
This is one of the issues that I have with how CS and software engineering is
taught in universities.

Yes, you could look at this as "vocational training" and not "education". But
you could also look at this as education with a hands-on component using
commonly available tools.

Sure, you could have students memorize a list of git commands. That would be
terrible. But you could also teach students to understand how a distributed
VCS works, the graph operations involved in commands like "checkout", "merge",
and "push", and the underlying way of thinking about data and how it changes.
That both provides students with an extremely useful practical skill as well
as setting them up for understanding much more complicated topics like CRDTs
and distributed data synchronization. And when the tool that was used gets
replaced, so what? If the concepts used by the tool were taught correctly,
then picking up a new one should be trivial. I've been through countless IDEs
and debuggers and version control systems in my career, but the _reason_ I can
do that is because at some point I learned _the first one_ of each and was
then able to transition that knowledge along the way.

"Training" gets looked down in a way that seems actively harmful to me. Just
because a tool might not be relevant in the future doesn't mean there's not a
huge amount of value that can be gained from learning it today.

~~~
thefunnyman
I absolutely agree. If we in the industry are expected to constantly remain up
to date on new technologies, it seems reasonable to expect our CS educators to
do the same. Realistically these tools change infrequently enough that courses
which teach these tools will likely remain relevant for at least the first few
years after students enter industry. I've had many courses in which my peers
didn't understand git even as seniors because it's not properly taught at my
school. If you enter industry without basic git knowledge you're going to have
a bad time and the one of the main points of education is to prepare you to
enter the workforce.

------
arman_ashrafian
At my school there is a 2 unit class that you must take along with the intro
DS&A course that teaches bash, vim, git, testing, etc. It was definitely the
class that helped me the most in my internship and also made me a Vim user.

[http://ieng6.ucsd.edu/~cs15x/](http://ieng6.ucsd.edu/~cs15x/)

~~~
0az
I too use (Mac)Vim.

In my experience, most CS majors at UCSD that I've met complain about the
course. On the other hand, DSC doesn't have an equivalent, which I find
disappointing but understandable. Maybe it'll get one in the future.

------
jedberg
It's funny, when I was in school, I was always told the difference between a
good CS school and an ok school was that the good school only taught you
theory and left the practical application to the reader. The ok school had
courses on tools and language syntax.

It's kind of awesome to see this coming out of MIT.

~~~
sombremesa
The world's best CS school is an internet connection.

~~~
xkemp
I'm entirely self-taught and can entirely understand wanting that belief to be
true, but it just isn't. A university can give you so much more than just
learning some programming language. At the very least, it's going to force you
to dabble in some languages you wouldn't ordinarily touch. The same obviously
goes for theory.

Assuming there are at least some things that require a minimum effort that is
uncomfortable before allowing you to see their benefits, you will discover
more guided by qualified people and well-designed curricula than on your own.

Then, there are the people: from my experience especially with Ivy-League
faculty, these schools seem to do _something_ right. Remember that _one
teacher_ from school that really got you into (reading
shakespeare/track/organic chemistry)? Yeah, they aren't all like that, but a
rather significant number seems to be.

~~~
theLotusGambit
> Assuming there are at least some things that require a minimum effort that
> is uncomfortable before allowing you to see their benefits, you will
> discover more guided by qualified people and well-designed curricula than on
> your own.

Perhaps, but sitting in the lecture hall isn't the only way you can get
thorough instruction from professionals. Books exist, and they don't suffer
from the same monetary, timing, and pacing issues that classrooms do.

The primary historical disadvantage of books- that they weren't interactive
and you therefore couldn't get help if stuck- is no longer an issue with the
internet. It's possible that the internet is too disorganized and low-quality
to be one's primary teacher, but its amazing supplementary value makes other
media tenable.

Those are my anecdotal opinions, anyway. But I'm curious, what do you think
physical teachers have to offer that Books/Online Courses/Podcasts/Whatever +
The Internet don't?

~~~
bigj0n
I think that structure, accountability, and community are the big draws
towards school. For young people I think that these are extremely important-
when I was in school- taking 6 classes meant I spent a roughly 40 hour work
week on school stuff. I had a really hard time doing half of those hours when
I wasnt in school.

Obviously that's more of a me issue than an issue inherent to self-learning,
but many of us have me issues.

If you're not the type of person who would benefit from structure and
community- the value proposition clearly doesn't make sense. Even if you would
benefit from those things- the value proposition isnt clear at all- its
tremendously expensive.

~~~
hatmatrix
I guess part of "community" is your peer group, but also access to an
authority to whom you can address questions (that won't leave you hanging,
most of the time).

------
xrd
My book about the GitHub API from O'Reilly had a similar idea: thinking in and
about tools is an important concept. O'Reilly permitted me to release it under
creative commons so you can find it here for free:

[https://buildingtoolswithgithub.teddyhyde.io/](https://buildingtoolswithgithub.teddyhyde.io/)

------
dahfizz
I really wish this practical stuff was more emphasized. I graduated with a lot
of very smart people who could write great code - but they could not compile,
run, test, or check it into VCS to save their lives.

It made group projects hell.

~~~
sf_rob
I graduated high in my CS class from a top school, but it turns out that I'm
just good at tests/abstract thinking/hacking things together with duct tape.
I'm terrible at software engineering, and really glad to see this kind of
stuff being emphasized at the university level.

~~~
gen220
Depends on your point of view, but it sounds like you’re great at software
engineering. :)

Abstract thinking and duct tape are the tools of the trade! The tools they’re
teaching in this course are just fantastic abstractions held together with
duct tape, after all.

------
cosmotic
Learning about a command-line debugger and command-line profiling tools would
be helpful for those that find themselves in the past. IDEA and Visual Studio
have had these things integrated for decades. I find the likelihood of knowing
how to use a debugger or profiler is inversely proportional to the amount of
time someone spends in the terminal.

It's astonishing how many developers rely on logging/print statements for
debugging. The learning curve of using a tool like PDB or GDB is just too
steep for most people.

~~~
bachmeier
> It's astonishing how many developers rely on logging/print statements for
> debugging.

One reason is that you don't switch contexts if you insert a print statement
in your code. I personally find that to be the least distracting way to debug.

~~~
porknubbins
I’ve tried using GDB and respect those who can, but when I am debugging my
short term memory is generally full trying to understand the program code and
trying to remember GDB commands clobbers that.

------
Aperocky
Non CS graduate here, funny how my learning curve has been basically what
y'all are saying.

I had one java class before I officially kick started my programming career by
wiping windows off my laptop and installing ubuntu. Then proceeded to force
myself to do everything from the command line, not that there were many other
options. It escalated quickly from there.

Starting from the terminal is much more intuitive than writing 'int main/
public static void main' in an IDE.

~~~
woodrowbarlow
> Starting from the terminal is much more intuitive than writing 'int main/
> public static void main' in an IDE.

i would take this a step further: starting from _any_ REPL is an advantage in
learning programming. the tight feedback loop fosters experimentation. python
is another good starting point in this regard.

------
trillic
Here's a link to a similar course offered by UMich EECS. I really enjoyed it
when I took it as an undergrad.

[https://github.com/c4cs/c4cs.github.io](https://github.com/c4cs/c4cs.github.io)

------
jacques_chester
In other engineering disciplines this used to be called "shop class" or
similar. In his day my dad was taught as much about carpentry, metal work,
plumbing etc as he was taught about radios and circuits.

As an educational technique, "sink or swim" is about as efficient as spinning
a wheel and handing out degrees.

------
saboot
This is not only useful for CS people, but to us hard science members. Coding
is a mandatory prereq.. which is usually one class on C or C++. Then we're
expected to collaborate on a project with hundreds of developers. This is a
great resource for those of us who are a bit lost, thank you.

------
sn41
When someone comes to me these days for knowledge about basic Unix/MacOS/Linux
CLI tools, I direct them to the GNU core utilities documentation - it is very
nicely organised according to task. I also demonstrate how CLI can do read-
based operations as fast as SQL on medium size databases (just take an SQL
dump and pipe) -

[https://www.gnu.org/software/coreutils/manual/html_node/inde...](https://www.gnu.org/software/coreutils/manual/html_node/index.html)

For various sorting and filtering followed by report generation in latex etc.,
a knowledge of awk also helps. I use the mawk interpreter since I have found
it to be slightly faster with ASCII format files.

------
sumoboy
It's sad to see freshman CS students getting thrown into this unknown world of
programming with zero understanding of basic programming principle such at
simple logic, tools, and even a book. I just witnessed this last semester
where the students first class was basically 'intro was a C++'. No books or
resources supplied or referenced.

So it even gets better when the instructor implies don't get help from the
internet or examples for assignments, in his eyes everything on the internet
is bad or wrong. I gathered he basically wanted the students to fail, what a
super hero. Glad to see the effort here to help CS students, great job.

~~~
leetcrew
it's even worse at the school I graduated from. the intro level course for cs
majors is in python, but calculus I is a prereq. so the students who are
catching up in math and/or don't quite feel ready for the real intro course
have to take the remedial course, which is in c. I was a TA/grader for that
course and what a shitshow it was. I don't think the professor ever explained
the concept of undefined behavior.

the highlight for me as a grader was the assignment where they first had to
define functions outside of main. many of the students didn't understand that
you need to actually return values from (non-void) functions. but in a lot of
cases, the value they were supposed to return happened to be sitting in $rax,
so they would end up producing the correct output. I was never sure what to do
in those cases; they lacked the conceptual tools to even understand what they
had done wrong.

~~~
vonmoltke
> the intro level course for cs majors is in python, but calculus I is a
> prereq. so the students who are catching up in math and/or don't quite feel
> ready for the real intro course have to take the remedial course, which is
> in c.

I don't understand, why would students who need to take Calc 1 not just take
the normal course the following semester?

~~~
leetcrew
I didn't explain that very well. students who were seriously considering the
cs major could certainly just take calc their first semester and then take the
real intro course next semester.

at the same time, the university basically considered having taken calc in
high school to be a proxy for the overall quality of the student's stem
education so far. so if you were one of those people, you were encouraged to
take the intro intro course first. this was also the course that people would
take who were interested in cs but weren't stem majors. it was a poorly
designed course for both purposes.

~~~
vonmoltke
Got it, thanks. Sounds like the "C for Engineers" class I took as a freshman
EE. Mine sounds like it was better-designed, though, possibly because it was a
gen-ed-type requirement for all engineering degrees.

------
tgbugs
In my graduate program (Neurosciences) the students with a computational
background usually realize after about two years that all of our colleagues
desperately need a basic orientation for how to actually use a computer to do
real work. The only institutions that I know of that teach the kinds of
courses we need are community colleges.

The curriculum presented here is an enormous community resource and I hope the
other institutions recognize the desperate need for a course like this and
allocate the resources to teach it.

------
nandkeypull
CMU has a similar course called "Great Practical Ideas for Computer
Scientists" (a play off of the infamous "Great Theoretical Ideas in Computer
Science") at
[https://www.cs.cmu.edu/~15131/f17/](https://www.cs.cmu.edu/~15131/f17/).

------
whateveracct
Purdue CompE has a required 1 credit hour lab that covered Unix command line,
bash, git, and a little Python. It's been the most useful credit hour I've
ever earned.

------
haileris
Good as a primer for those that aren't naturally hackers but decided to become
computer science majors and have little to no experience with a unix-like
operating system.

I learned Linux, the shell, basic scripting, and the terminal environment in
high school out of necessity and then began to thoroughly enjoy it. Planning
to enter university as a CS student I took the time to learn Vim, though I
didn't start using it regularly until much later.

I can't exactly articulate why, but I'm fairly upset these sorts of things
comprise an entire course. What happened to RTFM? Where is the general
curiosity? Even if you have no prior experience with a majority of these
things, these are the kinds of things you figure out over the weekend while
doing your regular courseload.

~~~
gowld
Why is Compilers an entire course? Databases? Operation Systems? All of these
topics are covered in books you can read.

------
beefhash
[https://missing.csail.mit.edu/2020/security/](https://missing.csail.mit.edu/2020/security/)

> An example of a hash function is SHA1, which is used in Git. It maps
> arbitrary-sized inputs to 160-bit outputs (which can be represented as 40
> hexadecimal characters). We can try out the SHA1 hash on an input using the
> sha1sum command:

Can we please stop presenting SHA1 as a valid choice for a hash function
anytime now? Especially in a security context? This passage is probably just a
holdover from the 2008 version of this page, but it's still frustrating to
see.

------
yodsanklai
I still remember my first week of engineering school (1997). Before the actual
classes started, we had an intensive UNIX week. I loved it. It seemed like the
real deal to me. I was already using linux at the time, but for the first time
I was properly taught things by experts, and not computer magazines. What was
my hobby was suddenly becoming something serious and respected. So much has
changed since then but I'm glad that to this day I'm still using the same
commands and tools.

------
joerickard
I just graduated from University of Colorado Boulder this last semester with a
CS degree, and am glad to say that this was a required course. It was a 3000
level course called Software Development that also incorporated a long form
group project for team cooperation skills. It definitely helped me to improve
my efficiency and organization when working on projects. Teaching
thoughtfulness in designing not only a solution, but a work environment, is an
important lesson.

------
chatmasta
When I was in college, we also followed a "traditional" CS curriculum. The
introductory language was Scheme. The language in core courses was C. Advanced
courses used whatever was best for the course, usually C or C++. Many of the
courses have had the same problem sets since 1985.

At the time, students had problems with it because "how are we supposed to
build apps with this knowledge?!" There were even student efforts to
"modernize" the curriculum by supplementing it with student run workshops on
app building (which actually did really well).

Personally, I really appreciated the curriculum. I was a self taught
programmer going into CS, having done lots of web dev and automation stuff
with PHP / Python. And I was really cocky about it. But as my adviser told me
on my first day, "yes, you're a programmer, but you are not yet a computer
scientist." I knew nothing about Computer _Science_ , and had never touched a
low level language, because I had no practical reason to. The next four years
were valuable for me because they forced me to learn about topics that I will
never teach myself.

And you know what? By the time I graduated I was fully proficient with git,
python, Javascript, bash, and a whole bunch of other tools and concepts,
despite the fact that no class forced me to learn them. I picked them up from
working with others, scripting tests for my assignments, and _my internships_.
It also helped to have the foundation of lower level knowledge. It's a lot
easier to understand the "magic" of your scripting language when you have an
appreciation of what it's actually doing underneath the hood. It's easier to
understand bash when you've written a shell in C. Etc.

For me, this approach worked well. School taught me the fundamental concepts
that haven't changed since 1985, which means they probably won't change much
by 2054, either. Who knows what industry will be using in 2054? I appreciate
that the school curriculum prioritized core, fundamental concepts over tooling
trends and the language _du jour_. Yes, it's important to learn those
practical skills, but they'll come with practice and experience in industry
(especially if you have 3 internships); there's no need to take a class on
them. And when the next one comes along, you can learn it in a week. Your
knowledge of the fundamentals will help.

~~~
s_trumpet
Honestly, this course would have been a game-changer for those of us who went
to terrible colleges with minimal opportunities for internships. The
disconnect between theoretical classes and practical ones was simply too vast
to grasp for the majority.

You sound like one of the top tier of students, being a programmer before
entering college (which I assume was a good one). There are colleges out there
where the faculty have only a theoretical relation to any actual useful
knowledge. E.g. my semester-long networking class actually had less content
than just watching a few YouTube videos. My operating systems class had a prof
who was so completely clueless about so many things I can't list them. On the
first day of class, he said "There are 3 OS (sic) - Windows, Mac and Unix" and
refused to believe a student who told him that OSX is a unix. My CS education
is entirely self-taught as a result.

------
tombert
I can't speak for any other schools, but before I dropped out of Florida
State, they had a class called "Intro to Unix", which was only worth one
credit.

We all were given login credentials to a server and our assignments were
typically Bash scripts; there was one class spent on Vi, and the professor
combined the Nano and Emacs class together. We also learned how to do
Makefiles and how to run GCC...

I had assumed that this was standard in most CS majors...was I wrong?

~~~
vaughnegut
Very wrong, unfortunately. At my school there are students halfway through
their degree who can't switch a git branch without using a drop-down menu in
their IDE (and even then with difficulty) or have ever used the CLI for
anything. The place students tend to learn these things is their internship.
The first one is typically a turning point in their programming and tools
ability

------
terminaljunkid
Thank you a lot for posting this link.

I am majoring in CSE in India and I think you guys have it still better.
India's engineering education (maybe except IITs) is completely screwed up by
people who don't know what they are doing. The average student here doesn't
come out of interest but for sake of getting some job. There are lot of people
who don't understand difference between text editor and word processor till
end of the 4 year program, but still get an 'S' grade (>90% score) because of
rote learning system. Leave alone mastering the tools, they expect to open a
PDF/docx in their phones and copy it to the computer. Having said that, the
college I study is one of "top" colleges of the state.

They foolishly waste 1 year in our life by teaching "common" subjects like
chemistry, physics, elements of {electronics,mechanical,civil} engineering
etc.. I mean, they may be somewhat marginally useful, but they waste time and
money for that while there's lot of stuff to learn in CS itself; just because
some baldhead decided it would be good to teach all subjects to engineering
students in first year.

I really wish I could study in US.

------
daniel_rh
2 words: bash reduce

(eg using cut, sort, split -l, nohup, ssh to orchestrate a massive job with
only bare unix tools available)

------
pgcj_poster
All of this seems like stuff I would expect someone studying CS to pick up on
their own. I learned to use git in college, but not because anyone taught me:
I just figured it out because I had group projects and needed version control.
On the other hand, there's no way I could have possibly learned how something
like ray-tracing worked without learning it in school or doing some really
intense self-study. I feel like it's a waste of class-time to teach stuff like
git, shell scripting, etc. If you're smart enough to understand graphics or
compilers, you should be able to learn those tools on your own without any
trouble.

------
daxfohl
I wonder how different things would be if cs departments had a special lab
without mice.

------
mannykoum
We had a similar course at Columbia (half semester, 1 credit). The professor
was good and the information pretty useful; very similar material to this one.
The paradox was that for the ones who knew the significance of such a course,
well, we had already learned most of these things the hard way. Maybe our
other CS profs should have advertised the course as an optional requirement to
get people interested early instead of their junior/senior year.

------
peter303
I have a MIT degree and learned these when I encountered them in my work. An
important thing is to learn how to learn for the rest of your life.

------
cnees
University of Michigan had this as an elective three or four years back, and
it's served me well to understand things like piping, output redirection, and
reflog. I'm glad MIT's making this public. It seems like it could fill a big
gap for people who don't have the mentorship to know what they don't know.

------
deadgrey19
This is a standard second year CS course at UNSW:
[https://cgi.cse.unsw.edu.au/~cs2041/19T2/index.html](https://cgi.cse.unsw.edu.au/~cs2041/19T2/index.html)

Topcis included: Shell Perl Git Javascript Webservers Make Performance tuning

------
amai
Vim? Why not teach a real IDE like Eclipse or Intelij Community Edition? It
has much better auto-completion, has a GUI for Git, debugging and profiling
etc.

Also I'm missing test driven development or at least unit tests in the
curriculum. Reproducible results are important, even at university.

------
rawoke083600
I could add, one course or two about "communications" the one with people in.
Most of us will spend our times in teams, with highly opinionated and
sometimes conflicting individuals. Computer programmers don't know how to
listen or to respond, we mostly just react.

------
fao_
To be honest, I was kind of disappointed with this, because most of it I
already knew! (That's not a criticism of your course c:)

In the vim section, you might want to cover `*` - go to next match of current
word and `#` - go to previous match of current word

------
mhh__
Probably at less depth but I ended up learning quite a lot of these topics at
GCSE (16ish), with the exception of proper version control although I taught
myself git and C++ instead of actually working. Probably quite lucky in
retrospect

------
tester89
We have a class like this at my uni and it’s the most hated class for the CS
course.

------
alienlike
In my observation (at a major research institution), some grad-level CS
students lack an even more fundamental skill: touch typing.

------
adultSwim
I thought it was going to be communication or active listening.

------
robomartin
> Vim avoids the use of the mouse, because it’s too slow; Vim even avoids
> using the arrow keys because it requires too much movement.

I'm sorry, it isn't my intent to start an editor war. Use whatever you want, I
don't care. Just don't lie about it. I expect far more from MIT than this
nonsense.

VI and VIM are what they are because keyboards of the era --and the entire
UI-- looked like this:

[https://retrocomputingforum.com/uploads/default/original/1X/...](https://retrocomputingforum.com/uploads/default/original/1X/d4ee796ce7397d62b975d7ab03a8e0975146b330.jpeg)

Notice the location of the Ctrl key. It used to be where the Caps-Lock key is
today, making it FAR more convenient and comfortable for entering Ctrl
sequences.

This is from a Tektronix terminal, which I used in the early 80's. Here it is:

[https://www.computerhistory.org/revolution/input-
output/14/3...](https://www.computerhistory.org/revolution/input-
output/14/349/1826?position=0)

The VT-100, if I remember correctly, introduced four cursor keys:

[https://www.computerhistory.org/revolution/input-
output/14/3...](https://www.computerhistory.org/revolution/input-
output/14/349/1849?position=0)

I also used VT-100's and clones during the '80's.

[https://www.computerhistory.org/revolution/input-
output/14/3...](https://www.computerhistory.org/revolution/input-
output/14/349/1697?position=0)

Notice the total absence of anything even resembling much more than a simple
typewriter. No mouse, function keys and other modern facilities.

So, yeah, if you were writing a text editor at the time, you would be well
served to do such things as implement modal view/insert operation for more
reasons than just the archaic keyboards. These terminals were used to connect
with remote systems at VERY LOW BAUD RATES.

It's hard to imagine that BAUD 300 or 1200 was great speed at some point in
history. In that context, cursor keys or grabbing a scroll bar with a mouse to
yank it around with abandon made no sense. You were literally only able to
receive from 30 to 120 characters per second...and a screen with 80 characters
by 25 lines had 2,000!

This is another reason for which escape control commands had to be invented.
You had to be able to address you 80x25 canvas and place text where needed
rather than to refresh the entire 2,000 character screen.

This is why, quite frankly, I hate the "cult of vi". Cult members are, for the
most part, people who have no historical connection to where this tool came
from and why. We, at the time, would have KILLED for a graphical UI with a
mouse. Yet that was impossible at the time due to both machine and connection
speed limitations. You literally could not have used it even if you had it.

So, yes, at the time, if you had to write a text/code editor (I wrote a few)
you had no choice but to use a bunch of Ctrl-<something> codes and perhaps
even implement a distinction between reading and inserting code. I still
remember sequences like Wordstar's "Ctrl-k-x" running on an 8080 S-100 system
with, yes, a VT-100 terminal attached.

Yes, the VT-100 introduced four cursor keys, but if you were writing software
at the time you could not make the assumption that the user had access to
cursor keys, most keyboards did not have them until much later. That
assumption was not safe when VI was created.

Like I said above, use whatever you like, I truly don't care. Just don't lie
to yourself about it, particularly when the truth is a matter of history. I
think most people who came up through that era of computing laugh at the
vi/vim cult because from our perspective --not yours-- it is complete
nonsense. This text editor had NO CHOICE but to be as it is due to being
written for crappy computing hardware and environments of the time. If you had
to use one of those systems today you would be horrified. If you had to write
a text editor back then you would write it exactly this way. And the minute a
decent an ubiquitous GUI showed up you would drop it like a hot potato and try
to forget the nightmares.

MIT Computer Scientists ought to know history and not print nonsense like
that. That entire paragraph about VI is basically wrong, historically wrong.
You can leave it like that and perpetuate a fantasy or correct it and at least
show some respect for history.

And then do everyone a favor and explain that the speed of text entry is of no
consequence whatsoever. MIT should not propagate that cultist belief. The time
devoted to things having nothing to do with text entry is, in some cases,
orders of magnitude greater than text entry. Not everyone is a PHP script
kiddie. Some of us are writing real and complex software, some of it with
life/death potential, and code entry is so ridiculously low in the scale of
where time is spent and what things are important that it is absolutely
laughable to talk to someone who has become religious about text editors
because of stuff like this out of a respected university. Do you really think
code entry speed and efficiency is important at all when working on the code
for an MRI machine, a space capsule or an implantable insulin pump? Exactly!

If coding is factory work, then, sure, mechanize as much as possible and count
strokes. That would be the day I become a gardener.

~~~
molteanu
> Vim avoids the use of the mouse, because it’s too slow; Vim even avoids
> using the arrow keys because it requires too much movement.

I haven't read the article, but this reads to me as "using the mouse is too
slow, so try VIM instead and soon you won't need to use the mouse anymore."
and "Reaching for the arrow keys takes too much time, so try VIM and keep your
hands on the home row for added productivity.", respectively.

~~~
robomartin
The point is that this kind of productivity does not matter at all. I mean,
not even 0.00001%.

We deliver complex hardware + software products that have to work correctly
under challenging conditions and, ideally, not kill anyone in the process or
burn down entire buildings. We do not deliver code-entry athletic performance.

In a typical project code entry time is so ridiculously insignificant that I
would never hire anyone who came in and made the typical vi/vim argument about
efficiency. This would instantly tell me they have no mental connection to
what is actually important.

Another element is that, when you work in a multi-disciplinary environment you
don't necessarily have the luxury of sticking with one tool. Which means
devoting a lot of time on something like vi is pointless.

Another view: Say you have a team of 100 software engineers and you have to
get a complex product out the door. Would taking a month off to train everyone
to become a vi/vim ninja make this team deliver properly working bug-free code
sooner and at a lower cost? The answer is, of course, no. Or, more accurately,
no f-ing way. That's why this cult of efficiency is misguided.

