Hacker News new | ask | show | jobs
by henrikschroder 2361 days ago
When I did my CS programme decades ago, we all started with Scheme, which is very high-level, and forced everyone to focus on the algorithms, the math of it, instead of what the hardware is doing, or how the Scheme interpreter is implemented. It gets you going, thinking about values and execution and iteration and recursion.

Starting with bits and bytes and hardware would be pretty goddamn boring, I think. You'd lose a lot of students that way.

That said, in the third year we had a course in analog electronics, which was basically transistors and logic gates.

Following that course was one in digital electronics, where we all built our own little toy 8-bit computer, wiring the CPU ourselves, writing the microcode ourselves. I'll never forget the a-ha moment when you realize that your instruction set are just binary patterns representing which wires to put a current on, which units to toggle on and off. The instruction to move a value from a register to an address in RAM has to look like this, because you need to toggle the read input on the correct register, and the write input on the RAM unit, and everything else has to be off. Blew my mind at the time.

The clock was manual if you wanted to, so you could step through and watch your little CPU run a program, or you could set it to like 1Hz and watch the thing go. And from there, you can sort of get how a modern computer works, it's just a matter of going from 1Hz to 1GHz, wider buses, wider instruction sets, but it's no longer "magic" how the CPU works, it's all ones and zeroes, for a reason, and you now know that reason.

3 comments

I think it depends on the audience.

For a group of prospective CS majors, or people learning programming for its own sake, I think it would be good to start with a high level language, say Python, Scheme or Ocaml, and then progressively deconstruct the layers of abstraction between the language and the physics.

For a group of electrical engineering majors, it might actually tie in better with their other courses if one starts with simple physical constructs like bits, bytes, and gates, and gradually introduce abstraction layers to form more convenient programming models.

That’s basically how they taught my computer architecture course, but they started from C (instead of Python) and worked back to assembly and then to transistors or whatever those gate things are (I studied enough to make an A and don’t care anymore unless someone pays me to).

I think it must be a reasonably normal approach.

It's interesting as I studied Computer Engineering which focused on the hardware and low level, with some programming on top of that. I was pretty good at that too. However afterwards the Google-style interview algorithm questions do not come naturally for me, and you'd think I'm a complete imposter by the look in some 20-something interviewers eyes, even though have been programming for 20 years...
I feel exactly the same way: Computer Systems Engineering. Took to programming easily, as well as digital. (Not as good in analogue though). Was teaching my tutors programming by the end of first year. Getting asked to hack/ deconstruct software in 2nd.

Would fail miserably in these Google style tests.

I think the difference is that our brains are wired to solve issues from first principles. Some of the best CS I've come across use pattern recognition to determine the best algo to apply to a situation.

The end result is the same code, but we speak different languages until we arrive at the same end. Other design methodologies help give us a better framework for cross communication.

Eg. Voronoi diagrams. Absolutely fantastic way of doing mesh reduction. Took a CS guy to point it out to me ... (I was mostly thru designing my own).

Eg. Same CS would never consider using ASM to save clock cycles.

Scheme is deadly boring. You'd lose a lot of students that way. Starting with bits and bytes and hardware would be pretty goddamn fun, I think.

I first really got into things with assembly language for DOS. It was interesting to directly control the IRQ controller, real-time clock, interval timer, and keyboard interface. These were all motherboard chips that could be messed with.

Years later I passed a mandatory Scheme class. I tolerated it to get my degree, but I was furious. I handed in just enough assignments to pass the class. If the degree had started with Scheme or required very much of it, I would have found something less miserable to do with my life.

Another positive aspect of starting off with Scheme was that it leveled the class out, it removed the edge that all the self-taught programmers thought they would have over the people who hadn't really done much programming. Everyone was pretty much equally clueless. Very refreshing.
You make an interesting (unsupported) assertion here. You, who find talking to an IRQ controller, real-time clock, etc. interesting, find Scheme boring, therefore others (who may not share your interests in such details) will also find it boring. Bit of a logical fallacy there...
I've run a lot of surveys of introductory students trying to find what topics are more or less interesting to them. A part of my dissertation was committed to it, actually.

At this point, I'm more or less certain you'll rarely find situations where you have a mass-appealing context. One students' dream context is another students Most Boring Possible. You're probably better off having many diverse contexts and hit all the MUSIC guidelines (eMpower students, Useful to their long/short term goals, make students Successful, make it situationally and domain-based Interesting, and give people opportunities to demonstrate that they Care about each other).

Agreed.

I recall, in high school, we were writing a disassembler for a custom weird assembly language which was written by one of the school's graduates a few years prior to that... and we had to use this assembler as a language of choice :) That's high school! And it was quite fun. These days, many CS grads/post-grads know tensorflow and other flashy high level stuff while having very vague understanding of how things actually work at the lowest level (source: interviews).