Object oriented programming is the only sane way to write software

object oriented programming is the only sane way to write software.
c++ out classes c.
prove me wrong cucks.

Attached: is_this_OO.png (500x988, 367K)

babby's first programming huh?

Do you like inheritance, or composition?

Attached: CPIrMBJWoAA13jV.png (652x479, 310K)

Yes, yes. I like polymorphism as well.

I licked a negro once

Attached: xZbq9CH8_400x400.jpg (400x400, 21K)

Using a sane language that provides either compile time or run time dependency injection via reflection built into the language
IE:
class Service
{
protected $logger;

public function __construct(LoggerInterface $logger)
{
$this->logger = $logger;
}

public function divide($a)
{
if ($a == 0) {
$this->logger->warn('Cannot divide by zero!');
return null;
}
return 1/$a
}
}

// some other part of the code

class NullLogger implements LoggerInterface
{
// code
}

class FileLogger implements LoggerInterface
{
// more code
}

// Another part of the code

$app->singleton(LoggerInterface::class, FileLogger::class);

Writing code like this has been the most enjoyable aspect of programming. Both the language and I know that this class requires a LoggerInterface. Why should I need to specify every single time I create a new instance? And if I don't have dependency injection, if we need to switch from a FileLogger to a DatabaseLogger, I'd need to switch every single instance

Good for you.

Can either of those languages even do proper monads?

Monads are just a solution to Haskell's self-inflicted design retardation of being pure and lazy and real languages don't need them. That said I'm sure someone has crammed them into C++ with templates somehow.

>Not understanding what a monad truly is.
wew lad
I bet you handle your asynchronous behavior using mutexes and semaphors and call it elegant.

No. I handle asynchronous behavior using goroutines, mapreduce, or promises :)
Why use anything else?

A promise is basically a monad.

>Language crammed with retarded problems entirely of the designers' own making
>Add over-engineered abstractions nobody else needs or wants
>y-you just don't understand ;___;

90% of the use cases for monads are just IO or internal state. The other 10% isn't important enough to abstract and thus no one cares about monads.

>2018
>not implementing your own microkernels in C + assembly

t. retard who can't into category theory but still uses their basic knowledge of functional programming to pretentiously impress other retards.
Monads aren't hard and there are tons of different ones that (good) functional programmers use to handle lots of different types of problems. Admittedly there are less examples of well known useful co-monads but that's mostly cause people forget they exist.

>there are tons of different ones that (good) functional programmers use to handle lots of different types of problems

Way to get buttflustered and completely sidestep what I posted. This is exactly the point. No one uses monads apart from functional language programmers, because no one else needs them.

You use things that are basically monads (eg. promises) except that you reinvent the wheel each time.

No, promises are promises. Even if the core behavior can be modeled as a monad, in imperative languages they're typically implemented explicitly, without leaning on the monad abstraction. You do not needs to factor out every possible concept in programming. Monads, as a compsci abstraction, are not generally useful to imperative language users and it's usually more clear and instructive to implement and talk about things explicitly without going higher level.

>Abstractions are unnecessary
>OOP thread
lololol

*Monads* are unnecessary.

but monads are not basically promises.

I know its an OOP language but is there actually any point to writing in OOP in python.

Dc Monalds?

They are. You can take any type and turn it into a promise of that type, you can also take a 'promise of a promise of a type' and turn it back into a 'promise of a type' and so on. They obey all the monad laws (as in Category Theory). In what way are they different from monads?

Actually, the List Monad is the most commonly used monad.

>writing oop in python
Literally why.

Python is a glorified scripting language, sure it HAS OO features but they are completely optional and definitely not the path of least resistance to getting anything done.

The same argument can be given about Python's FP elements as well.

Not that guy but python supports stuff like multiple inheritance and type annotations in its OOP. It's easier to use OOP in Python than in Javascript or C++.

Promises are still monads even if they don't implement a "monad interface". Knowing that something is a monad helps you as a developer to structure your program. Just like how integers are monoids over addition, you're using category theory everyday in your poo language wether you like it or not.

>it's easier to use oo in python than c++
That's because Python just works regardless of how badly implemented an idea or design consideration is. This is good and bad for obvious reasons.

Python also supports monads because some guy built a package that contains them. It doesn't make it as functional as Haskell as a result.

The point here is that if you want to learn how to use OO correctly then you need to use a language that is built around the OO paradigm so you are forced to design this way, same thing goes for FP.

Using Python is just lazy because everything works because that's what Python is designed to do.

I mean, Monads are a more general structure.

Take for instance the fix point monad, how would you define that thing with promises?

I think that the mindset that monads are the same as promises limits their potential, sure they look a lot like the maybe monad combined with the IO monad, but that's basically it.

You can use monads to truncate infinite loops, define weird concurrency schemes, all sort of fun stuff. Not only to wait for a value and see if the value is an error or the value itself...

I see your confusion. I didn't mean that promises are monads in the sense that any monad can be implemented as a promise. I meant that promises are monads in the sense that promise is a monad, just like the list monad and other monads.

>asynchronous behavior using mutexes and semaphors
Asynchronousness has nothing to do with concurrency primitives

huh, I had no idea that C++ had a std::async library. I thought people just forked threads and used concurrency primitives.

Dumb phoneposters.