Stop using OOP

Not an argument

forall a b. m a -> (a -> m b) -> m b
(where m is Applicative)

any language with objects is an OOP language

..

OOPsie did i offend the c fags?

Any language with inheritance, encapsulation, and polymorphism.

>stop using OOP
>because making struct pointer, struct init functions, and functions that need you to pass that struct in is the way to go lads

>Using inheritance

OOP is good
doc.lagout.org/programmation/Smalltalk/Smalltalk - Objects and Design.pdf

Whats wrong with that? Also I guess Erlang is OO now?

oop doesn't necessarily have to have these things. only critical part is that you fundamentally operate on conceptual 'objects'.

e.g. it is possible to write object-oriented go programs, though go does not have inheritance.

And what’s wrong with thinking of your system as objects interacting with each other?
Give me something concrete and don’t dodge the question

i'm not op, and write a decent amount of OO code, but the functional paradigm has plenty of merit.

the most concrete thing (imo) is that it tends to lead to less code, which, in my experience, is almost always a win. plus, the code you're left with is (often) more reusable.

Monad is a * -> * that has bind and return.

Define functional programming. First class functions? Guess C++ is functional. Purity? That means all Lisps are not functional. Referential transparency? We're left with, like, 4 or 5 languages that have that property.

You can absolutely write functional code in an OO way. There’s this meme that Java = OOP. But the fundamental idea behind OO design is more about metaphor and thinking of your program as objects than it is about writing in a corporate Java style with factories and setters, getters, etc. That can be OOP but more often than not it’s not.

Think of a micro service programmed in purely functional clojure. In the Alan Kay’s definition of objects, that micro service is an object. You communicate by message passing, probably through an REST API, and you get a response. I believe in this metaphorical way of OOP, and I believe it’s much closer to what Alan Kay meant by objects.

Do you guys even enjoy programming in a smalltalk environment like Pharo?

I don’t know, I’m not the one who is telling people to stop using OOP and do FP. If anything I believe OOP is a metaphorical paradigm for the discovery of the natural joints that make a solution to a problem. That probably won’t make any sense to you if you haven’t read David West, but the idea is that OOP (and Alan Kay’s original definition of it) has little to do with java and its corporate and verbose way of programming.

this is why it's useful to think of these things in terms of paradigms rather than languages. it's definitely possible to write "OO code" in functional languages, and vice versa.

you can also view one through the prism of the other, though i'm not sure that's a useful exercise. conceptualizing a function as an object is possible, but why?

more interesting (to me, at least) is the application of the surrounding thought. trying to apply SOLID principles to Haskell code is... silly. similarly, implementing a Monad in Java is more trouble than it's worth (scala, pls no).

>he doesn't roll his own OOP in C
faggots

It’s also interesting that you mention lisp. According to Alan Kay, small talk and lisp were at that time the only OO languages. Unfortunately OOP has been corrupted by corporations who adopted OO as a buzzword without understand it, and hordes of bad programmers who mangled the term beyond all recognition.

I actually agree that what is considered idiomatic java (setters/getters for everything, abstract factories, useless patterns, badly used polymorphism and encapsulation, etc) is a very bad thing. But if we’re arguing about proper OOP, I think that not only it’s the best way to reason about programs, but also that it doesn’t get in the way of functional programming or even modern paradigms like Type driven design. It’s just a way of seeing a system as metaphors of objects. It has nothing to do with POJOs (god bless you if you don’t know what that is)

I think it’s useful to think of functions as objects when you have serverless functions. You don’t see the actual function as an object, but the serverless container instead.

But I think I agree with you. Unless you’re saying SOLID is a core of OOP? Because I don’t think so. I think SOLID is only useful as a means of reducing complexity in enterprise systems with hundreds of developers and more pain than its worth to implement for small teams

fp is an approach. it pretty much requires first-class functions (though there's probably some way to work around that if you're enough of a masochist). it is definitely possible to write functional programs in C++, but C++ is not a "functional language," in the same way that it's possible to write OO programs in CLISP, but CLISP is not an "object-oriented language."

