[Elv13]

Back in 2007, my first semester in a technical CS school had plenty of assembly, binary, MMU emulation, OSI / TCP/IP, boolean math and so on.

I know this is mostly gone at this point, but it should not. The fundamentals are essentials. I often meet people who are totally clueless how a computer work and have CS degrees.

"How can you do C, it is so old? By now, we must have invented faster languages. Computers changed so much recently". Sure... Binary is now expressed with emoji.

[cbd1984]

Those aren't the fundamentals of CS. The fundamentals of CS are data structures and algorithms, as the Good Book says. Hardware is important, practically, but don't let practicality blind you to the actual core of the field: Practicality has a way of becoming obsolete, and an actual education is for life.

[toyg]

Meh. It's like saying that the fundamentals of film-making are writing and acting -- except writers and actors are nothing without an actual camera, and if you don't know how to place the camera and how to cut film produced by such camera, you will never get a film done. Cameras change, but you will never have a camera that miraculously materializes in all the right places to take exactly the shots you imagined. In the same way, some things will never change on the hardware side: you will always have inputs, outputs, memory, storage, human interfaces, power management, booting and so on.

[cbd1984]

The difference is that when people talk about hardware, they're talking about the equivalent of film, not abstract "this is central to being a camera which works with visible-spectrum light" concepts.

> you will always have [...]

> memory, storage

First, making a distinction between memory and storage is not an "at all times, in all places" kind of thing. It's more "this is what we do now, in the past, on some systems, it was different, and it may be different in the future" kind of thing. Single-level storage is not currently popular, but it was in the past and may yet come back. It already has, in some limited contexts.

Second, we've already seen home system storage go from paper tape to magnetic tape to magnetic disk to metallic magnetic disk to solid-state NAND Flash or close equivalent. Each has vastly different performance characteristics and details in every detail.

> human interfaces

I'm sure there are some iron-clad universals in HID. I don't know which of those translate from CLIs to touch-screens to gestural interfaces to speech recognition to pupil tracking to...

> power management, booting

Two things which have changed quite a bit even in the lifetime of "vaguely IBM PC-derived" desktop computers, and even moreso if you widen your scope up and down the power curve to include handheld systems and, you know, Real Computers What Do Real Work.

[toyg]

> we've already seen home system storage go from [...]

Yes, but the point is that there will always be a requirement to manage and persist the data you are working on somehow, and how you go about this somehow dramatically impacts (or should impact) the choices you make at the more abstract level of data structures. It is a fundamental concept that you will be forced to consider in one way or the other. You can have the fastest algo in the world crunching huge amounts of data, but if you then take an inordinate amount of time to store and retrieve results, it's as bad as having blazing-fast storage and crappy algos.

> I'm sure there are some iron-clad universals in HID

I agree that is traditionally considered a subclass of I/O, but I think in recent years we have seen that it's much more important than previously understood. Good software with mediocre UI is ignored while mediocre software with good UI can change the world. This is one of the few real discoveries in our field since the '80s.

>> power management, booting

> Two things which have changed quite a bit

... but are still there in some shape or form, and will forever be there. They are changing the world because people put effort and thought into them as fundamental parts of computing experiences, not one-offs that can be simply ignored as "constant time".

[derefr]

Those would also be the fundamentals of theatre, though, and film as a medium is essentially defined by its divergence from theatre. The fundamentals of film are cinematography and editing, but even this is theoretical compared to the craft of film-making. Just as CS includes the behaviors of Von Neumann machines with tapes, which is abstract compared to the science of e.g. processor die doping.

[taneq]

Wow. My first semester of computer science had me studying fuckin' Gofer.

[Elv13]

It was a technical school with very practical teachers. The lack of "theorists" probably helped a lot. Most of them were either from the video game industry or 80's embedded developers. In Quebec (Canada), a technical school teacher unlikely is to have a PhD. Technical schools and universities are 2 different "level". You can take technical school (CEGEP) as a pre-university degree (or you can end there and get the equivalent of an associate degree). When taking a CS one instead of science, you "lose" 1 year, but it is much more fun. Too bad they replaced the system programming courses with web ones a couple of years ago.

All that to say that sometime, having real industry veterans as teachers really influence the teaching point of view.

[unwind]

As in https://en.wikipedia.org/wiki/Gopher_%28protocol%29, right, the precursor to HTTP?

[taneq]

Nope, as in https://en.wikipedia.org/wiki/Gofer_%28programming_language%..., the neutered Haskell clone.

Don't get me wrong, I certainly think that functional programming has its place in the world, but as a first year uni student all fired up about finally learning "real" programming after years of teaching myself (back before the internet laid everything out on a platter), I was not impressed.

[toyg]

Eh, same with me and Scheme.

I don't think functional paradigms can really be appreciated by 1st/2nd year undergrads. At that age you are fundamentally impatient to make your mark in a practical sense, your approach will be instinctively imperative. You have to hit the wall (scaling / parallelism / thread management / complexity etc) before you start to really appreciate the upsides of functional paradigms.

Unfortunately, a lot of professors are actually terrible educators (after all, they did not get there by teaching but by researching) and think the learning process is as linear as house-building: "place bricks here and there so that your next row will be this way and that way". They also think people should enjoy programming for programming's sake, whereas a lot of people are motivated by a creative process driven by outcomes.

[Symbiote]

> your approach will be instinctively imperative

Not necessarily (based on being an assistant in lab sessions for first year students learning Haskell).

But what it did do was put everyone on the same level, including the arrogant students who "already knew how to code" and hadn't listened (or attended) the lectures.

I think they chose a functional language to start with good habits for thinking about what to implement, not how to implement it. If you don't know what the problem is, you should work on that, rather than bashing out some Java...