I always find it funny to see calls to “unlearn oop”. It’s a tool, useful in some contexts and not useful in others. At some point industry treated it like a silver bullet, and now people are reacting to it by checks notes treating the hot new paradigm as a silver bullet.
learn oop, learn fp, learn logic programming, learn whatever you want. Also, learn when not to use them.
It’s a tool, useful in some contexts and not useful in others.
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.
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.
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, too, have wished to be able to easily embed prolog, or at least its reduced non-turing-complete version, datalog, into a less declarative language.
Also, I think integration with answer set programming for static code analysis could be useful. This is sort of a mid-way point between test driven development and something like the type level programming in languages such as Haskell or semi-automated theorem proving in languages like Coq.
FP has been around a long time, and yes, it is outright better than OOP. Sorry. I write Haskell professionally, and never have I ever felt like something would be easier done in an OOP language. Quite the opposite.
Unrestricted mutation makes programming really hard, and OOP and mutability go hand-in-hand. If you try to make immutable objects, then you’re just doing FP with worse ergonomics.
I would humbly suggest FP may seem especially natural to you precisely because that’s what you use all day.
I mean, I have an OOP background. I found FP as a result of my dissatisfaction with OOP. In fact, I used to teach OOP languages to new students and saw the same mistakes over and over again, mistakes that are simply not possible in FP. It’s a very similar story for everyone I work with, too. We all had jobs in various OOP languages before we managed to get jobs writing Haskell.
Oh, and I’m currently teaching Haskell to someone at work who has a CS degree and has only done OOP languages (and C), and while it’s different than what he’s used to, he’s still picking it up very quickly (working towards making him a junior engineer, which I think shouldn’t take too much longer). In fact, just the other day we pair programmed on a bug ticket I have and he was not only following along with the code, he spotted issues I hadn’t seen yet. Part of it is certainly that’s he smart (which is why I’m doing this in the first place), but part of it is also that, with a bit of familiarity, FP languages are incredibly easy to read and follow. The primary difference is that FP does everything explicitly, whereas OOP encourages a lot of implicit (and hidden) behavior. When you organize code around functions, there’s necessarily more explicit arguments and explicit return values, which makes it far, far easier to follow the flow of logic of code (and test!). Recently I was trying to read through our Kotlin codebase at work (for our Android app), and it was so much harder because so much is implicit.
Please Grok tell me why was I so invested in this discussion, even if I’m not quite sure what OOP is?
It’d be fun to talk shop with the fast code in slow languages folks. I do that for a living. I remember three ways, but I’m sure there’s more:
- “Just use a better data structure”
- “My language is a DSL for a faster language” (Polars, Numpy, etc)
- “My compiler is surprisingly good if I’m careful” (Julia, JVM, etc)
It’s almost always slow is ways that the language choice doesn’t matter even a little
Arguably “we can just put it in docker, and create an auto scaling microservice with a load balancer, behind a CDN for avg request latency” fits this group too. The hoops I have to jump through to get a good user experience on top of our shitty PHP backend are unreal
“Key Search Words 101”. Make it quicker and easier to find other programmers solutions on the web.
I’ve never seen a course on functional programming. That would be interesting.
It’s what the Wizard Book (Structure and Interpretation of Computer Programs) was written for.
My uni had one. Sadly I couldn’t fit it into my schedule because of overlaps and other requirements.
i took two courses on functional programming through coursera. it was based on scala.
I had one. I wish I remembered more of it.
Where’s
Using Solutions that Already Exist
No, seriously, you don’t have to build everything from scratch by yourself. Other people write code too.
It’s a double-edged sword and understanding when to re-use and when to re-implement is an art that goes wrong more often than right.
We desperately need to teach people when a 3rd party dependency is necessary and not just optional to save writing a single function (cough left pad cough).
Also when the dependency is really good but other considerations override it being a viable option like security or code ownership.
How we all didn’t collectively learn our lesson from left pad baffles me.
Yeah, the problem is the balance. In-house code sucks. Nobody outside the team tests your code. Self-developed code is not battle hardened. You can only use the skills available in your team and especially for specialist topics like databases, security or cryptography having in-house expertise is rare and expensive.
Using external dependencies sucks. You are dependant on externally developed code and on someone elses skills, quality controls and trustworthyness, and you usually don’t have time or ability to really verify any of that. Even a good dependency can get stuck in some kind of development hell (like e.g. OkHTTPClient) and not deliver updates for years, and supply-chain attacks are constant threat.
In the end both options suck for different reasons and it really depends on the scenario where one or the other is useful. Leftpad is an extreme example, but most options are less obvious.
Well said. I find I have a hard time with trying to get devs who cut their teeth on Node to take a moment and think before just reaching for a dependency. A dependency might be the right move but taking a moment to consider is a bare minimum and most people don’t do that.
I’m trying to keep my panic over how that behavior translates to AI code in check but it’s a struggle given human behavior time and time again.
Yeah, other idiots.
Got caught in that trap at my first coding job. Made a sort formula and a sr dev asked my I didn’t just use the array.sort.
My answer: I didn’t know it was there.
History of software design would be an AMAZING course.
It’d be a good idea. Hopefully it’d see an end to those idiots claiming single exit means there can only be one return statement.
I would actually love to take 3300! That sounds fun.
As for 4020, writing performant code in Python typically means calling into libraries that are written in C.
Hello programmers, electrical engineer here.
I work in MEP design, basically power design for commercial buildings and multi-tenant residential.
I am constantly saying I wish every fucking engineer, architect, interior designer, building manager, etc. had been forced to take a class on project management and accountability.
Curious if some of you run into a similar desire…
At what level is SOLID good, and when insanity begins.
You have to learn this through suffering. Class would have to be project based.
You forgot the most important one:
CSCI 7999 - logging with cat.
Missing “how to politely but firmly tell management ‘that’s a dumb fucking idea’”
-1 for unlerning OOP
But
+1 for Zork
+1 for unlearning OOP
It’s a cult
Why? I find it quite useful.
While the concept has it’s uses as a tool, the fallacy that OOP advocates fall into is overusing it.
I’ve seen many people completely swear off of using scripts, which is absolutely ridiculous. While you may use some tools more than others, swearing off an entire code structure for no reason is ridiculous.
Say there’s a module of code you need to write that has hundres if not thousands of variables that come into play in combinations that would be extremely difficult to organize as functions. You’re then stuck with passing all those as inputs and outputs between functions.
Sure, you could organize all those variables as a giant array and pass them around as one big block, but at that point you’re just emulating the shared workspace that you get with scripts, and you’d just be better off working with scripts from the start.
The issue with OOP is that it completely ignores this reality and insists that nobody should ever need a script, and if they think they do then they just aren’t clever enough.
Well you’re not wrong, but man, you’re hating the screwdriver because you work in a bolt factory.
Use the took that best suits your problem, right?
Also: what’s that code that has thousands of variables that cannot be organised? If it isn’t just an example for the sake of an example, I’m genuinely curious! And how does scripts “fix” that?
Also: I have always hated java for their overuse of OOP, but also restricting its use, wtf.
Also: I love a straightforward script, on linux at least!
Well you’re not wrong, but man, you’re hating the screwdriver because you work in a bolt factory.
Like I said, the problem with OOP advocates is that most of them are calling for bolts to be destroyed in this analogy. If they weren’t so fanatical about it we wouldn’t be havining this conversation.
what’s that code that has thousands of variables that cannot be organised?
It’s not a random example. I can’t go into detail, but it’s the code I work on on a daily basis. It’s a physics model for industrial equipment. Highly customizable for customers, and I need to know exactly where various sub assemblies are located and be able to move them in various configurations.
And scripts doesn’t “fix” the problem. It’s more that using functions is infeasible due to the difficulty in cramming everything into input arrays, so scripts end up being orders of magnitude more efficient to work with. The scripts are all called from a function, which does allow us to interface with other groups or our own custom GUI.
That’s wild, I have worked on large scientific software, coupled with electron microscopes (off all kind of types, bio, material, big, small) and we had over 700 types of processings of different data and visualisation. Without OOP in there it would have been a one man orchestra-mess per client.
We had those people clinging to their scripts too, they were actually the best getting the results out from bad aquisitions, but it’s kind of complicated because it’s not the scripts that are important but the dude using them.
The OOP was good because it tied it all together (you could easily string compute modules together to form new treatments of data for example), that’s not needed in a small, one-situation setup, but still I’d code something to manage it all if I were you (and had the possibility to do so ofc), maybe your gui does that. But then again, I don’t know how it all works where you work so what do I know 🤷🏻♀️.
Cheers
still I’d code something to manage it all if I were you (and had the possibility to do so ofc)
You’re continuing the exact problem I described. Quit. Dictating. To. Me. How. My. Code. Should. Work.
“Best practice” is a fucking guideline. You can’t bilndly apply it to every single situation and expect it to work all the time. There’s always exceptions and nuance that must be accounted for, and the people that refuse to ackowledge that are fools.
Go find someone else to gaslught, jackass.
I feel like I’m the only CS major to have taken a CS focused ethics class
Would be nice if all engineers had to take ethics
Ethics are worthless if you’re not the one calling the shots. Your only options are doing what you’re told or quitting.
Sure, but it’s important to know when to do what you’re told, and when to quit.
There’s at least one other option: Making it look like you’re doing what you’re told.
My first assignment as a professional programmer I balked at. I said it was “Unethical and immoral.” And when they told me I “had to do it” I said that I don’t and that they shouldn’t find someone else. My boss stepped in, chewed me out and told me to she would do it. Instead of putting her foot down there was just always another priority. It never got done in the ten years of the project.
What was the assignment?
Yeah, I’m not sharing that. I’m fairly sure it was legal, though.
Heh, fair enough.
