Computer Science Courses that Don't Exist, But Should

In my opinion this is a thought terminating cliche in programming and the IT industry in general. It can be, and is, said in response to any sentiment about any thing.

Sure, I agree it can be. But it doesn’t make it less true that “it depends” is often the answer. As I see it, my job is often to think “what applies in this case”. Including thinking about things like: 

• what matches the mental model the company has about this
• what’s the shape of the problem
• what type of abstractions do we already use
• what aspect do I want to make available, how is this expected to change?
• etc

Now, saying what sort of context you think something should or should not be used in, and what qualities of that thing make it desirable/undesirable in that context, could lead to fruitful discussion. But just "use the right tool for the right job" doesn't contribute anything.

Sure. I lean towards object oriented design when things represent a simple well known object with a stable set of “nouns and verbs” that are unlikely to change. In my case this tends to be around UI elements or the data layer very basic things, where I don’t care too much about “data transformation”, but want to encapsulate an action (eg. I think being toggleable is intrinsic to a switch, so switch.toggle feels like a stable api and I can design an object like this that others can understand without having to care about the internals)

Some design patterns that come from the oop tradition (not exclusive to oop, but very much part of the toolkit) that I find exceptionally useful. For example, the strategy pattern is something I’ve used often when building things like data exporter and importer tools. I can structure my logic in this way, move all the specific logic to the leaves. 

I can’t be exhaustive, but for me oop is all about encapsulation, and so I use it when it calls for that. I think it also makes APIs easy to test.

——

Functional programming I absolutely love. Whenever I’m transforming data, i think in functional terms. Composable functions, immutable data. It’s just a lot easier, and for me it makes it easier to test processes and operations. I tend to lean to this this in a business logic layer. If I can describe operations in a way that we talk about them in the company, and make those units of transformation testable, then bigger processes become safer and auditable. 

Another thing from functional programming languages that I love is things like algebraic data types. It just pains me to use a language without sum types now. 

——

A while back I used “aspect oriented programming”. That didn’t catch on, but moving some things like logging, event tracking, etc. to aspects makes sense to me. If a language supports function annotations, I /will/ try to move those sorts of aspects to a function annotation.

——

I spent a while doing prolog, and that language is just something else. I wish I had an easy to embed prolog that I could use for constraints on data. This one I don’t “get to mix and match” because multi purpose languages don’t include aspects of it. But thinking in terms of reversing operations (eg. Given this result, what set of constraints produce it) is still a tool that helps me understand how to shape a problem. 

——

There’s a lot of nuance to this, more than can fit in a comment, and definitely nuance that doesn’t apply to imaginary problems or problems/sotuations that we don’t share. Also, you and others will probably think about it differently. to me that’s kind of the point, both thinking in terms of a diverse toolkit, and having a team with diversity of thought.

I would humbly suggest FP may seem especially natural to you precisely because that's what you use all day.

An object is a poor man's closure.

A closure is a poor man's object.

These are two sides of the same coin, and both of them miss the point. You should be dealing with scale, and you should use a language that allows you to concisely describe how to compute large amounts of data easily. The best part is that once you start writing APL, you'll feel like a wizard.

FP & OOP both have their use cases. Generally, I think people use OOP for stateful programming, and FP for stateless programming. Of course, OOP is excessive in a lot of cases, and so is FP.

OOP is more useful as an abstraction than a programming paradigm. Real, human, non-computer programming is object-oriented, and so people find it a natural way of organizing things. It makes more sense to say "for each dog, dog, dog.bark()" instead of "map( bark, dogs)".

A good use case for OOP is machine learning. Despite the industry's best effort to use functional programming for it, Object oriented just makes more sense. You want a set of parameters, unique to each function applied to the input. This allows you to use each function without referencing the parameters every single time. You can write "function(input)" instead of "function(input, parameters)". Then, if you are using a clever library, it will use pointers to the parameters within the functions to update during the optimization step. It hides how the parameters influence the result, but machine learning is a black box anyway.

In my limited use of FP, I've found it useful for manipulating basic data structures in bulk. If I need to normalize a large number of arrays, it's easy to go "map(normalize, arrays)" and call it a day. The FP specific functions such as scan and reduce are incredibly useful since OOP typically requires you to set up a loop and manually keep track of the intermediate results. I will admit though, that my only real use of FP is python list comprehension and APL, so take whatever I say about FP with a grain of salt.

Why? I find it quite useful.

Have you ever seen a real-world project that actually uses OOP in any significant capacity? I haven't.

When using Java, you might write "class" on top of your structs and modules, but actual OOP with self-contained classes that contain both data and business logic using inheritance and all the other OOP concepts, that's incredibly rare.