Live data from Hacker News

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

prog21.dadgum.com

101–110 of 308 posts

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

#101

The TFA wants the following computer science courses: Unlearning Object-Oriented Programming: a course on specific software engineering techniques Classical Software Studies: a course on the history of software tools Writing Fast Code in Slow Languages: a course on specific engineering techniques User Experience of Command Line Tools: an engineering design course Obsessions of the Programmer Mind: course about engine…

People don’t get this up in arms when there is a math course about using math tools or math history or how math is used to solve actual problems, but for some reason they do about computer science.

They just label such people as Applied Mathematicians, or worse: Physicists and Engineers; and then get back to sensible business such as algebraic geometry, complex analysis and group theory.

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

#102

Earlier quoted context omitted.

You first sentences already suggest one comparison between the histories of computing and philosophy: history of computing ought to be much easier. Most of it is still in living memory. Yet somehow, the philosophy people manage it while we computing people rarely bother.

I always think it is great value to have a whole range of history of X courses. I once thought about a series of PHYS classes that focus on historical ideas and experiments. Students are supposed to replicate the experiments. They have to read book chapters and papers.

History of physics is another history where we have been extremely dependent on the "substrate". Better instruments and capacity to analyze results, obviously, but also advances in mathematics.

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

#103
Unlearning object oriented programming

I think OOP became popular because it feels profound when you first grasp it. There is that euphoric moment when all the abstractions suddenly interlock, when inheritance, polymorphism, and encapsulation seem to dance together in perfect logic. It feels like you have entered a secret order of thinkers who understand something hidden. Each design pattern becomes a small enlightenment, a moment of realization that the system is clever in ways that ordinary code is not.

But if you step back far enough, the brilliance starts to look like ornament. Many of these patterns exist only to patch over the cracks in the paradigm itself. OOP is not a natural way of thinking, but a habit of thinking that bends reality into classes and hierarchies whether or not they belong there. It is not that OOP is wrong, but that it makes you mistake complexity for depth.

Then you encounter functional programming, and the same transformation begins again. It feels mind expanding at first, with the purity of immutable data, the beauty of composability, and the comfort of mathematical certainty. You trade one set of rituals for another: monads instead of patterns, recursion instead of loops, composition instead of inheritance. You feel that familiar rush of clarity, the sense that you have seen through the surface and reached the essence.

But this time the shift cuts deeper. The difference between the two paradigms is not just structural but philosophical. OOP organizes the world by binding behavior to state. A method belongs to an object, and that object carries with it an evolving identity. Once a method mutates state, it becomes tied to that state and to everything else that mutates it. The entire program becomes a web of hidden dependencies where touching one corner ripples through the whole. Over time you code yourself into a wall. Refactoring stops being a creative act and turns into damage control.

Functional programming severs that chain. It refuses to bind behavior to mutable state. Statelessness is its quiet revolution. It means that a function’s meaning depends only on its inputs and outputs. Nothing else. Such a function is predictable, transparent, and portable. It can be lifted out of one context and placed into another without consequence. The function becomes the fundamental atom of computation, the smallest truly modular unit in existence.

That changes everything. In functional programming, you stop thinking in terms of objects with responsibilities and start thinking in terms of transformations that can be freely composed. The program stops feeling like a fortress of interlocking rooms and begins to feel like a box of Lego bricks. Each function is a block, self-contained, perfectly shaped, designed to fit with others in infinitely many ways. You do not construct monoliths; you compose arrangements. When you need to change something, you do not tear down the wall. You simply reassemble the bricks into new forms.

This is the heart of functional nirvana: the dream of a codebase that can be reorganized endlessly without decay. Where every part is both independent and harmonious, where change feels like play instead of repair. Most programmers spend their careers trying to reach that state, that perfect organization where everything fits together, but OOP leads them into walls that cannot move. Functional programming leads them into open space, where everything can move.

Reality will always be mutable, but the beauty of functional programming is that it isolates that mutability at the edges. The pure core remains untouched, composed of functions that never lie and never change. Inside that core, every function is both a truth and a tool, as interchangeable as Lego bricks and as stable as mathematics.

So when we ask which paradigm handles complexity better, the answer becomes clear. OOP hides complexity behind walls. Functional programming dissolves it into parts so small and transparent that complexity itself becomes optional. The goal is not purity for its own sake, but freedom; the freedom to recompose, reorganize, and rethink without fear of collapse. That is the real enlightenment: when your code stops feeling like a structure you maintain and starts feeling like a universe you can endlessly reshape.

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

#104
post #11

"CSCI 4020: Writing Fast Code in Slow Languages" does exist, at least in the book form. Teach algorithmic complexity theory in slowest possible language like VB or Ruby. Then demonstrate how O(N) in Ruby trumps O(N^2) in C++.

We had this as a lab in a learning systems course. converting python loops into numpy vector manipulation (map reduce), and then into tensorflow operations, and measuring the speed.

Gave a good idea of how python is even remotely useful for AI.

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

#105

> 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…

> The effective history of computing spans a lifetime or three.

That argument actually strengthens the original point: Even though it's been that short, youngsters often still don't have a clue.

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

#107
> It's about being able to implement your ideas.

No, it's about creating something which does something useful and is easy to maintain. Plumbers have great ideas and approaches but you just want plumbing which works and can be fixed .

It's time developers realised they are plumbers not **** artists.

[HN reduced my expletive to just four asterisks which seems a bit reductionist]

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

#108

> It's about being able to implement your ideas. No, it's about creating something which does something useful and is easy to maintain. Plumbers have great ideas and approaches but you just want plumbing which works and can be fixed . It's time developers realised they are plumbers not **** artists. [HN reduced my expletive to just four asterisks which seems a bit reductionist]

> It's time developers realised they are plumbers not artists.

If we're plumbers, why all the memory leaks?

Or... are we also bad plumbers?

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

#110
I could add so much to this page.

- COBOL on punch cards

- RPG II/III

- PDP/Vax Shared Memory Modules

- Hierarchical Data File Storage

- Recursive Expression Evaluator

- Batch Processing large datasets

- Compressed dates and numbers

So many of these teach you structural complexity that you’d never learn in today’s world.

Post reply on HN