Live data from Hacker News

Computer science courses that don't exist, but should (2015)

prog21.dadgum.com

91–100 of 308 posts

Re: Computer science courses that don't exist, but should (2015)

#91
post #74
post #28

Earlier quoted context omitted.

Computer scientists should treat history like civil engineering or physics treat their histories. These are subjects that make objective progress. Art or philosophy might or might not make progress. No one can say for sure. They are bad role models.

At least for history of economics, I think it's harder to really grasp modern economic thinking without considering the layers it's built upon, the context ideas were developed within etc...

That's probably true for macro-economics. Alas that's also the part where people disagree about whether it made objective progress.

Micro-economics is much more approachable with experiments etc.

Btw, I didn't suggest to completely disregard history. Physics and civil engineering don't completely disregard their histories, either. But they also don't engage in constant navel gazing and re-hashing like a good chunk of the philosophers do.

Re: Computer science courses that don't exist, but should (2015)

#92

CSCI 4810: The Refusal Lab Simulate increasingly unethical product requests and deadlines. The only way to pass is to refuse and justify your refusal with professional standards.

But universities want their graduates to be employable, is the thing.

Re: Computer science courses that don't exist, but should (2015)

#96
post #45

I would add debugging as a course. Maybe they should teach this but how to dive deep into figuring out how to learn the root cause of defects and various tools would have been enormously helpful for me. Perhaps this already exists

Yes please. Even senior engineers apply with their debugging abilities limited to sprinkling print-exit over the code.

Do you have a moment to talk about our saviour, Lord interactive debugging?

Re: Computer science courses that don't exist, but should (2015)

#97

Jesus christ Yes to all of it. Also needed: Systems Engineering 101/201/301/401: How to design a computer system to be reliable Security Engineering 101/201/301/401: How security flaws happen and how to prevent them Conway's Law 101/201: Why the quality of the software you write is less important than your org chart The Real DevOps 101/201/301: Why and how to simultaneously deliver software faster, with higher qualit…

In addition, Team Dynamics 301: A course in Blame Management Handling the traditional “innocent punished, guilty escape/promoted” issue. With explanation of the meme “Success has 100 fathers/mothers while failure is a orphan.

Re: Computer science courses that don't exist, but should (2015)

#98
post #88

CSCI 4810: The Refusal Lab Simulate increasingly unethical product requests and deadlines. The only way to pass is to refuse and justify your refusal with professional standards.

Actually a lot of degrees have a relevant ethics class.

I don't disagree that such classes exist, but I have yet to see an ethics lab specifically with the intention of practicing refusal.

Re: Computer science courses that don't exist, but should (2015)

#99
post #81

CS102 Big Balls of Mud: Data buckets, functions, modules and namespaces CS103 Methodologies: Advanced Hack at it ‘till it Works CS103 History: Fashion, Buzzwords and Reinvention CS104 AI teaches Software Architecture (CS103 prerequisite)

Introduction to PhD study: "How hard can it be, I'm sure I could write that in a week"

Re: Computer science courses that don't exist, but should (2015)

#100

> CSCI 3300: Classical Software Studies Alan Kay, my favorite curmudgeon, spent decades trying to remind us we keep reinventing concepts that were worked out in the late 70s and he’s disappointed we’ve been running in circles ever since. He’s still disappointed because very few programmers are ever introduced to the history of computer science in the way that artists study the history of art or philosophers the histo…

The history of art or philosophy spans millenia. The effective history of computing spans a lifetime or three. There's no sense comparing the two. In the year 2500 it might make sense to be disappointed that people don't compare current computational practices with things done in 2100 or even 1970, but right now, to call what we have "history" does a disservice to the broad meaning of that term. Another issue: art an…

> Computation has overwhelming dependence on the performance of its physical substrate (by various metrics, including but not limited to: cpu speed, memory size, persistent storage size, persistent storage speed, network bandwidth, network scope, display size, display resolution

This was clearly true in 01970, but it's mostly false today.

It's still true today for LLMs and, say, photorealistic VR. But what I'm doing right now is typing ASCII text into an HTML form that I will then submit, adding my comment to a persistent database where you and others can read it later. The main differences between this and a guestbook CGI 30 years ago or maybe even a dialup BBS 40 years ago have very little to do with the performance of the physical substrate. It has more in common with the People's Computer Company's Community Memory 55 years ago (?) using teletypes and an SDS 940 than with LLMs and GPU raytracing.

Sometime around 01990 the crucial limiting factor in computer usefulness went from being the performance of the physical substrate to being the programmer's imagination. This happened earlier for some applications than for others; livestreaming videogames probably requires a computer from 02010 or later, or special-purpose hardware to handle the video data.

Screensavers and demoscene prods used to be attempts to push the limits of what that physical substrate could do. When I saw Future Crew's "Unreal", on a 50MHz(?) 80486, around 01993, I had never seen a computer display anything like that before. I couldn't believe it was even possible XScreensaver contains a museum of screensavers from this period, which displayed things normally beyond the computer's ability. But, in 01998, my office computer was a dual-processor 200MHz Pentium Pro, and it had a screensaver that displayed fullscreen high-resolution clips from a Star Trek movie.

From then on, a computer screen could display literally anything the human eye could see, as long as it was prerendered. The dependence on the physical substrate had been severed. As Zombocom says, the only limit was your imagination. The demoscene retreated into retrocomputing and sizecoding compos, replaced by Shockwave, Flash, and HTML, which freed nontechnical users to materialize their imaginings.

The same thing had happened with still 2-D monochrome graphics in the 01980s; that was the desktop publishing revolution. Before that, you had to learn to program to make graphics on a computer, and the graphics were strongly constrained by the physical substrate. But once the physical substrate was good enough, further improvements didn't open up any new possible expressions. You can print the same things on a LaserWriter from 01985 that you can print on the latest black-and-white laser printer. The dependence on the physical substrate has been severed.

For things you can do with ASCII text without an LLM, the cut happened even earlier. That's why we still format our mail with RFC-822, our equations with TeX, and in some cases our code with Emacs, all of whose original physical substrate was a PDP-10.

Most things people do with computers today, and in particular the most important things, are things fewer people have been doing with computers in nearly the same way for 30 years, when the physical substrate was very different: 300 times slower, 300 times smaller, a much smaller network.

Except, maybe, mass emotional manipulation, doomscrolling, LLMs, mass surveillance, and streaming video.

A different reason to study the history of computing, though, is the sense in which your claim is true.

Perceptrons were investigated in the 01950s and largely abandoned after Minsky & Papert's book, and experienced some revival as "neural networks" in the 80s. In the 90s the US Postal Service deployed them to recognize handwritten addresses on snailmail envelopes. (A friend of mine who worked on the project told me that they discovered by serendipity that decreasing the learning rate over time was critical.) Dr. Dobb's hosted a programming contest for handwriting recognition; one entry used a neural network, but was disqualified for running too slowly, though it did best on the test data they had the patience to run it on. But in the early 21st century connectionist theories of AI were far outside the mainstream; they were only a matter of the history of computation. Although a friend of mine in 02005 or so explained to me how ConvNets worked and that they were the state-of-the-art OCR algorithm at the time.

Then ImageNet changed everything, and now we're writing production code with agentic LLMs.

Many things that people have tried before that didn't work at the time, limited by the physical substrate, might work now.

Post reply on HN