OOP is TRWTF

This reads like a :@levicki: rant to me. His "real world" examples didn't seem to demonstrate anything useful to me about what he was trying to say, except that, sure, as the old saying goes, FORTRAN programmers can write FORTRAN in any language.

I wouldn't consider myself to be an OOP zealot or superfan or anthing like that but I didn't find his case against it to be particularly compelling.

Dragoon

@boomzilla

I only skimmed the article, but that is the impression that I got as well.

hungrier

Some might disagree with me, but the truth is that modern OOP has never been properly designed. It never came out of a proper research institution (in contrast with Haskell/FP). I do not consider Xerox or another enterprise to be a “proper research institution”. OOP doesn’t have decades of rigorous scientific research to back it up. Lambda calculus offers a complete theoretical foundation for Functional Programming. OOP has nothing to match that. OOP mainly “just happened”.

An organic development that wasn't "properly designed" at a research institute? *drops monocle in shock*

topspin

@boomzilla said in OOP is TRWTF:

This reads like a :@levicki: rant to me. His "real world" examples didn't seem to demonstrate anything useful to me about what he was trying to say, except that, sure, as the old saying goes, FORTRAN programmers can write FORTRAN in any language.

I wouldn't consider myself to be an OOP zealot or superfan or anthing like that but I didn't find his case against it to be particularly compelling.

IMO, OOP got sold as yet another silver bullet for everything in the 90s (?) but definitely has its uses.
I didn't more than skim the article either, but his arguments seem to me. Yes, shared mutable state causes problems. I don't see how abstraction and encapsulation are the root cause of shared mutable state, though. I mean, just for example, encapsulation makes it pretty easy to make an object immutable.

Maybe he's just .

The methods or properties that provide access to particular fields are no better than changing the value of a field directly. It doesn’t matter whether you mutate an object’s state by using a fancy property or method — the result is the same: mutated state.

boomzilla

@topspin said in OOP is TRWTF:

IMO, OOP got sold as yet another silver bullet for everything in the 90s (?) but definitely has its uses.

Yeah. I wouldn't call it a silver bullet. I don't think such a thing exists. Difficult problems are difficult, and having a variety of tools is useful. If all you have is a hammer...

He really hates mutated state. Perhaps if he'd explained where this had been a problem for him I'd have a better idea of where he's coming from. But doing CRUD against a database and writing a detailed simulation are going to be super different.

topspin

@boomzilla said in OOP is TRWTF:

@topspin said in OOP is TRWTF:

IMO, OOP got sold as yet another silver bullet for everything in the 90s (?) but definitely has its uses.

Yeah. I wouldn't call it a silver bullet. I don't think such a thing exists.

That's what I meant.

Difficult problems are difficult, and having a variety of tools is useful. If all you have is a hammer...

Agreed.

powerlord

@Dragoon My favorite part of this article by far is the part where he calls multi-threaded code bad.

hungrier

My favourite part:

Of course, this is plain stupidity

TimeBandit

From the "slow and memory hungry" department:
https://venturebeat.com/2019/07/22/slacks-desktop-app-now-launches-33-faster-uses-50-less-memory/

Edit: This was supposed to be in other news today

TwelveBaud

@boomzilla He talked about Haskell and ML and other functional programming. It's probably the same rant about "pure" programming we've already had, just with a different color press-on bow holding the paper together.

boomzilla

@TwelveBaud said in OOP is TRWTF:

@boomzilla He talked about Haskell and ML and other functional programming. It's probably the same rant about "pure" programming we've already had, just with a different color press-on bow holding the paper together.

Yeah, obviously he was shilling for FP, which I don't have a problem with in principle, and it's super useful in its own ways. He just completely missed the boat as far as making his case as opposed to calling out some ways that people abuse their code.

Like was the Lego example trying to tell me? It didn't make any sense at all as an analogy.

PotatoEngineer

