The Missing Semester of Your CS Education (2020)
missing.csail.mit.edu
missing.csail.mit.edu
Learning Outcomes:
1. Understand Unix/Linux commands for navigating directories and files and manipulating files and folders.
2. Understand terminal commands for searching and input/output redirection.
3. Understand shells such as sh, csh, ksh, tcsh, bash, zsh.
4. Understand debugging via print statements and general debugger concepts.
5. Understand version control via Git and Github, source control, workflow, commit, collaboration, pull, push, create and pushing a new repository, cloning, branches, merging, and conflicts.
6. Understand vim including mouseless navigation, normal/insert mode, copy/paste, search/replace, and saving/quitting.
https://selfservice.mypurdue.purdue.edu/prod/bwckctlg.p_disp...
The only time I found it to be a liability was when I was pair programming. My pair couldn't read a shell script to save their life & had very little interest in learning. When I tried explaining it line by line, they stopped wanting to pair because I was apparently making them feel stupid. They actually reported me to management for being an arrogant mansplainer. I'm pretty sure that was the beginning of the company deciding I was not a culture fit :P I had to learn how to, and how not to, work with someone less experienced in a certain topic after that.
One of the downsides of pair programming is that it's great when you both have complimentary skillsets. It's less productive when no one knows what the heck is going on. In this case, the task was to benchmark how many writes one could make to Kafka using our monolith. They wanted to see at least 10K/writes per second. The only problem was no one knew how to use Kafka (well), including the person who was asking for it.
So I wrote some gnarly looking Bash code to fire up Kafka, Zookeeper, the app, etc. Some people wanted to use Docker, but I didn't see the value in using a slower VM w/ limited resources. I wanted to use as much CPU as possible. My pair didn't know Docker, Bash, or Kafka. I lost my pair somewhere around talking about having to clean up zombie processes.
It went downhill from there.
Yes, cultural fit is real, and it isn't always about white men drinking craft beer.
Builds work quite different in Java, for instance.
> Understand shells such as sh, csh, ksh, tcsh, bash, zsh.
I was taught csh as an undergrad. A complete waste of time, in my opinion, akin to teaching BCPL rather than C. Just teach bash, and perhaps sh. To my knowledge, just about nobody writes scripts in csh, ksh, tcsh, or zsh. You use bash for portability across Unix systems, sh for even better portability across Unix systems, or you use a modern scripting language like Python3.
Students may benefit from learning zsh for interactive use, but I don't think there's enough benefit there to justify spending time teaching it.
My company still does intro lessons with ksh because it's set as the default shell on all of our servers.
I think it's worth focusing on Bash, but at least contrasting it with csh and pointing out the lineage and other options. Perhaps spending some time writing some scripts in sh since there is a large install base of outdated or missing Bash.
I have no idea what schools think about this. I generally prefer deep knowledge in a single language, but there is value in learning a bunch of languages so picking up yet another new language is trivial. When I've spent too much time in one specific language I've found it harder to switch around.
In my company the default shell in the UNIX accounts is csh, and tcsh is recommended as a "nicer" csh. They do have bash if you want to use it, but they only "support" csh and tcsh. As a result, many important scripts by engineers are written in csh/tcsh. People who've never used bash. Very annoying, as for those who choose to use bash are often told they have to go into tcsh to get a given program to work, etc.
IMO it’s better to focus on fundamentals like math/algorithms that can be applied in multiple areas rather than specific tools.
Everything in a CS curriculum is easily Google-able.
Being functionally illiterate at the command line is harmful for productivity, so I think it's deserving of some in-class attention.
Imagine handing this to a person who's never heard of a shell, doesn't know how to `cd` or `ls`:
https://www.gnu.org/software/bash/manual/html_node/What-is-a...
> 1.2 What is a shell?
> At its base, a shell is simply a macro processor that executes commands. The term macro processor means functionality where text and symbols are expanded to create larger expressions.
> A Unix shell is both a command interpreter and a programming language. As a command interpreter, the shell provides the user interface to the rich set of GNU utilities. The programming language features allow these utilities to be combined. Files containing commands can be created, and become commands themselves. These new commands have the same status as system commands in directories such as /bin, allowing users or groups to establish custom environments to automate their common tasks.
"Macro processor?" "Expressions?" "Unix?" "Command interpreter?" "GNU utilities?" "Directories?" (you mean folders?) "/bin?" "Environments?"
My undergraduate advisor said since the second-semester lab was the basic lab, the first-semester lab had to be the basement lab.
Not in my experience, it isn't. Maybe for the first two years of undergrad but after that I've found that Google rapidly becomes useless.
The class almost went off the rails the first time before I realized half the students didn't know what a text editor or shell was. I ended up writing a document at a slightly lower level than this "missing semester" course (though taking some inspiration from it).
If I teach the course again, I plan to do one week shell bootcamp with "get to know your system" exercises spread throughout.
There are four quadrants of knowledge:
1) What you know you know
2) What you know you don't know
3) What you don't know you know
4) What you don't know you don't know
College is in large part about covering (4) and turning it into (2) or (1). You're describing turning (2) into (1) - you need to know what to Google in the first place.
Even if (at first) students just do a single `git add --all && git commit -m "finished project"` it goes a long way to just exposing people to the concepts. Provided the infrastructure is in place (eg GitHub or gitlab instance), it really isn't much different than dealing with a zip file, but provides 10x the educational value.
Bonus points to the prof that builds assignments that involve git branching from an earlier assignment.
I didn't study Computer Science to learn how to write bash scripts.
The good ones are really CS + one extra year worth of projects and practical coursework, like learning what Agile is, Source Control, Build Systems and so on.
CS 193 was a very low effort class (1cr), where you could follow the command by command instructions and perform all the tasks necessary to pass.
Unfortunately tools like git, vim, and shells all possess philosophies and concepts that are very hard to grasp without context, and constant use.
We were on multiple occasions told the mantra, add-commit-push, which I will say is enough for basic git usage, but since pretty much none of the subsequent classes used git to any capacity, I would assume many students lost all familiarity within the next semester (Makefiles that automatically git added and pushed code were used for submitting code).
I also think most people were hindered by vim, lacking sufficient instruction but still being presented it as the primary option.
I think if you’re going to implement a similar class / program, the tools really have to have uptake beyond a single course.
Sidenote, the different shell types weren’t covered in my semester, we just used bash / dash.
I think the trade-off on timing here is with internships during the summer after freshman year. I think you’ll have a much better chance of success if you’re at least roughly familiar with these workflows vs. interns who are totally unfamiliar with version control systems, for example. And perhaps that’s all the course is meant to accomplish at 1cr.
One of the students I was friends with was much younger than me, smart kid, very good in the camp, still college age / situation in life, and after the bootcamp he decided to go back to school for a CS degree after some "hey you're more than capable of qualifying for a lot of scholarships" type discussions.
Anyway we met up a while later and he described how he was in these classes with theory and various languages and so on.
Then the students would do projects together and they'd look at him like he was a wizard with what were fairly rudimentary debugging but still similar skills to what us described in 'the missing semester of CS education', or at the very least the ability / lack of fear to pick them up fast (something that if you're good at it is super handy in a fast moving boot camp).
I remember when I was in college (dropped out for a variety of reasons) I really hated theory or 'just learn this focused thing you'll understand later' type classes when I just couldn't see ... the end use / test that end use in front of my face.
It occurred to us that a sort of 'full stack light' boot camp almost would be a good intro to some of these deeper programs. Even if just to give some level of ... practicality / way of testing / seeing output ... etc.
No doubt that many schools / departments would be averse to such a system for a lot of reasons. Even the bootcamp I went to was hosted by the same large university... but was sourced bought from some outside company and had NO association with the CS and similar departments.
At a larger tech co I am consistently seeing boot campers coming in better prepared and with more hustle than CS grads. It would be interesting to see if their acceleration through the ranks is on average faster. It definitely is from my anecdotal experience.
That's a stretch.
What I've seen with Bootcamps is that they know one stack and how to do one thing only. They are really productive in that one stack but lack the more fundamental understanding that CS grads have.
When it comes to learning a new stack, technique or solving harder problems, the CS students run in circle around bootcamp grads. But to the non-technical manager, they see the bootcamp kids writing code on day one so they naively assume they are better.
I'd be surprised if the bootcamp hires weren't better in the short term for specialized lower-level roles using newer tech. But many of the bootcamp learnings will be obsolete in 5 years; CS fundamentals are obviously more timeless.
I know bootcamp grads that are now staff level engineers at FAANG or equivalent companies (based on levels.fyi pay bands). The money is in the bank. The RSUs are vested. They are only in it because they want to be at this point
Obviously not most boot campers but most engineers of any kind regardless of background wont reach that level.
I have never seen a CS student "run circles" around a bootcamp grad after equivalent experience.
It is telling that "The Missing Semester of CS ed" would be laughably basic to most boot campers and last I checked would be done as part of the pre-work to get into the bootcamp to begin with.
Side note: The bootcamps around today are much much better than 5 years ago. They are iterating rapidly.
The best people I have worked with have been HS dropouts (fully self taught), MIT and a CMU grad who were very self taught before their program, and bootcamp grads who pivoted from other fields (oddly music, fine arts, and a standup comic. Maybe because in those fields being "good" is completely insufficient and they bring a "must be the best" mindset?)
I like how fundamental knowledge is treated as trivia. It's an interesting perspective.
> Side note: The bootcamps around today are much much better than 5 years ago. They are iterating rapidly.
Citation Needed here. Almost once every two weeks there are testimonies from Lambda's students that beg to differ.
A couple areas I would add
* How to ask questions [1]
* How to debug problems, control, hypothesis, baseline
* Reproducible research [3]
* The Art of Doing Science and Engineering - Learning to Learn, Richard Hamming [4]
* How to Solve It, George Polya [5]
* How to work in teams, collaborate?
[3] https://esajournals.onlinelibrary.wiley.com/doi/full/10.1002...
[4] https://www.youtube.com/playlist?list=PL2FF649D0C4407B30
They did eventually realize that teaching some of the basics would actually make for more successful students, and better alumni donations.
In the end, the CS Dept. started offering these things as zero-credit courses as a way to square the circle.
[EDIT] incidentally, the arts are also infamous for being dominated, at a professional level, by kids with artist parents and kids with rich parents (who can bankroll years of private lessons and then years of little-to-no income while paying for access to career-makers) so... there's that.
Of the 22 people in the class, 21 of them were singers - everyone except me. Much of the class was around singing - singing scales, etc. I saw nothing in the syllabus that required singing, but... you had to learn to sing stuff by sight reading, and... I'm not a singer. It was embarrassing for me (and probably for others). I think I managed to drop out before losing all my money on that, but... frustrating. Could also tell most of these people had had voice lessons for years, and were all taking this class as a way of getting in to theater work, not... to play an instrument.
That feels roughly analogous to a CS department requiring a "*nix skills" course or similar, as most liberal arts degrees require a substantial amount of writing.
I assume music (and possibly some fine arts) would require some background in those subjects. They often require a portfolio or audition before entering the program.
Do engineering programs expect students to have taken calculus?
Though with music (and possibly engineering), you likely have to prove ability prior to being accepted into the program.
I don't know how people coming in not having sunk thousands of hours into computer crap before entering a CS major don't drown in a hurry. It'd be like starting a creative writing degree in a world where reading & writing aren't taught in school, except maybe as a one-semester high school elective, and you're just expected to have picked them up on your own time by age 18, if you're going to be a creative writing major. "OK, you're familiar with stories from watching TV, but now you're going to need to read and write them. If you can't read them here's a book(!) to help you learn to read, in you own time. Good luck anyone who wasn't already a long-time reading-and-writing nerd before choosing this major".
Of course some of the problem is that CS programs use computers so much. Which I know may seem like a silly complaint, but I think the fundamental issue is CS-the-science being mashed together with what's really a vocational program (which is what 99+% of students and employers actually want out of it, and its being "real" CS is mostly just an IQ filter). I imagine if you go into, say, a junior college HVAC program not knowing which is the business end of a screwdriver, you'd also be at a big disadvantage compared with most of your peers, and probably feel really out-of-place for quite a while.
I took MIT's "Intro" to Programming and Algorithms I think it was called (6.001). I'm not a professional developer but I've written a fair bit of code including Python which is what the class used. I'm pretty sure that, as an undergraduate, had I never seriously used a computer command line before, there is no way I could have gotten through that course.
The same dynamic is largely missing from other engineering courses, as well as the sciences, which don't really expect more than high school classroom work, an interest, and general aptitude.
And it's certainly true that CS (the math degree) gets munged with CS (the engineering degree). MIT's a bit more engineering focused (the degree is in the engineering school). There are also some variants of the degree that are more or less engineering-centric.
You're not going to meet that kind of abrupt and early resistance on the path to becoming a doctor because you didn't spend tons of your free time as far back as junior high reading anatomy books or practicing dissection, for instance.
Again, there are almost certainly other factors, and correlation is not causation, but there is at least logical correlation.
To your broader point, a lot of kids enter college with only a broad idea of what they want to do. And high school courses don't really offer much guidance. High school science classes have very little to do with their counterparts at good colleges.
[1] https://www.aei.org/carpe-diem/chart-of-the-day-the-declinin...
Meanwhile there are definitely a lot of gatekeeping-assumptions about childhood interests in modern CS programs, which one would expect to have gotten stronger as more and more freshmen actually could have had experience with computers on their own—so, starting with late-80s freshmen, mostly, with the effect getting stronger fast after that. That lines up so well with the data on CS-program-enrollment-by-sex that it seems to me like the factor to examine before we go looking for other explanations. Again, to be excessively explicit due to the topic, I mean this in terms of accounting for the gender gap in programming, not in terms of addressing any other issues of sexism in the industry, which I am not denying exist.
It's much more inclusive indeed. If you can afford the mandatory completely unrelated undergrad you need to have completed to even apply to med school and the travel fees to attend your in-person interviews of course.
No, instead it's unrelated to the field so you can grind fractions of GPAs against other applicants. At least, CS is kind enough to let everyone try the real thing.
They don't call it the firehose for nothing. [0]
There's been some research on this and places like Harvey Mudd solve this basically by dividing the incoming freshmen into 'has any experience at all programming' and 'completely new', which was like 50-50 if I recall. And then tweaking assignments to not be video game focused -- pulling in problems & themes from bioinformatics and other fields instead.
Our only program of any significance in CS101 was a space invaders clone, but because we were so inexperienced, they provided a project template where we really just had to fill in some methods with a bunch of for-loops. When we got to the later courses and had to write our programs from scratch, we really had no idea where to begin because the 101 coursework had done all of that for us.
The video game assignments were asinine because they were beyond our skill level to do from scratch, so their templates handled all the I/O for us and that part of the program was treated like a bunch of magical incantations. As a result, we never fully internalized how all the moving parts fit together, and it kept us from learning useful stuff like how to read/write from files or execute system commands.
Difficulty of any given program at the undergraduate level is completely dependent on university policy. Maybe at the research level, you truly need to be more intelligent / harder working / whatever to succeed in math than in art history, but at the college level, you could do for instance:
- cram all that is taught in current undergrad, MA, and PhD (including the thesis) for art history in 4 years
- let CS students graduate if they can write any working program in any language of their choice
Tada! Art history is now the hardest degree in the college where only the best students aren't weeded out out; and CS is the easiest degree there is.
My point being that CS departments assuming prior levels of CS unlike other departments is merely an instance of a larger pattern.
I'm sure it would be considered a laughable course to teach at an elite school today. (OK. It was a bit harder because we were using punch cards and we had to beg for more computer cycles if we made too many typing errors, but still.) But I'm pretty sure it wasn't because we were a lot dumber back then.
I agree with your basic point though some students do freeze up with even relatively easy math. But, yes, you could put together a relatively easy programming course and call it CS. And liberal arts courses are not necessarily easy today--especially at a good school. You'll be doing lots of reading and writing.
That's the opposite of my point, really.
> And liberal arts courses are not necessarily easy today--especially at a good school. You'll be doing lots of reading and writing.
My point was about the "within university" variance of student levels rather than the "between university" variance. I have no doubt that a liberal arts programs in a good university is more selective than the CS program at a particularly non selective university. However, within any given college, I'd be surprised if the liberal arts program manage to get the above average students and the CS/Math/... programs get the below average students.
It wasn't until I got past the first few java heavy intro courses that I realized I had a huge leg up on a lot of the other students that only had experience with Windows or Mac. Before that I felt like I was behind behind the curve because I was stubbornly writing Java in emacs because I couldn't stand how dogshit slow Eclipse was, so I didn't have the advantage of the code-completion or project management features.
Looking back on it, the curriculum was actually just holding most students back even further and by using emacs and managing my projects from the command line, I was just increasing the lead I already had over students that didn't have linux experience.
Since the 70s, AI was dominated by lisps and nearly everybody was driving at "general" AI by emulating or even attempting to simulate human thought processes.
In the 00s people started putting more weight behind statistical / stochastic methods for arriving at answers without necessarily trying to use any model of human cognition. This was called "data mining" and then "machine learning" (partly, I presume, to distance it from the 40 years of academia's dismal failure to produce working AI) and only in the last ~5 years has it come around to people starting to use the term "artificial intelligence" again.
In the early days of the revamp, it was common to see janky perl and fortran and not much structure holding it all together. Lately, I gather, the ecosystem is nearly entirely python-centric, but this is due to the gravity well around pandas. There's nothing in particular about python that makes it suitable to the task, though it is happily more approachable/accessible for academics than if a pandas equivalent had instead evolved in C++ or Java.
It is very sad that we need to take two entry level programming language classes in the first year. My university does not allow me to remove it as it's the pre-requisite of pretty much everything else. And I can't "prove" that I know Java, which I didn't but I'm confident that I can get the basics going in one day and the basic-medium stuffs in a week because I already know some C, C++ and Python.
The only class that I think should teach programming languages should be a PL class. An introductive one usually teaches three or more languages in one shot with each an example of a paradigm.
BTW the zero-credit courses sound like an excellent idea. Students do not get credits but still get education out of them. It's a great practice.
Java as a language is actually tiny. So are most languages. Most of the pain is in the tools, build chains, and libraries that go along with them. Also sometimes what works very well in one lang is a pain in another. For example the dictionary in python has no real equivalent in C, unless you use some lib or write something yourself. In java you would need a map or hashmap class and knowing it exists sometimes is the biggest hurdle. But at least it is in the std library. So sometimes those sharp edges bite students as they are first starting with new langs and have decent exp in another language.
SCIP (well loved on HN) was designed for as the introductory class for freshpersons who'd never seen a computer before (which was the default case when the course was designed).
The first lecture was about how to program in lisp, using the example of symbolic differentiation. That one lecture was 100% of the introduction to computers and programming: the rest of the semester was spent on computer science.
In retrospect they could have put more focus on debugging tools as well. But since they didn't mandate one particular system--we had projects where every kid was using their own development environment, from VS on Windows 95 to vi, gcc, and Make on FreeBSD all developing on the same codebase. It sounds like development hell, but it made porting the app to all of the target platforms a breeze.
Can you share more info on that?
(For reference, I had that happen at least twice in school, where the group of us broke up the work and scheduled check-ins, and by the end of it only I had done my part...though being cynical, as the team missed check-ins with various excuses, I had also done everyone else's because I cared about my grade)
Unlike the real world, where if someone is allocated work, and doesn't do it, a manager deals with it. Professors are not interested in being managers.
That said, it DOES sound useful for the real world, where the incentives are better aligned.
I should have taken it first semester, freshman year. It was full of invaluable meta information which would have made my four years not only easier, but more productive. I may have even stayed in Chemistry if I had the correct tools from the start.
I am largely self taught when it comes to CS, and so I learned these tools first from a practical application. I didn't have anyone to set up a dev environment for me; I had to do it myself. I am always shocked when I work with new grads from top CS schools who have almost no knowledge of basic tools like grep or how to use an interactive debugger.
Theories and academia are nice, but are a fair stretch from the real world in any field. If we really want to require an advanced degree to enter the work force, then we should abandon the idea that most students attend college for a liberal education and accept they reality that students attend college for workforce preparation.
Teaching tools of the trade is, well, a trade school thing. I suppose you have to decide if the degree program is more like "Prep school for FAANG" or a program to teach people how to be computer scientists. When I see classes like this I flashback to the required "Problem Solving" class I had to take as part of my CS degree which was a full semester of "How many windows are there in NYC?" or "How many bowling balls fit inside a Boeing 747?" Biggest waste of time considering Google and the like had moved on to HackerRank/LeetCode style questions years ago.
Coming from a school that's known as a good technical/engineering school I found the CS program to be a bit lacking on the "CS" part. Lots of outdated classes on "how to develop for the web/mobile" and such.
Where do you draw the line? If you don't have tools and knowledge of tools you're not going very far in a "pure CS" degree, either.
I'm watching the git/VCS one now and it's still touching a great deal on CS concepts, so it's not just "here's 10 git commands"
These skills (VCS, debugging, etc.) are incredibly important in being a software engineer and could certainly have a place. I think I'm likely to fall on either side of the fence depending on how things are implemented in any given case.
I have a bit of "PTSD" so to speak from my degree program. Lots of checkboxes for focuses in your major or minors to be awarded for taking a bunch of outdated classes that were largely things like "How to use Android Studio" rather than a more generalized class on "programming for mobile".
I think what happened in my program is the department saw things students needed in order to be successful in the field: learning to program for mobile/web, cyber security, etc. And instead of putting together good classes on the theory and backbone of those areas they created a bunch of "trade" electives that got outdated before they printed the syllabus.
Also the vast majority of students took an internship in the field myself included, and on the job was where I learned a lot about trade related concepts like VCS, flavor-of-the-week Agile, etc. I just don't want to see CS degree programs become expensive and outdated bootcamps and that's the direction I feel my alma mater's CS program was heading in a lot of ways.
I disagree. So much of our computing literacy is in how to _use_ the systems, and understanding concepts of using the shell, debuggers, source control, etc.
I see these kind of classes as more similar to the foundational courses in math you take before you dive into Calculus. If you haven't studied algebra, or memorized arithmetic facts, it's going to be very rough if you start into graph theory and Calculs I. Math and science majors already have students who have spent literal years being exposed to concepts before they get to college.
Less flippantly: I think everybody knows that "computer science" BA/BS programs are feeders for the industry (almost exclusively in both directions -- it's hard to get an industry job without a BSCS and the overwhelming majority of BSCS go into industry instead of academia, more so than other bachelors programs).
There are people who wish there were separate tracks for academic-minded folks and industry-minded folks, but young industry-minded folks generally don't want to go to a "trade school"s, they want to go to college and enjoy college culture before they go into industry.
So I'm generally hesitant to classes that can easily become "Here's how to use Android Studio".
There was such a lack of understanding when it came to debugging that many people graduated still not knowing how to print a register. I worry about them because a lot of man hours were wasted in stupid errors, they would come to me after struggling for several hours. I'd take their applications, compile, run it once, see how it failed; then ran gdb and each and every time it took less then 15 minutes to find the issue.
They called me "The Woz 2.0" (my first name is shared with the brilliant man associated with that nick) but it wasn't difficult or some great feat; i literally just used a debugger, like anyone should know how to do.
It was a sobering realization for sure. The future of application development lie in the hands of many who are not only scarred of debuggers, but only ever know how to use them in an IDE
Version control is the most common thing I have to teach interns in general & that too remote version control usage - particularly my "oops, I dropped my laptop after 3 weeks" story.
Git makes that curve a lot less complex to deal with (no server setups).
The other bit I tend to drill down into is about writing graphviz files for everything.
Mostly what I do is generate code and documentation out of one system - but often, I dump out things in some arbitrary format, only to process it in python in to a graphviz diagram or in some cases some more fancy svg stuff (outputting direct D3.js is better, for something like a Sankey diagram for data-flows).
Like this[1] is a way to discuss a problem with a cycle in a DAG, instead of whiteboarding it out, particularly if your work-mates are going to be remote.
[1] - https://gist.github.com/t3rmin4t0r/6991ce21b41b2558c5362455c...
This way, as a TA, I can also code review them and it also deters plagarization.
If you're only going to teach one editor, why an editor that's so arcane in comparison to something similar to a text editor like Sublime or Atom? If you're going for a terminal-compatible editor, why not Emacs or Nano? If you want the most workplace-ready tool, why not Intellij or VS Code? And my main question, why not at least teach a few and empower the users to really explore and find the best tools for them? To me this smells of people who don't want to help students equip themselves for success and instead want to teach them the "right" way to do things.
Time. It's supposed to be over their IAP which is about 4-5 weeks or so.
This is a continued course just put together by a bunch of grad students of things they have to learn on the side or not emphasized enough.
Pragmatically, Emacs is usually not installed by default on Linux systems and Nano sometimes isn't. If you had to pick a command-line editor to teach, Vi/Vim is probably the safest bet.
(Unless you mean for workstations or servers people constantly log into, as I’m thinking of containers).
I learned emacs over some months; I had a job as the IT support guy and I wanted to become a Unix C developer, so I grabbed an unused HPUX workstation, sent all my email to emacs, and then spent months learning how to use it. Probably six months before I was using it decently well.
which is honestly fair because emacs is essentially a full-on lisp machine with a set of excellent text editing utilities.
So, basically, it's popular, useful, and they know it. But, even before saying that they provide this caveat: "As programmers, we spend most of our time editing code, so it’s worth investing time mastering an editor that fits your needs." Then they devote a little of time explaining how to best learn any editor.
Also, in the QA they say "The three of us use vim as our primary editor but Emacs is also a good alternative and it’s worth trying both to see which works better for you.... An advantage of using Emacs is that extensions can be implemented in Lisp, a better scripting language than vimscript, Vim’s default scripting language."
They did explain that they based there decision based off the most popular command line editor (based on a stack overflow survey). Although it would probably be good to at least reference other popular / useful ones for exploratory purposes, for a quick overview course I think focusing on vim makes ample sense.
I don't think they really advocate for vim to be your daily driver for all editor needs. Just a "you should know a thing or two about what this is because you're going to be lost the first time git shoves you into a vim editor" sort of thing.
It's also one of the few modal editors out there, and that's a different paradigm students might not have been exposed to. In comparison, Emacs is much more similar to Sublime or VSCode (always insert, functions invoked via shortcuts).
While I understand the value of distinguishing between CS and software engineering, not being comfortable with basic shell commands, installing programming language tools, compiling something using those tools, or source control means that there has been a huge gap between theory and practice in their education, which hurts understanding of both.
Particularly when interacting with senior CS students, they'll spend 6 months just getting comfortable doing very basic things like installing and running Python, using ssh with a VM, and using the command line. They try to do productive work, but their unfamiliarity with the basic tools of making software means they actually spend their time learning that.
Actually, this also applies to the basics of just writing a functioning library or piece of software, or being familiar with async vs. sync programming, etc etc. It would be better if they could dip their toes into these things while learning about, say, algorithms, because identifying the slow step in its execution context and designing a better algorithm requires knowing this stuff. Or even better, before doing any of that. I've met people with 6+ years of CS or CS-related educational background who don't know how to do basic problem solving / troubleshooting of their work because they've only done toy coding for coursework.
The answer is basically "sure, but we explain what we mean in the lecture."
It's not sexy. A lot of it isn't "computer science." But until you get this stuff down you won't be doing day-to-day development very well.
This is the main issue in my view. CS isn't development. CS is research, development is application. I'm a software engineer and I would never call what I do CS. Things are going to be clunky and awkward until schools split CS from Software Engineering, like they do with other sciences and their applications.
The only thing which stuck with me was the Therac-25 story. Everything else was just pretty much "don't deliberately use your powers for evil" type thing.
It's easy to talk about professional ethics and choosing good over income on an internet forum when the impact it has on someone else's life has no impact on yours. If I left a FAANG to work for peanuts at some volunteer agency, I suspect you wouldn't be there to chip in when my loved one needs support and suddenly my ethics can't foot the bill like my old salary could. You have no idea the impact a FAANG salary would have on my life and my loved ones', so it's not very thoughtful to suggest that somebody who has to prioritize financial gain is unable to see good other than financial gain.
my favorite software ethics framework so far is https://ethicalos.org/
Similar concept, but targeted towards non CS majors
I saw a lesson on R, for example, which is probably not too useful for a webdev or mobile app developer.
Imagine you study civil engineering but all your classes are taught by physicists and mathematicians, and you are studying physics. Yes, this is all important foundational knowledge for engineering, and you can't be a good engineer if you don't know any physics. But engineering is not physics and to graduate civil engineers without actually teaching them engineering seems like a massive fail. Adding a "missing semester" in which they learn how to use some engineering software is just scratching the surface of what an civil engineering degree should require. That we have gotten away with this in CS-land is just because of the immaturity of the field, not because this is a good way of producing the software engineers that society needs.
So graduates are expected to show proficiency in a minimum of 5 different programming languages? That sounds like an enormous waste of time.
Do you think there are tradeoffs worth considering between language paradigms? Is there a reason why you might want to write something close to the metal, vs something in a scripting language? Is there a reason you might want FP over OO for certain problems?
I mean...my curriculum didn't explicitly call out languages anywhere, but along the way I picked up Python (intro class), Java (most classes), C and an x86 assembly (embedded class), C++ (graphics class)...and within two years of graduating I was wanting to learn a functional programming language, and changed jobs just to do it. Had I gone AI track I would have picked up a Lisp. It's not really that big an ask.
Learning x86 assembly for the sake of it isn't useful or educational. However, building an x86 compiler (or in my case JVM compiler) as part of a languages and compilers course is something worth doing.
Every developer should learn to work with an SCM tool.
Yes, Vim and git are specific choices, but they are reasonable, extremely popular defaults. The first will work basically everywhere, the latter at least gets you the concepts necessary to quickly learn and use something else if needed (while being the most popular of its kind)
This isn't something you do in CS ever. If you want to learn a technical skill like system administration or git, great. It isn't CS though.
I don’t have to regularly look up how to bold text even in Markdown, but I do have to regularly look up various Bash-isms.
It's like an English major who can read and analyze the classics and nothing else - and cannot write at all outside of abstract poetry.
The only thing that seems missing is document preparation - presumably using LaTeX (we had to use troff, which was 'fun').