Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Missing Semester of Your CS Education (2020)

missing.csail.mit.edu

Post reply on HN
Print view View original

221–230 of 347 posts

Re: The Missing Semester of Your CS Education (2020)

#221

Post by ModernMech »

readingnews wrote: post #170

I have tried in vain to get this implemented at our uni. I can say a few things I find interesting: - Students used to get this stuff but no longer do, for example all workstations used to be unix, so when you left, you "knew" "unix" (shell, vim, etc) - Due to things like ABET, classes are crammed with need-to-know-for-accreditation info so, well, some items need to go by the wayside (many are in the MIT list) - Ther…

We're trying to implement exactly this. I assign the MIT missing semester materials in my sophomore systems programming course, and we do all of our assignments using a CLI, C, GCC, and Git. Prior to my course, the students know only Java and IDE programming.

One problem we have is that the prereq chain for our courses is very long, so adding another course as a pre-req to all others lengthens that chain.

The MIT course offers probably too much info for our purposes, or at least info students don't need preloaded. Just basic CLI and basic Git clone/fork/pull/push are enough for up to probably Junior year. The problem is that the intro courses are so sanitized that students aren't even getting basic CLI until Sophomore year, which means by the time they graduate, they're behind where they should be imo.

Re: The Missing Semester of Your CS Education (2020)

#222

Post by [deleted] »

eslaught wrote: post #205
lordnacho wrote: post #92

Earlier quoted context omitted.

I have this feeling that the kids who appear better at uni are the ones who happened to pick up certain not-quite-programming skills before they started. Basics of networking, how installation of programs happens, how to use the command line, that kind of thing. I looked over her shoulder as my wife was doing a CS degree, and I realised there's a bunch of these little things that make life a lot easier if you know th…

This doesn't fit my experience. I mean, yes, this was me. I came in knowing most/all of this. I knew six (or more?) programming languages, had at least played with CVS/SVN, had installed Linux (read: fought with the Linux bootloader to get my AMD CPU to boot without crashing), had dipped my toe in a few open source communities. But I was a tutor in college and I interacted with a bunch of people who didn't come in wi…

[deleted]

Re: The Missing Semester of Your CS Education (2020)

#224

Post by wirthjason »

dls2016 wrote: post #209
readingnews wrote: post #170

I have tried in vain to get this implemented at our uni. I can say a few things I find interesting: - Students used to get this stuff but no longer do, for example all workstations used to be unix, so when you left, you "knew" "unix" (shell, vim, etc) - Due to things like ABET, classes are crammed with need-to-know-for-accreditation info so, well, some items need to go by the wayside (many are in the MIT list) - Ther…

Thank you for making the point about accreditation, it's sort of a pet peeve of mine. I taught "intro to C++" last year at the Harrisburg campus of PSU. The students were a mix of non-CS majors who didn't know what a file was, a handful of students who already knew how to program and a bunch in the middle. Re: accreditation... the admin is very reluctant to change anything about the courses. Even specific textbooks h…

C++ needs a “missing semester” around tooling. Most material I see focus on the core language but leave out setting up build systems, package management, clang tidy, testing etc.

Re: The Missing Semester of Your CS Education (2020)

#225

Post by [deleted] »

Niksko wrote: post #107
sokoloff wrote: post #103

Earlier quoted context omitted.

There’s absolutely a responsibility to educate on the topics needed for the degree to be granted. This class is an adjacency to an EE or CS candidate. Are universities also failing their students by not offering/requiring a touch-typing class? I don’t think so, in large part because computer science is not programmer occupational training.

A CS course isn't programmer occupational training in name only. Practically, there aren't many CS research jobs and working as a programmer is more often than not the career path for someone with a CS degree. Universities can choose to be puritans about what CS is as you seem to be advocating for, or they can be realists and fill a very real gap in skills and knowledge. Your point about "the topics needed for the de…

[deleted]

Re: The Missing Semester of Your CS Education (2020)

#226

Post by seadan83 »

whynotminot wrote: post #159
bjourne wrote: post #147