My favorite part is how very, very skimpy the "alternatives to OOP" section is. OOP is bad, because I have quotes from Famous Names! You should do Functional Programming, because you already know how to do it!

...and just how is it better? Please explain, using any detail at all.

I really need to learn some functional programming at some point, but I've tried to debug LINQ expressions (and their JS equivalents), and I often end up decomposing them into a small number of steps that I check with the debugger. Functional Programming doesn't particularly save me from being bad at programming. And the frothing zealots in the FP camp don't help – I've found a wide variety of toy FP tutorials, but I'm not actually sure what the benefits are for more-complex solutions.

topspin

@PotatoEngineer said in OOP is TRWTF:

My favorite part is how very, very skimpy the "alternatives to OOP" section is. OOP is bad, because I have quotes from Famous Names!

Love how he quotes Linus. I mean, he’s surely a great programmer, but I wouldn’t exactly take his “anything but C sucks” taste for kernel development as good general advice.

You should do Functional Programming, because you already know how to do it!

Better than the parts (not that I’ve read it, but see above) shilling procedural instead.

PleegWat

OOP is a tool. With any tool, there are days when it should be first in your hand, as well as days when it should stay firmly in your toolbox while you use something else.

dkf

@boomzilla said in OOP is TRWTF:

obviously he was shilling for FP,

Better than that, he appeared to be saying not only that OOP isn't a magic bullet, but also that FP instead is a magic bullet. Which elevates him from the Usual Fuckwad category into the Snake-Oil Salesman category. This industry has far too many purveyors of snake-oil, and over and over we find that the best approach is one that uses a mix of techniques, applying each when it makes sense but never pretending that any of them is a universal hammer.

But a sensible balanced approach doesn't make for epic rants or sell expensive seats to lectures.

cvi

There's a lot of bad OOP code because there's a lot of OOP code. If everybody were writing FP code, we'd instead instead be drowning in bad FP code (and the rant would likely be about that).

Gąska

@TwelveBaud said in OOP is TRWTF:

@boomzilla He talked about Haskell and ML and other functional programming. It's probably the same rant about "pure" programming we've already had, just with a different color press-on bow holding the paper together.

As the author of this other rant, I wholeheartedly disagree. The guy from OP is high on academic kool-aid and sounds like he's never worked in a real life project. I only read like 20% of the article, but couldn't bring myself to go further, he's just so annoying and full of self-righteousness.

The main goal of OOP is to help maintaining large applications by describing the architecture with an easy to grasp concept - objects. People live in a world of separate, independent entities that communicate with each other through a small number of well understood methods (compared to the internal complexity of the entities themselves). The idea is that describing the software world in such terms makes it much more intuitive to work with. And it's a good idea that works very well in practice. It's because this idea works well that people are able to build layers upon layers of abstraction and everything is still more or less working. Without OOP, it likely wouldn't work at all.

Design patterns are tools too. They work quite well for what they were designed for. The problem is that - in line with Sturgeon's law - 90% of developers are crap, and they have no clue what pattern is the right one. Also, they don't bother with refactoring. Even the best developer will pick a design that's wrong in the long run 9 times out of 10 - the secret to keeping it all under control is to regularly update the design so in every moment it's (close to) the best design possible given the circumstances and the likely direction that the project will take in the future. Basically - don't let any part of code become legacy. Everyone hates working with legacy code.

Functional programming is a tool too. It works very well for what it was designed for. And it was designed for reliable software that doesn't have surprises. Every professional hates surprises. In an archetypal functional code, every function, every module, every whatever level of division you pick, has clearly defined inputs and only depends on those clearly defined inputs. Cosmic rays aside, with the same set of inputs it will always produce identical output. The effect is that the dependency graph becomes very streamlined - function calls tend to become strictly hierarchical, which greatly helps avoiding spooky action at a distance. And because there are no cross-dependencies, modules can be easily isolated and parallelized - something that's increasingly important as each year AMD keeps adding moar coars.

