I just have never understood the whole OOP vs Func...
# announcements
h
I just have never understood the whole OOP vs Functional debate. They're not mutually exclusive. Sure, you can't fully do both at once, but the best principles of each can always be considered. Kotlin definitely pushes for the immutability of data that FP espouses. But even in OOP, it's been established for a long time that it is horrible etiquette to have a function operate on the arguments, unless you absolutely have to (i.e. it would be significantly less efficient not to) Hence why often in oop, a method will return a new instance of a class instead of changing the state of the instance passed in. Essentially, I just think always design your objects to the best principles of oop and your functions to the best principles of functional and why debate?
👀 2
👍 2
m
🍿
c
Because people like to put everything in clearly labeled boxes. Which is contrary to how our world works. As soon as you stop trying to do that consciously, everything kind of clicks in place. What I'm saying is, yes, I agree, use whatever fits wherever you need it.
👍 1
g
Can you take the best from both worlds? Probably yes but a lot of people believe, and rightfully so, that functional is objectively superior to imperative. Hence the debate. Imho, a good type of debate because it brings a lot of fresh ideas and changes the landscape of modern development. Kotlin/Swift is basically a product of this debate. It's not the same as bikeshedding over two libraries that are doing virtually the same thing.
1
a
It's kind of comical now but a decade ago this debate was dominated by java 6 and OOP being inseparable in people's minds, .net following so closely in that vein at first reinforced it
m
From: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html ----------------------------- The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.
😀 1
m
@ghedeon please reread your post. It's an example.of exactly what the OP was talking about. Also believing something is objectively better, after reduction, is merely believing. There is no objectively if it's only belief. Not sure if that was your intent either. There are aspects of bot FP and OOP that are great. But often people confuse things too. As others have said, immurability is generally a good thing. But some believe only FP is immutable. Some.confusion, and us Devs like to disagree. Not quite the same, but tabs vs spaces, vim vs emacs, language comparisons etc.
h
Coke vs pepsi
m
Very true. It's not developers, it's people. I guess it gives us something to 'talk' about?
h
I'm a bit embarrassed to have posted this, because it makes me seem like I'm just trying to bait out a conversation about an overly discussed topic. But as @Mike pointed out, discussions such as these are very crucial, and our beloved Kotlin exists in part due to them.
g
As a Java dev that 99% of the time writes imperative code I'm probably not the best guy to defend FP but in my limited understanding it's a higher abstraction/cognitive level. So not exactly coke vs pepsi. In ideal world code is an annoying inconvenience. Why? Because in ideal world you model your problem via set of formal requirements, you execute them, you get your answer. We know WHAT and we don't know or care HOW it's done. Requirements --> answer ("Ok Google, make me another Facebook or somethin'!") Basically, a math function (if we feel courageous, we can extend the concept as far as to wavefunction of the Universe simple smile). But we're not there yet, so we have to bear the burden of writing code as an intermediate step: requirements -> code -> answer. Code brings complexity. And complexity is "the biggest problem of the development and maintenance of large-scale software systems"[*]. We want to reduce it. What contributes to complexity? State and control flow (bread and butter of imperative programming). Whatever helps to avoid/minimize these two factors — helps us reduce HOW part and focus on WHAT, by bringing our code closer to formal rules or Logic as we call it. So, basically declarative programming (hi Compose), ex. functional/logical. [*] - https://github.com/papers-we-love/papers-we-love/blob/master/design/out-of-the-tar-pit.pdf
I know, I know, it's time to pack it up when you see Uncle Bob, DHH or pdf links.