Earlier quoted context omitted.

I had a guitar tutor once and I asked him if I honestly had a chance to get into the Royal College of Music. He said absolutely, no problem, as long as you practice for at least two hours per day. Every day. For the next ten years... High-level CS is the same and I don't see any reason why it should be different. There is just no, or very little, time to teach introductory programming classes at most universities.

Am I unique in not romanticizing computer science? I see it more as a trade. There can certainly be some beauty to it. I’m sure coal miners hold some of their own in special regard too.

There is beauty in just about any trade that is well done. To the extent this is romanticized is up to you. I'm not a big fan of the professionals that feel it is 100% trade. On the flip side, the 100% romantics are not ideal either IMHO - too focused on technology for technology sake.

Re: The Missing Semester of Your CS Education (2020)

#227

Post by sethammons »

ClumsyPilot wrote: post #161
RomanPushkin wrote: post #157

Vim? Really? No text editor will make you a good programmer. I barely use/know Vim with 20 years of programming experience.

The first thing I do on any linux box is remove Vim for nano Vim is like Dvozak keyboard. Consistency and standardisation is more important than 1% performance improvement.

Wait - you actively remove vim? Or you alias nano to vim? Neither of those make sense to me. Why not leave it there and just not use it?

Every system I've ever been on has vi and nano and usually vim.

Re: The Missing Semester of Your CS Education (2020)

#228

Post by lizknope »

I posted already in the thread but when I started college in 1993 we had a mandatory intro to computing environment class. At the time everything on campus was Unix based with a mix of Sun, DEC, HP, and IBM workstations.

The class is still called E115 and I found the online text book. It has definitely changed in the last 30 years and the MIT course is probably a lot more in depth but the concept is the same.

You have students coming from high school that may have only used Windows or Macs. I've heard that a lot of students have got used to iPads and cloud storage don't even understand the concepts of files or file systems.

https://e115.engr.ncsu.edu/online-textbook/

Re: The Missing Semester of Your CS Education (2020)

#229

Post by a_e_k »

ModernMech wrote: post #141
fsociety wrote: post #118

Earlier quoted context omitted.

I agree you should know how to use a debugger, however will also note that some companies mandate use of a specific IDE (or heavily encourage). I have seen devs scoff at the thought of print debugging, but I recall that in systems programming there are many times you can’t use a debugger or need to rely on other tool. I’d rather schools teach the concept of step debugging vs runtime debugging. Teach students to try t…

> I have seen devs scoff at the thought of print debugging Next time they do, ask them to recommend a better method of debugging that works across generally all languages, compilers, IDEs, and platforms with next to zero configuration.

The key thing about print debugging for me, that I've never seen a typical debugger handle well, is what I like to think of as "temporal debugging":

Taking a program trace from the print debug statements, grepping through it repeatedly to filter down to certain events of interest, looking at the interleaving of those events, and figuring out the order that things happened in to cause it to go off the rails. That sort of thing. (To be fair, time-travel debuggers can start to get at this, but those are pretty uncommon. Traces, as you say, work almost everywhere.)

Or better yet, compare the traces between working and non-working runs to see how they differ. I've looked at diffs of traces this way before. (Sometimes I'll first use a small script to renumber pointers in traces by order of appearance.)

I've also used this sort of strategy before for debugging rare threading or other non-deterministic issues. Have the shell run the program in a loop, saving each run's trace and results to a different file, go off and get lunch, come back and see if anything failed. Then look to see if any of the runs failed and look for the structural differences between the working and non-working traces.

I can't imagine sitting and stepping through in a debugger 100+ times in the hopes that maybe this time, it will be the run that's just different enough to trigger the bug and that the debugger itself won't prevent the issue from manifesting. Not to mention, trying to remember the steps from all the good runs and spotting where the bad run goes bad before you've stepped to far. No thank you.

I think people really underestimate print debugging. Debuggers are fast and easy for simple bugs, sure, but there's powerful stuff that you can only really do with printed traces.

Post reply on HN