pic rel

And honestly, you don't really need functional language for functional programming. All you need is make sure that your code only takes inputs from one place, and that the result isn't affected by anything else than those inputs. And you don't need Haskell for that. Most procedural languages are capable of that. Even C. Though more high-level languages certainly help. And - something that Blakey couldn't wrap his head around, which led to thorough derailment in the linked topic - you don't need to write all your code in functional style to take advantage of it. Hell, I'd say it's a totally wrong approach, because it prevents you from getting work done. A little functional programming here and there is good enough to get started. The more the better, of course. I suspect many programmers already practice functional programming to some extent without even realizing it (Blakey totally does - see his never-ending praise of LINQ). Functional programming is basically about taking the common knowledge among programmers - that surprises are bad and complex, hidden dependency graphs are the main source of surprises - and making a semi-formal approach to it in order to maximize the benefits.

And the most important thing - OOP and FP aren't at odds. You can use both at the same time - and they complement each other very well. In particular, the OOP abstractions allow treating code modules as if they were purely functional, even if deep down it's the same old free-for-all spaghetti m

TL;DR: don't let fanatics get into your head. FP is great, but for entirely different reasons than people talk about. So is OOP. And you don't have to choose one or the other - use both if that's what good for your codebase. Also, Rust is the best language.

Dragoon

@Gąska said in OOP is TRWTF:

Also, Rust is the best language.

Damn, so close to a good post.

loopback0

@Gąska said in OOP is TRWTF:

Also, Rust is the best language.

Put this at the start next time so I know not to read the rest of the post

topspin

@Gąska said in OOP is TRWTF:

The main goal of OOP is to help maintaining large applications by describing the architecture with an easy to grasp concept - objects. People live in a world of separate, independent entities that communicate with each other through a small number of well understood methods (compared to the internal complexity of the entities themselves).

Not sure if that's been in the 20% you read, but it's interesting he started with the same statement (separate entities), then came to a radically different conclusion because whargarbl mutable state whargarbl.

Considering his rants about abstractions, I think he totally failed to grasp what those are and how to use them. Sure, "abstractions" like AbstractInterceptorDrivenBeanDefinitionDecorator are exactly what TDWTF makes fun of, but did anybody sane ever argue that abstractions in general are bad?! He should never think of anything higher level than electrons and transistors, then.

And his rants about mutability make no sense either. Sure, immutability comes basically for free in FP, but making something immutable is still easy to do in OOP.

Mutable state in the real world is almost never a problem, since things are kept private and never shared. This is “proper encapsulation” at work.

Encapsulation is the trojan horse of OOP.
What we have never been told is that encapsulation, in fact, is glorified global state.

@Gąska said in OOP is TRWTF:

TL;DR: don't let fanatics get into your head.
Also, Rust is the best language.

ISWYDT.

sockpuppet7

@Gąska said in OOP is TRWTF:

Also, Rust is the best language.

Memory safe and C-like performance, I agree it should replace everything else.

TwelveBaud

@Gąska Absolutely did not mean to imply that it was you ranting; in that post, you gave a clear, concise summary of what purity was, why it's useful, and why it shouldn't be the only tool in your toolbox. To me, it's the rebuttal both to the rant in that thread and the article we're discussing here. Your post here took that to the next level, and if I had a Medium account I'd totally cross-post it there and give you all my likes.

Adynathos

There was a similar rant claiming that C++ was invented to create more jobs for programmers, because now software projects are big and complicated while in the olden days a few devs and assembler was enough.

pie_flavor

Author is a complete twit.

Simplicity is the opposite of complexity. Therefore our first and foremost responsibility as software developers should be to reduce code complexity.

Oh my god! What a revelation! Reduce the code complexity, how could I never have thought of that. After all, nothing is more complex than procedural abstraction; your code would be so much more clear if you replaced a high level object model with ten thousand lines of verbatim string parsing.

