Live data from Hacker News

The Missing Semester of Your CS Education (2020)

missing.csail.mit.edu

81–90 of 347 posts

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

#81

It's amazing how many CS programs fail to teach you even the basic tools of being a software developer. Yes, yes, CS is not programming, but there is a non-trivial amount of CS that is indeed programming, and that is generally what people do with their CS degrees, so it'd make sense for a CS program to teach the basics. Maybe even more than the basics.

I think this is mostly a US thing, or countries based on similar education systems.

In Portugal our computing degrees are Informatics Engineering to use a literal translation, a mix of CS stuff and Engineering. And validated by the Engineering Order as fulfilling certain requirements, for anyone that at end of the degree also wants to do the admission exam for the professional title.

Those that only care about the theory part of CS take a mathematics degree with major in computing.

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

#82

I was blessed with a badass AIX teacher. Thank you Coleman University for allowing hackers and AIX in your facility!

Is there anything about AIX that differentiates it or makes it exceptional over other UNIXes? Not saying you're insinuating that. Just curious about AIX.

Yes, in many ways it is closer to Windows and IBM mainframe/micros semantics, even though it looks like UNIX on the surface.

For example, it uses COFF (although it also does ELF), the shared libraries also use export files, are private by default, and allow lazy loading on demand when symbols are touched for the first time, just like on Windows.

The TUI tooling to manage the OS is similar to what the other IBM platforms use.

Not much I can remember, the last time I used Aix was in 2002.

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

#83
post #2

The content taught here is the highest payout thing you can learn, in my opinion. Certainly more important than actually writing code or learning algos. What this content covers should unlock iteration speed, which is the single greatest lever in learning and growing faster (on a computer). Thus it gives you more cycles to go back to improving your code, experimenting with algos, etc. Probably also highly correlated…

I sat with a talented developer whilst we wrestled with a threading issue this past week. I wanted to inspect the value of a variable within a method during execution and asked him to set a breakpoint. He didn't know how to do that in the IDE, which he'd been using for over a year. Debugging is indeed a skill which needs learning.

How would a breakpoint help with debugging a concurrency issue?

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

#84

Earlier quoted context omitted.

> I never bothered learning how to use the debuggers for those languages. I don't miss them. This could be causal.

You'd have to assume that the python and go debuggers do something that C debuggers don't do.

Or assume that python debuggers aren't as nice to use, or that python does not lend itself to inspecting weird memory and pointer dereferences, or a bunch of other possibilities.

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

#85

Earlier quoted context omitted.

A talented developer who doesn't know how to set a breakpoint sounds contradictory to me.

Hi! I'm that person! Senior engineer, decade of experience. I've used debuggers in the past, both for running code and looking at core dumps, but I really don't find them to be cost effective for the vast majority of problems. Just write a print statement! So when I switched from C to python and go a couple jobs ago, I never bothered learning how to use the debuggers for those languages. I don't miss them.

I think there's a sort of horseshoe effect where both beginners and some experienced programmers tend to use print statements a lot, only differently.

When you're extremely "fluent" in programming code and good at mentally modelling code state, understanding exactly what the code does by looking at it, stepping through it doesn't typically add all that much.

While I do use a debugger sometimes, I'll more often form a hypothesis by just looking at the code, and test it with a print statement. Using a debugger is much too slow.

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

#86

Earlier quoted context omitted.

I sat with a talented developer whilst we wrestled with a threading issue this past week. I wanted to inspect the value of a variable within a method during execution and asked him to set a breakpoint. He didn't know how to do that in the IDE, which he'd been using for over a year. Debugging is indeed a skill which needs learning.

A talented developer who doesn't know how to set a breakpoint sounds contradictory to me.

I didn't use debuggers since switched from C to Rust. By the way I switched from emacs to VSCode and I do not know how to debug here. I never used debugger with lisp. Debugging is a language dependent technique.

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

#87

Earlier quoted context omitted.

I sat with a talented developer whilst we wrestled with a threading issue this past week. I wanted to inspect the value of a variable within a method during execution and asked him to set a breakpoint. He didn't know how to do that in the IDE, which he'd been using for over a year. Debugging is indeed a skill which needs learning.

A talented developer who doesn't know how to set a breakpoint sounds contradictory to me.

There are large categories of software engineering where debuggers are not used that much.

I work on compilers and debuggers are more of an hindrance than help when trying to fix a compiler bug.

I believe there is a similar situation for distributed systems.

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

#88

I love vim, it's great to know how to navigate it, but I have met very few people who use it professionally. I'd love to hear others' experiences, there.

I don't use vim much since nano seems to be on every installation I've seen recently.

But I don't think anyone can avoid learning how to quit vim. We've all been there, you think you know the keys, you don't, now you are trapped.

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

#89
post #36
post #15

Earlier quoted context omitted.

I use (Neo)vim as my daily driver, professionally (for the past 4 years, coming from Goland). I've found every other editor to be too heavy/slow (VScode/Jetbrains), or too noisy (regarding features). Neovim allows me to specify the precise minimum I desire to have a fully functional IDE-like experience (basically treesitter + LSP + DAP + minimal extra plugins). It's super fast, I'm already in my shell, and my memory…

Once I learned how to use vs code productively it really changed my mind. The other day I needed to do a quick base64 encode and vs code had that. Same goes for formatting some json or doing a diff. It's all available in a single tool with no learning curve. Hell it even has git and git blame in there.

I think VS Code is just extremely convenient and can address most peoples needs out of the box. It’s therefore also very beginner friendly. You don’t need to constantly fight the tool or spend hours researching how to configure some trivial feature. That being said VS Code is quite heavy and has an enormous amount of GUI elements. I mean they even have buttons for things like git fetch and pull for heavens sake. They could release a VSC Light that strips most of the GUI out.

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

#90

Earlier quoted context omitted.

A talented developer who doesn't know how to set a breakpoint sounds contradictory to me.

Hi! I'm that person! Senior engineer, decade of experience. I've used debuggers in the past, both for running code and looking at core dumps, but I really don't find them to be cost effective for the vast majority of problems. Just write a print statement! So when I switched from C to python and go a couple jobs ago, I never bothered learning how to use the debuggers for those languages. I don't miss them.

I find I use the stepping debugger less and less as I get more experienced.

Early on it was a godsend. Start program, hit breakpoint, look at values, step a few lines, see values, make conclusions.

Now I rely on print statements. Most of all though, I just don't write code that requires stepping. If it panics it tells me where and looking at it will remind me I forgot some obvious thing. If it gives the wrong answer I place some print statements or asserts to verify assumptions.

Over time I've also created less and less state in my programs. I don't have a zillion variables anymore, intricately dependent on each other. Less spaghetti, more just a bunch of straight tubes or an assembly line.

I think it's possible that over the years I hit problems that couldn't easily be stepped. They got so complicated that even stepping the code didn't help much, it would take ages to really understand. So later programs got simpler, somehow.

Post reply on HN