an interesting case-study is something like Python, which supports both a functional style (lambdas, first-class functions, etc), but also classes, inheritance, encapsulation, etc. you can solve your problems using either approach (or a mixture of the two!), but is neither an "OO language" nor a "functional language."

erlang.org/download/armstrong_thesis_2003.pdf

never do

Attached: 2701810_0.jpg (630x630, 24K)

one could make the opposite claim about serverless functions, though. you can see the function as just a function. it really is a matter of perspective and how you like to solve problems. if it's better or easier for you to think of things in terms of objects, great! if not, great!

i'm not at all trying to say that SOLID is the core of OOP. i'm saying that it's an important part of the thought and practices that have cropped up to support OOP. just trying to compare common practices (or "fundamentals"), since it seems more constructive than speaking completely in the abstract.

Sure i'll write my webapp in haskell

Attached: nn.png (645x729, 51K)

Right. I agree with you on both things. The first one is just a matter of personal choice. I like to think of those things through object metaphors but I can see why you would want to think of them as just functions.

As for OOP, I think there’s a difference between old school OOP (metaphors for objects and message passing) and corporate OOP (Solid, java, etc). I try to practice the former, not the latter. And have serious doubts on whether the latter is all that useful at all

a great read and an interesting point.

one important difference between oop and fp is mutability. oop tends to encourage interior mutability (someone mentioned POJOs earlier). fp tends to discourage it (or, in the case of Haskell, make it a major chore).

this has huge implications for fault-tolerance and scalability. writing a multi-threaded system in an OOP style without something like mutexes is hard. doing the same thing in a "pure functional style" is trivial.

infoq.com/news/2010/07/objects-smalltalk-erlang

harmful.cat-v.org/software/OO_programming/why_oo_sucks

Purescript

I like how he mentions RCATWD. Except replace computers by containers or virtual machines.

for the backend? no thanks.

PS is great, and eliminates a lot of Haskell's warts (partial functions and exceptions come to mind), but it's not nearly as productive because of it. also it's slow. really slow. you'd be better off just writing functional JS if you really want to target node on the backend.

great on the frontend, though. halogen is dope.

Functional programming languages are implementation of lambda calculi.

User.Reply("No. Go fuck Yourself");

don't forget the try/catch.

A monadic operation is a unary one. :^)

OOP in the loo

That's what I'm doing, it's great.

Attached: Screenshot from 2018-09-11 11-58-34.png (600x239, 31K)

hope evereone get lisp is useless?
haskell is the same, but they make is more difficult, so not easy to get it the same useless shit like lisp

Attached: SC_SCAM.png (224x250, 4K)

You could have at least given him a less Haskell-specific answer

look just imagine a burrito

go back to fucking jeeta pussy you butthurt faggot

>not just your own pure functional DSL in an imperative language

Attached: .jpg (1280x720, 105K)

But what does that mean? I'm sure you can only make that comparison with respect to the type system of the language. But language is much more than just types. By the way, does Haskell even have formalized operational semantics? It seems like as of now it's "things behave exactly how compiler makes them to be".

What are you doing, user? Looks interesting.

looks like ruby with monads

>Haskell

literally uselss.

Separation of value and effect. With option the effect is that the computation might shortcircuit, in List the effect is that you have multiple values, and with state it's that the state gets threaded (not in the multiprocessing sense of threading, but in the sense that it gets passed on between the state modifiers).

For all three monads you can write programs where you only care about the value, while the effect is handled at statement boundaries. In scala it looks like this