It is also wrong that many mainstream languages don’t offer any other alternatives to code organization other than OOP.

Haskell, one should note, is a horribly shitty language for not offering any other alternatives to code organization other than FP.

There’s no objective and open evidence that OOP is better than plain procedural programming.

Ever try to write a GUI?

It looks good on paper — we have clean hierarchies of animals, dogs, humans, etc. However, it falls flat once the complexity of the application starts increasing.

But that's not the programming paradigm's fault. That's the programmer's fault. I'm sure your code is perfectly comprehensible when it was written with the goal of 'most calls to map and >> possible', as functional code so often is.

the truth is that modern OOP has never been properly designed. It never came out of a proper research institution (in contrast with Haskell/FP).

Good lord! A programming language and paradigm not coming out of a research institution? Stop the presses!

OOP doesn’t have decades of rigorous scientific research to back it up.

FP doesn't have decades of anyone using it for anything ever to back it up.

Projects get delayed, deadlines get missed, developers get burned-out, adding in new features becomes next to impossible. The organization labels the codebase as the “legacy codebase”, and the development team plans a rewrite.

Such is the life. But you were talking about OOP? You should probably continue about that.

OOP is not natural for the human brain, our thought process is centered around “doing” things — go for a walk, talk to a friend, eat pizza. Our brains have evolved to do things, not to organize the world into complex hierarchies of abstract objects.

You are a retard. This, my instinctual response, immediately classifies you as a retard-object which is a kind of person-object but distinct by its virtual method 'think' (i.e. no-op). In fact you're thinking the exact opposite way: you perceive it as 'doing' something, meaning it's still a separate task to you, but you don't perceive your concept of everything around you as an object hierarchy, because it's so deeply ingrained it's analogous to thinking itself to you.

If you could think.

As an oversimplified example, the output of 2+2 or calculator.Add(2, 2) mostly is equal to four, but sometimes it might become equal to three, five, and maybe even 1004.

And yet such things are required because it's running on computers with hard disks and internet connections and headphones. If the meaning of '10.002' changed due to the computer switching languages, it had better switch to the correct computation instantly. Now explain how you're supposed to represent mutable underlying state from a pure language, and if you say 'monad' you lose.

Similarly, a good programming framework should provide mechanisms that prevent us from doing stupid things.

If only you had such a framework, because you've been doing a stupid thing for four pages now with no sign of stopping.

OOP code encourages the use of shared mutable state, which has been proven to be unsafe time and time again.

Ever used, say, Ruby or Rust? I think you meant to say 'C# and Java encourage the use of shared mutable state'.

OOP typically requires a lot of boilerplate code (low signal-to-noise ratio).

Ever used, say, Python or Kotlin? I think you meant to say 'C# and Java typically require a lot of boilerplate code'.

It even features design patterns that address the issues of nullability and provides a superior way of error handling.

You should try languages that aren't C# and Java sometime. For instance, Swift hits this one out of the park. More so than any functional language ever.

OOP was never intended to have things like inheritance, polymorphism, the “new” keyword, and the myriad of design patterns.

But functional programming was intended to have things like sum types, abominably terse syntax, the pipe operator, and the myriad of symbols that make you think you're writing fucking Perl.

Erlang is OOP in its purest form. Unlike more mainstream languages, it focuses on the core idea of OOP — messaging. In Erlang, objects communicate by passing immutable messages between objects.

Is there a point to any of this? Do I care what it was 'supposed' to be? You already went off on how it was grown organically, and now you've forgotten.

Is there proof that immutable messages are a superior approach compared to method calls?

Hell yes! Erlang is probably the most reliable language in the world. It powers most of the world’s telecom (and hence the internet) infrastructure.

And your bank uses COBOL. Now go fuck yourself.

Let’s forget for a second that we’re all grown-ups, and pretend we’re trying to assemble a cool lego truck.

