Learn C, Then Learn Computer Science

I disagree. There is a rich theory of cryptography that is entirely abstract, for which the low-level details are an irrelevant distraction. Even the AES finalists, which were designed with low-level concerns in mind, are described abstractly and can be implemented at a high level (I have an implementation of Serpent in Common Lisp, for example -- no messing around with low-level details, just a functionally correct block cipher). Within the crypto research community there are people who work on high-level languages suitable for cryptography implementation:

http://www.charm-crypto.com/Main.html

To be fair, there is also an enormous body of work on implementing cryptosystems in the real world -- at least enough to have an entire course dedicated to the topic. If anything, we should really have two courses: an introductory course that covers the theory of cryptography, and a cryptography engineering course that deals with real-world implementations.

For limited ranges of valid. If you are implementing a low performance requirement CRUD app, certainly you can become an effective programmer without knowing the low level details.

But if you want to be an engineer? Good luck. I've worked with people that didn't know the stuff behind C, and they are pretty useless as soon as performance matters, or you need to talk to hardware, or crank through a lot of numerical computations, minimize watt usage of a cellphone, app, debug complicated situations, and so on. They don't have a good mental model of the machine in their mind, and so they cannot figure out what is going on, reason about the performance of a modern chip, and so on.

There are a lot of arguments for expediency on HN. Probably it is partially justified, but I will always advocate for an engineering education, as opposed to a 'learn rails in 3 weeks and get a job' approach. Education and knowledge enables you to tackle any problem that comes your way.

So, while you can learn to be an effective debugger of a Python script (say) and so on without detailed knowledge of the machine, mastering the fundamentals will make you an effective debugger and enable you to do so much more. To stick with the python, what happens if the python implementation is buggy? There is a large subset of programmers that can not cope with that situation.

Why limit yourself? If this is going to be your career, the way you pay your mortgage, feed your kids, and so on, invest in yourself. I'm having trouble of thinking of the downside of acquiring the knowledge, but I can trivially think of the upside.

Abstract vs. Concrete Data Types are introduced very early as representations for the theoretical structures discussed in class and then we are given projects that can be solved using concepts and theorems introduced with the expectation that we will implement the appropriate structures and algorithms in C. The code itself is read over carefully and just as important as whether the output is good. Now, this is partially a luxury afforded by my university's small size; freshman and sophomore CS classes aren't taught in 200 person lecture halls, they're 30-40 students at the max. My first exposure to a linked list was writing one in C, not using one in Lisp. You model them, write proofs, recurrence relations, graphs, etc. on exams, and implement them in projects so that you show an aptitude for both the theory and the mechanics.

By the time you hit your fourth year, you take Programming Languages and Theory of Computation. Automata/Machines, Grammars, BNF, Compilers, etc. in lecture; seeing these concepts applied by studying and writing code in OO languages, LISPs, and Prologs in lab. And you'd sure as hell better understand how the garbage collector in your favorite high level language works or you'll get hosed on the exam. There's other staples mixed in of course; a whole semester devoted to Java/OO (I think a whole semester devoted to functional programming and Lisp would be better, but that's another story). A semester of OS, a semester of Networking. But just focusing on the whole programming/vs science side of it, there's no reason they can't both be taught effectively.

Classes at the time were a mix of C, Pascal, and Lisp (at my school, YMMV). Certainly all the chances for getting pointers wrong made developing in C harder, at first. Even today I prefer to reach to Python to throw together some algorithm I am musing about. So I definitely acknowledge your point.

But, I just don't see a way around it. Today I am refactoring code to make it stay in the cache better. Doing that is not an exercise in pointless efficiency; it is the difference between the program being usable or not (it is a real time system). I contemplated compiling to assembly and eyeballing it, but a few sessions with the profiler got me the answers I needed. But to do this I had to keep in mind the pipeline architecture (cost of if statements if you don't get the branch prediction), the size of the cache, the cost of function calls, etc.

I recognize there are careers out there where you never have to touch that stuff. You write SQL calls and use a 4GL language, and so on. But what happens when your SQL runs to slow? Do you randomly vary the various server settings until it seems to run better, or do you actually understand (say) the cost/benefit of making the cache for the indexes larger? How would you talk to a piece of hardware your boss drops in your office? How..., well, you get the idea.

None of that is advocating building an entire 4 year curriculum solely on C/C++. Certainly it makes sense to do the algorithms class largely in a language like Lisp or Python. But after a certain point if you want real performance you are in C, battling low level details, and I think that is as important, if not more important, than proving the O() complexity of Fibonacci heaps.