for {
a

you are as pitiful as religious fanatics. oop is just another tool. use it when needed. don’t avoid bc u are a special snowflake

Thanks pajeet

Oh, I should probably add that in my code example the monad is option, and the return would be Option[Either[Error, A]] where Option tells us if the computation succeeded, while the Either comes from the validate which tells us whether the value, should the computation succeed, can be successfully validated.

Rust is the perfect balance between OOP and functional programming.

Attached: Rust_programming_language_black_logo.svg (1).png (1200x1200, 56K)

I can't stand the syntax though. I also prefer not to deal with memory if I can avoid it, but that's a luxury I can afford since I'm not working with real time stuff. That said I really like the fact that it has caught on because it actually pushes the envelope

true god

Well, you don't have to deal with memory in Rust if you don't have. It's all RAII unless you explicitly deal with raw memory access.
But you probably don't want to deal with lifetimes and ownership which can be annoying if you are used to more high level programming.

Yup, I appreciate that rust allows me to reason about memory, but I prefer using a managed run-time aka GC whenever possible.

>Rust is the perfect balance between OOP and functional programming.
I'm a little hesitant to call what Rust does "OOP".

stop creating abstractions for things you only define once.

nope.

closures are a poor mans object.

What's wrong with it?

objects are a poor man's closure.

wiki.haskell.org/Monad
wiki.haskell.org/What_a_Monad_is_not

to elaborate, monads are not about effects (there is no effect for your list example), though they can be used to separate like that (like the IO monad), they really are just a good way of composing and describing computations for anything that adheres to the monad laws. It's kinda good mathematical model for things.

oh yeah ignore the wikipedia page, it is also wrong.

Reminder that table-oriented programming is the best paradigm.

>no TABs
xDDDDddddddD

effect is not the same as side effect.

Are Scala's partial functions monads?

If you mean Option (same as haskells Maybe) then yes

either way lists don't have an effect they are (composed) data.

In this code snippet
for {
employee

my attempt at formatting didn't work out very well...

Isn't this kind of the same thing as having each object be its own process, and having them communicate through signals or network requests?

No I mean
def fun(a)(b) = a+b
seq.map(fun(3)(_))
But then is anything you put inside "map" a monad?

You're mixing partial application and partial functions. In your example you use the lists functor instance, not monad instance

fair enough

It's not OOP on Java sense, it doesn't force you to use it. But you are free to design your solution with objects in mind.
It's great because you can use functional and object features, but it doesn't drift away into impractical abstraction and stays close to how computer works.

yeah pretty much
the problem is that a universal language for that kind of communication didn't exist back then, REST APIs (or GraphQL if you're feeling fancy) solve that problem

stop being a useless meme for autists

at least i'm getting paid to fuck about in rust

functional-inspired c++ is best c++

much easier to live with than pajeet style where you need 20 pointless layers of classes for everything

at least you'll have written something instead of gluing an endless chain of stupid npm packages together (and spending ages googling for why it doesn't work when it did for the raj over on stackoverflow)

it's more "structs are useful" than OOP

breddy comfy though, as long as one avoids dealing with cancer like the windows api

A monad is just a monoid in the category of endofunctors.

This is an extremely low quality post.

Stop using dogma.

Multi-paradigm best paradigm. Use what works for the problem you're solving.

multiparadigm languages always suck

Restrictions boost creativity. We wouldn't have breakthroughs like monadic IO and garbage collection if we always used "the best tool for the job"

>Perl, Lisp, Scala, C++, C#, Java, Kotlin, and even Haskell
The most usable languages are multi-paradigm.

There's a difference between research and engineering. When you're just getting some shit done you want a language that can help you as much as possible. Then you go "well x really sucked, why is that?" and walk down the research track, sharpening your axe.

But if you spend all your time jerking off then you'll never get anything practical done.

>Perl, Scala, C++, Kotlin
all ugly unreadable garbage thanks to having no clear direction
>Lisp
C++ommon Lisp is an abomination with mountains of legacy shit obscuring everything. The most usable Lisps are the most pure Lisps, like Scheme.
>C#, Java.
Barely even count, you need more than just lambdas to do FP. In Java's case the lambdas are literally just objects.
>Haskell
what specifically are you referring to here?

>not inheriting from Fluffy, Pet, Animal
Normal languages can do multiple inheritances

fpbp