However, there’s a catch — all the truck parts are randomly mixed with parts from your other lego toys. And they have been put in 50 different boxes, randomly again. And you’re not allowed to group your truck parts together — you have to keep in your head where the various truck parts are, and can only take them out one by one.

What are you even on about anymore?

Now, he’s bored with all that money and decides to do things a little bit differently. He thinks that it would be a good idea to have a painting party. He invites his friends elf, Gandalf, policeman, and a zombie to help him out. Teamwork! They all start painting on the same canvas at the same time. Of course, nothing good comes out of it — the painting is a complete disaster!

Shared mutable state makes no sense in the real world. Yet this is exactly what happens in OOP programs — state is promiscuously shared between various objects, and they mutate it in any way they see fit. This, in turn, makes reasoning about the program harder and harder as the codebase keeps growing.

Functional programming makes no sense in the real world. Imagine if you were creating a painting, but you weren't allowed to modify the painting - you could only put each brushstroke on a piece of plastic wrap that went over the previous one. I too can sound intelligent.

Is all state evil? No, Alan Kay state is not evil! State mutation probably is fine if it is truly isolated (not the “OOP-way” isolated).

Isolated FROM WHAT? Shared WITH WHAT? Mutable TO WHOM? Describe what the fuck it is you're talking about, please.

What’s the use in having methods and properties on an object if it cannot be mutated?

Hahahahahahaha. Now I understand why you have always had trouble with OOP. You complete and utter moron.

What we have never been told is that encapsulation, in fact, is glorified global state.
...
This creates a complex graph of promiscuously shared objects that all end up changing each other’s state.

What the fuck does that have to do with why you shouldn't use global state?

The methods or properties that provide access to particular fields are no better than changing the value of a field directly. It doesn’t matter whether you mutate an object’s state by using a fancy property or method — the result is the same: mutated state.

Did anybody say differently?

OOP attempts to model everything as a hierarchy of objects. Unfortunately, that is not how things work in the real world. Objects in the real world interact with each other using messages, but they mostly are independent of each other.

I note that you are not phasing through the floor and the ink is coming out of your pen. I do believe objects in the real world are sort of completely dependent on each other.

OOP inheritance is not modeled after the real world. The parent object in the real world is unable to change the behavior of child objects at run-time. Even though you inherit your DNA from your parents, they’re unable to make changes to your DNA as they please.

That is the exact opposite of what OOP typically allows.

You do not inherit “behaviors” from your parents, you develop your own behaviors. And you’re unable to “override” your parents’ behaviors.

And that is the exact opposite of the truth.

Not to mention a moronic comparison. Anyone notice how every time he can't explain something, he switches to a completely fucking stupid analogy whose illogic is entirely dependent on the subjects?

You, as a person, don’t have a “write” method either — you make the decision to write some text based on outside events or your internal thoughts.

Tell us more about the programming model of components deciding what to do on their own because they observe outside state changing.
If someone tells me to write something down, and I take pen to paper, what the fuck do you call that in your analogy?

In non-OOP languages, doing trivial things like saving data to a file is straightforward — very similar to how you would describe an action in plain English.

Of course! Something about monoids in the category of endofunctors, I recall.

Sure, going back to the painter example, the painter owns a PaintingFactory. He has hired a dedicated BrushManager , ColorManager, a CanvasManager and a MonaLisaProvider. His good friend zombie makes use of a BrainConsumingStrategy . Those objects, in turn, define the following methods: CreatePainting , FindBrush , PickColor , CallMonaLisa , and ConsumeBrainz.

Of course, this is plain stupidity, and could never have happened in the real world. How much unnecessary complexity has been created for the simple act of drawing a painting?

There’s no need to invent strange concepts to hold your functions when they’re allowed to exist separately from the objects.

Seriously. Never used Scala? Never used, god forbid, C++? Is your entire world defined by C# and Java?

Boilerplate code is probably the biggest offender when it comes to the signal-to-noise ratio. Boilerplate code is “noise” that is required to get the program to compile. Boilerplate code takes time to write and makes the codebase less readable because of the added noise.

Whereas none exists in functional programming. The compiler just interprets your ideas straight out of your head.

Yet testing of private methods in OOP is nearly impossible.

Whereas FP doesn't even have private methods, and therefore Better.

In the simple example above, the line count has more than doubled just to extract a single method. Why does refactoring create even more complexity, when the code is being refactored in order to decrease complexity in the first place?

Contrast this to a similar refactor of non-OOP code in JavaScript:

It of course is entirely because of the OOP nature, and not because of the verbose syntax and rigid model. Kotlin's interface delegation? Never heard of it.

Unfortunately, the design patterns are nothing other than band-aids. They exist solely to address the shortcomings of OOP.

Wat? TIL 'your code looks better if you pattern it well instead of slapping everything everywhere' is a 'shortcoming'. Again, this makes me fear for your code quality*.

Soon, adding in new functionality, and even making sense of all the complexity, gets harder and harder. The codebase will be full of things like SimpleBeanFactoryAwareAspectInstanceFactory, AbstractInterceptorDrivenBeanDefinitionDecorator, TransactionAwarePersistenceManagerFactoryProxyorRequestProcessorFactoryFactory .

Only if you put them there. Also, +1 for equating 'OOP' with 'Spring'.

OOP inheritance has nothing to do with the real world. Inheritance, in fact, is an inferior way to achieve code reusability.

Again: You don't understand OOP in the slightest. And have never written a GUI.

Functional programming, on the other hand, allows us to achieve the same polymorphism in a much more elegant way…by simply passing in a function that defines the desired runtime behavior.

As opposed to passing in an object that defines the desired runtime behavior.

As we discussed earlier, encapsulation is the trojan horse of OOP. It is actually a glorified global mutable state

which you still haven't explained how it's relevant to encapsulation at all

I don’t even know what to say…a fancy word for a simple concept. In procedural/functional languages we can simply “hide” the implementation details in a neighboring file. No need to call this basic act an “abstraction”.

And?

Five bucks says this person never actually got around to learning proper OOP and went functional early enough that they only things they even know about it are what they picked up from their colleagues memeing about it.

Applied Mediocrity

@Adynathos Bjarne Stroustrup himself admitted it!

jokes > Stroustrup C++ 'interview'

DogsB

I read as far as this.

Instead of reducing complexity, it encourages promiscuous sharing of mutable state

Actually it fucking doesn't. You fucking decide to do that when you can't be arsed to write an immutate class to pass data around. More likely you decided to be lazy and let the ORM do everything and then wondered why you're getting bitchslapped when you have a 1000 line entitly class that you pass around everywhere and can't even be bothered to at leasts use to ORM to make it read only.

and introduces additional complexity with its numerous design patterns.

Books on design patterns are heavy for many reasons. The primary one being that you can hit someone hard with them when they suggest using a pattern. Learn from design patterns. Don't shoe horn them in everywhere.

Applied Mediocrity

Here comes @pie_flavor, gonna tell you the story
Hand me down my codin' tools

...

He got the action, he got the motion
Oh yeah, the boy can play
Dedication, devotion
Where the heck he finds all that time in a day

IOW, DR, but I admire your dedication to the craft.

Gąska

@pie_flavor said in OOP is TRWTF:

But functional programming was intended to have things like sum types, abominably terse syntax, the pipe operator, and the myriad of symbols that make you think you're writing fucking Perl.

While I agree that syntax of most functional languages is godawful, sum types and pipe operator are actually freaking awesome. Piping is like method chaining, except they don't have to be methods (and this is good because methods are more annoying to work with than free functions).

pie_flavor

@Gąska I'm not saying they're bad. I'm saying that I highly doubt FP was designed with those features in mind, if OOP wasn't designed with 'new' and polymorphism in mind.

Gąska

@pie_flavor well, if OOP wasn't designed with polymorphism, then it's fair to say FP wasn't designed with functions.

boomzilla

@pie_flavor said in OOP is TRWTF:

Sure, going back to the painter example, the painter owns a PaintingFactory. He has hired a dedicated BrushManager , ColorManager, a CanvasManager and a MonaLisaProvider. His good friend zombie makes use of a BrainConsumingStrategy . Those objects, in turn, define the following methods: CreatePainting , FindBrush , PickColor , CallMonaLisa , and ConsumeBrainz.

Of course, this is plain stupidity, and could never have happened in the real world. How much unnecessary complexity has been created for the simple act of drawing a painting?

There’s no need to invent strange concepts to hold your functions when they’re allowed to exist separately from the objects.

Seriously. Never used Scala? Never used, god forbid, C++? Is your entire world defined by C# and Java?

Either way. He'd just have functions to do all of those things. He literally has no point except, "I like to organize my code differently."

DogsB

@Gąska said in OOP is TRWTF:

has clearly defined inputs and only depends on those clearly defined inputs.

People keep talking about this like it's new and profound. Are the js developers finally understanding the shitheap they've created for themselves?

ben_lubar

@boomzilla said in OOP is TRWTF:

Yeah. I wouldn't call it a silver bullet. I don't think such a thing exists.

vampire hunters with guns would like a word with you

boomzilla

@ben_lubar said in OOP is TRWTF:

@boomzilla said in OOP is TRWTF:

Yeah. I wouldn't call it a silver bullet. I don't think such a thing exists.

vampire hunters with guns would like a word with you

Wondering why their silver bullets don't work against vampires?

ben_lubar

@boomzilla said in OOP is TRWTF:

@ben_lubar said in OOP is TRWTF:

@boomzilla said in OOP is TRWTF:

Yeah. I wouldn't call it a silver bullet. I don't think such a thing exists.

vampire hunters with guns would like a word with you

Wondering why their silver bullets don't work against vampires?

I mean, they're still silver. And bullets.

topspin

@pie_flavor said in OOP is TRWTF:

In non-OOP languages, doing trivial things like saving data to a file is straightforward — very similar to how you would describe an action in plain English.

Of course! Something about monoids in the category of endofunctors, I recall.

Oh right, I missed that. While he raves on how FP makes it easy to not have mutable state, he neglects to mention that to actually get side effects like writing to a file (which, in the end, is why you actually run a program) in FP you need, like, a PhD in monads or something.

DogsB

Are we perhaps more worried about “looking smart” in the face of our peers by making use of fancy OOP terms like “design patterns”, “abstraction”, “encapsulation”, “polymorphism” and “interface segregation”? Probably not.

Every developer worth their salt knows that it's their solemn duty to prevent these people polluting the gene pool

The software industry is centered around OOP.

Not really. It's centered around the front-end, usually js, and the cluster fuck that entails.

Am I the only one that thinks he's probably the lower end of mediocre at his job and bitching at his tools.

Also it's obvious he's never ridden a horse. Another creature that's as dumb as a rock but an absolute joy to ride and play with. That's why they're still around. Great for crowd control too. Regularly used by police here to get into places that cars can't go.

boomzilla

@DogsB said in OOP is TRWTF:

Am I the only one that thinks he's probably the lower end of mediocre at his job and bitching at his tools.

While blakey's still on ragequit hiatus? Yeah, look like it.

Captain

@topspin Monads are easy too.

Monads make it easy to tag where state is getting threaded through your program, so you know where you actually need to pay attention to state.

This is unlike typical imperative/OO programming, where namescapes tend to get polluted by semi-global state variables that you need to mentally simulate/populate while you read the code.

topspin

@Captain said in OOP is TRWTF:

@topspin Monads are easy too.

Compared to what, though?
Everything is relative. Compared to just doing it in non-FP languages they are not (and the original rant praises FP for being stateless, ignoring the situations when you do want state).

Also, i can’t find the meta-problem article anymore that talks about the problem with “simple monad tutorials”, but I got this instead.

The Fallacy of Monad Tutorials

Numerous attempts were made to explain monads in simple definitions; and monad tutorials have become a genre of its own. And yet, times and times again, they fail to enlighten the readers.

The shortest explanation of monads looks like this:

A Monad is just a monoid in the category of endofunctors

It’s both mathematically correct and totally useless to anybody learning functional programming. To understand this statement, one has to know the terms “monoid”, “category” and “endofunctors” and be able to mentally compose them into something meaningful.

Captain

@topspin Compared to just assuming you're in the IO monad and having semi-global state everywhere, which is what most OO/imperative languages tend to do. Hell, being "imperative" means that you're in a single monad you can never escape. So you already have the difficulty of monads, and the difficulty of misusing them as well.

Use monads for the same reason you don't put EVERYTHING in main.

If you don't understand what a monoid in the category of endofuctors is, i don't know what to tell you.

boomzilla

@Captain every so often I try to figure out what this monad shit is about and then I'm hit with a bunch of Haskell notation and I give up. I guess I'm too to wrap my mind around the syntactical paradigms or something. And it's usually after some functional hipster is telling me about all these problems I have that I never really noticed as such before.

Captain

@boomzilla: yeah, a "monad" as a general concept have exactly the same complexity as an "imperative programming language". Haskell is powerful enough to let you design your own imperative programming languages (typically to deal with an effectful computation).

So what do you need to define an imperative language? Syntax, and semantics for passing values around. The "hard" part of the Haskell tutorials (especially if you don't know Haskell) is seeing the forest for the trees, and realizing that they are using Haskell notation to:

name the imperative language (Maybe, IO, the type variable m, etc)
defining the semantics of taking values out of value with type m a and passing them into a function that that takes in an a and returns an m b (which guarantees that we stay "in" the monad)

If you get those two ideas, and how 2 lets you define chains of computations by "pulling values" from expressions, then you're 100% of the way there. If you do both of these, you can treat the language defined by m as an imperative programming language in its own right.

And similarly to imperative languages and their libraries, you don't need to know how to write a library (or a monad) to use one.

mott555

@Captain said in OOP is TRWTF:

@boomzilla: yeah, a "monad" as a general concept have exactly the same complexity as an "imperative programming language". Haskell is powerful enough to let you design your own imperative programming languages (typically to deal with an effectful computation).

So what do you need to define an imperative language? Syntax, and semantics for passing values around. The "hard" part of the Haskell tutorials (especially if you don't know Haskell) is seeing the forest for the trees, and realizing that they are using Haskell notation to:

name the imperative language (Maybe, IO, the type variable m, etc)

defining the semantics of taking values out of value with type m a and passing them into a function that that takes in an a and returns an m b (which guarantees that we stay "in" the monad)

If you get those two ideas, and how 2 lets you define chains of computations by "pulling values" from expressions, then you're 100% of the way there. If you do both of these, you can treat the language defined by m as an imperative programming language in its own right.

And similarly to imperative languages and their libraries, you don't need to know how to write a library (or a monad) to use one.

I feel like I just read something about cricket.

topspin

@Captain said in OOP is TRWTF:

@topspin Compared to just assuming you're in the IO monad

@boomzilla said in OOP is TRWTF:

some functional hipster is telling me about all these problems I have that I never really noticed as such before.

I have a feeling that "assuming you're in the IO monad" is easier for almost everybody, after all. Because you have to do exactly nothing to do that.

Look, I'm not arguing against functional programming. I think it would actually be beneficial if the scales would tip a bit more in that direction, there's certainly a beauty in FP. But saying "it's too hard to have immutable state in OOP languages" (OP article, not you) doesn't contrast well with "these FP concepts are so simple, everybody must be a moron not to get that".