[deltasevennine]

This opinion is also biased. We have no theoretical method for determining which design philosophy is better than the other.

We can't know whether the OOP religion is better, we also can't know if the Haskell religion is better, and we can't know whether NEITHER is better. (this is key, even the neutral point of view where both are "good" can't be proven).

We do have theories to determine algorithmic efficiency. Computational complexity allows us to quantify which algorithm is faster and better. But whether that algorithm was better implemented using FP concepts or OOP concepts, we don't know... we can't know.

A lot of people like you just pick a random religion. It may seem more reasonable and measured to pick the neutral ground. But this in itself is A Religion.

It's the "it's all apples and oranges approach" or the "FP and OOP are just different tools in a toolbox" approach.... but without any mathematical theory to quantify "better" there's no way we can really ever know. Rotten apples and rotten oranges ALSO exist in a world full of apples and oranges.

You can't see it but even on an intuitive level this "opinion" is really really biased. It seems reasonable when you have two options to choose from "OOP" and "FP", but what if you have more options? We have Declarative programming, Lisp style programming, assembly language programming, logic programming, reg-exp... Are we really to apply this philosophy to ALL possible styles of programming? Is every single thing in the universe truly apples and oranges or just a tool in a toolbox?

With this many options it's unlikely. Something must be bad, something must be good and many things are better then other things.

I am of the opinion that normal Procedural and imperative programming with functions is Superior to OOP for the majority of applications. I am not saying FP is better than imperative programming, I am saying OOP is a overall a bad tool even compared with normal programming. But I can't prove my opinion to be right, and you can't prove it to be wrong.

Without proof, all we can do is move in circles and argue endlessly. But, psychologically, people tend to fall for your argument because it's less extreme, it seemingly takes the "reasonable" mediator approach. But like I said even this approach is one form of an extreme and it is not reasonable at all.

I mean your evidence is just a bunch of qualitative factoids. An opponent to your opinion will come at you with another list of qualitative factoids. You mix all the factoids together and you have a bigger list of factoids with no definitive conclusion.

[rileyphone]

> without any mathematical theory to quantify "better" there's no way we can really ever know. Rotten apples and rotten oranges ALSO exist in a world full of apples and oranges.

So you believe that the only way things can be compared is on quantitative measurements? Not with how they impress their users within whatever context they're in?

> I mean your evidence is just a bunch of qualitative factoids. An opponent to your opinion will come at you with another list of qualitative factoids. You mix all the factoids together and you have a bigger list of factoids with no definitive conclusion.

This is the process in which we gain knowledge in an uncertain world. I guess you could take the nihilistic stance and ignore it, but what's the use of arguing with nihilists?

[deltasevennine]

>So you believe that the only way things can be compared is on quantitative measurements? Not with how they impress their users within whatever context they're in?

No but I believe that quantitative measurements are the ONLY way to definitively verify certain things.

>This is the process in which we gain knowledge in an uncertain world. I guess you could take the nihilistic stance and ignore it, but what's the use of arguing with nihilists?

I'm not ignoring anything. I'm saying especially for programming, nobody knows anything. Which is actually better OOP or FP? Nobody knows. This isn't philosophy, there is no definitive proof for which is better.

[com2kid]

> Computational complexity allows us to quantify which algorithm is faster and better. But whether that algorithm was better implemented using FP concepts or OOP concepts, we don't know... we can't know.

The CPUs code runs on are imperative, with a lot of complexities and details hidden from programmers by magic the CPU does involving things like reordering and automatic parallelization.

However, none of the current languages are great at writing code that maps to how the CPU works. One can comment that functional programming does a better job of breaking up data dependencies, but imperative code can also do that just fine.

The problem with mapping paradigms to performance is that none of the paradigm purists care about performance, end of the day they care about theoretical purity.

CPUs don't care about paradigms, they care about keeping execution units busy and cache lined filled up.

[deltasevennine]

>The problem with mapping paradigms to performance is that none of the paradigm purists care about performance, end of the day they care about theoretical purity.

It's not theoretical purity. It's more tech debt. How do I code things in a way where there's zero tech debt. Such that all code can be re-used anywhere at anytime.

[com2kid]

Separate problem!

Answer is good code review and design practices. Real CRs early on in the process, not just before signing off on feature complete.

I've seen horribly unusable code that was "good examples" of both OOP and FP. The OOP peeps have so much DI going on that tracing what actually happens is impossible, not to even get started on debugging.

The FP purists have so many layers of indirection before stuff actually happens (partial function application all over the place and then shove everything through a custom built pipe operator and abuse the hell out of /map/ to do the simplest of things).

Meanwhile some crusty old C programmer writes a for loop and gets the job done in 10, obvious, easy to read, lines.

[deltasevennine]

I am from the camp that FP code produces much less tech debt then other forms of programming.

But the problem here is that no one here can prove or disprove what I just said. And that is the point of my thread.

In fact I believe tech debt is a fuzzy word that is is ripe for formalism such that we can develop a theory around what tech debt is and how to definitively eliminate it through calculation,... the same way you calculate the shortest distance between two points. I believe that the FP style is a small part of that theory.

But that's besides the point. Because since this theory doesn't exist yet, you and I have no way of verifying anything. You can leave me a code review and I can disagree with every qualitative opinion you leave in it.

[Supermancho]

> We have no theoretical method for determining which design philosophy is better than the other.

We do have a theoretical method. It's the scientific method. Other than that, I'm largely of the same thinking. Also, confusing language implementation with overall design is a major source of confusion (eg Java vs OOP vs Erlang vs FP vs Haskell, etc)

How to measure "better" and how the data is interpreted, are the major stopping points to improving software language usability. There have been some attempts (re: Quorum). Classic OOP (inheritance, et al) is simpler to use than mixins for many projects. So now we have to worry about project size as another axis. Then we have to address the issue of median developer effort. What about memory? How do you weigh FP allocate-stack-as-a-for-loop vs reduced mutability? It's more complex than FP good OOP bad.

[still_grokking]

Nobody argued for any "better".

The point is: When things become a religion with cargo culting acolytes even the "best" approaches stop making sense.

That's completely independent of the concrete religion at hand.

I did not argue to "pick sides"!

In the end all the approaches are just tools. You need to wield them wisely for optimal results.

[deltasevennine]

This is the problem. You didn't even read my argument. Go read it again, carefully, instead of skimming through it.

My point is:

Maybe one of these religions is right. Maybe something is the best. Maybe a side must be picked.

You didn't argue for better. You argued that everything is the same, that all things are good and nothing is bad and that every single thing in the programming universe is a tool in a toolbox.

I disagree. Violently.

The point is neither the culting acolytes OR people like you can prove it either way.

But calling people who don't share your opinion as "culting acolytes" is manipulative. The words have negative connotations and it's wrong. Extreme opinions in science and logic are often proven to be true, they are often validated. To assume that anyone without a neutral opinion is a cultist is very biased in itself.

Here's a good analogy: I believe the world is round. I'm an extremist. You on the other hand embrace all theories as tools in a toolbox. The world could be round or it could be flat, your the reasonable neutral arbiter taking neither the side of the flat-earther or round-earther.

The illusion now is more clear. All 3 sides are a form of bias, but clearly our science says only one of these sides is true, and this side is NOT the "neutral arbiter" side

[still_grokking]

I did not argue for "everything is the same".

Quite the contrary.

I've said: Everything depends on context.

What makes sense for Haskell does not necessary make sense for other languages.

Also there is no "side" that needs to be picked. What's a good idea in one context could be a terrible idea in some other context.

But people are copying blindly Haskell lately.

The issue is that this happens blindly — again without questioning anything about the underlying premises.

Doing so is called "cargo culting". And that's something done by acolytes. (The words are loaded for a reason, btw.)

I'm coming from a language (Scala) where it took almost 15 years to recognize that Haskell isn't anything that should be imitated. Now that most people there start to get it people elsewhere start to fall for the exact same fallacy. But this time this could become so big that this will end up like the "OOP dark ages" which we're just about to finally leave. People are seemingly starting to replace one religion with the other. This won't make anything better… It's just equally stupid. It makes no difference whether you replace one "hammer" with another but still pretend that everything is a nail.

[deltasevennine]

You did argue for everything is the same. Basically by "same" I mean everything is "equally good" depending on context. The whole hammers are for hammering and screwdrivers are for screwing thing... I explicitly said your argument was that everything was a tool in a toolbox and you exactly replicated what I said.

My point is: something can be truly bad and something can be truly good EVEN when considering all possible contexts.

You can't prove definitively whether this is the case for FP or OOP or any programming style for that matter. You can't know whether someones "side" is a cargo cult or not when there's no theoretical way for measuring this.

The cultish following may even be correct in the same way I cargo cult my belief that the world is ROUND and not flat.

[still_grokking]

> My point is: something can be truly bad and something can be truly good EVEN when considering all possible contexts.

No, that's impossible. "Truly good" or "truly bad" are moral categories. Something closely related to religion, BTW…

> You can't know whether someones "side" is a cargo cult […]

Of course I can.

If it objectively makes no sense (in some context), and is only blindly copied from somewhere else without understanding why there things were done the way they were done, this is called "cargo cult". That's the definition of this term.

How can I tell whether there is no understanding behind something? If the cultists would understand what they are actually copying they wouldn't copy it at all. ;-)

Replacing methods with free standing functions is for example on of such things: In Haskell there are no methods. So free standing functions are all you have. But imitating this style in a language with methods makes no sense at all! It complicates things for no reason. This is obviously something where someone does not understand why Haskell is like it is. They just copy on the syntax level something that they think is "functional programming". But surface syntax should not be missed for the actual concepts! Even it's easy to copy the syntax instead of actually adapting the ideas behind it (only where it makes sense of course!).

[deltasevennine]

>No, that's impossible. "Truly good" or "truly bad" are moral categories. Something closely related to religion, BTW…

Wrong. Good and bad is used in a fuzzy way here, I'm OBVIOUSLY not talking about morality OR religion. What I am talking about are things that can be potentially quantified to a formal theory. For example we know the shortest distance between two points is a line. We have formalized algorithmic speed with computational complexity theory. O(N) is definitively more "good" then O(N^2).

Right now we don't have optimization theory or formal definitions on logic organization. We can't quantify it so we resort to opinionated stuff. And the whole thing goes in circles. But that is not to say this is impossible to formalize. We just haven't yet so all arguments go nowhere. But the shortest distance between two points? Nobody argues about that (I hope some pedantic person doesn't bring up non-euclidean geometry because come on).

All we can say right now is because there is no theory, nothing definitive can be said.

>Of course I can. >If it objectively makes no sense (in some context), and is only blindly copied from somewhere else without understanding why there things were done the way they were done, this is called "cargo cult". That's the definition of this term.

You can't. The definition of bias is that the person who is biased is unaware of it. You can talk with every single religious person in the world. They all think they arrived at their beliefs logically. Almost everyone thinks the way they interpret the world is logical and consistent and it makes sense. They assume everyone else is wrong.

To be truly unbiased is to recognize the possibility of your own fallibility. To assume that your point of view is objective is bias in itself. You ask those people who "blindly" copy things if they did it blindly, they will tell you "No." They think they're conclusions are logical they don't think they're blind. The same way you don't think your blind, the same way I don't think I'm blind. All blind people point at other blind people and say everyone else is blind except for them.

The truly unbiased person recognizes the possibility of their own blindness. But almost nobody thinks this way.

Nobody truly knows who is blind and who is not. So they argue endlessly and present factoids to each other like this one here you just threw at me:

"Replacing methods with free standing functions is for example on of such things: In Haskell there are no methods. So free standing functions are all you have. But imitating this style in a language with methods makes no sense at all! It complicates things for no reason. This is obviously something where someone does not understand why Haskell is like it is. They just copy on the syntax level something that they think is "functional programming". But surface syntax should not be missed for the actual concepts! Even it's easy to copy the syntax instead of actually adapting the ideas behind it (only where it makes sense of course!)."

I mean how do you want me to respond to this factoid? I'll throw out another factoid:

Forcing people to use methods complicates things for no reason. Why not just have state and logic separated? Why force everything into some horrible combination? If I want to use my method in another place I have to bring all the state along with it. I can't move my logic anywhere because it's tied to the contextual state. The style of the program itself is a weakness and that's why people imitate another style.

And boom. What are you gonna do? Obviously throw another factoid at me. We can pelt each other with factoids and the needle doesn't move forward at all.

[hutzlibu]

"You did argue for everything is the same."

I do not see where he did that. He argued simply that context matters. (And yes a "bad" tool can be the right tool, if it is the only tool avaiable.)

"My point is: something can be truly bad and something can be truly good EVEN when considering all possible contexts."

And diving deeper into philosophy here, can you name one example?

[0xdeadbeefbabe]

Not deltasevennine, but giving the CPU fewer things to do sounds good to me (in any context), even if it is currently unpopular. Some cults are popular and some aren't.

[deltasevennine]

>I do not see where he did that. He argued simply that context matters. (And yes a "bad" tool can be the right tool, if it is the only tool avaiable.)

Well I see it. If you don't see it, I urge you to reread what he said.

A bad tool can be the right tool but some tools are so bad that it is never the right tool.

>And diving deeper into philosophy here, can you name one example?

Running is better then walking for short distances when optimizing for shorter time. In this case walking is definitively "bad." No argument by anyone.

Please don't take this into a pedantic segway with your counter here.

[_gabe_]

> I believe the world is round

This isn't an opinion or a belief, it's a verifiable fact. We know the world is round because: if you travel east you'll eventually arrive at your starting destination; if you stand on a ship's crow's nest you can see further than the crew on the deck because of the curvature of the earth; if you fly a plane and make two 90 degree turns and travel an equal distance, you will end up at your starting point due to the curvature of the earth; if you go to space in a space station, you can visually verify that the earth is round.

Cargo culting acolytes will believe the earth is round with no explanation as to why. Just because you believe the right thing doesn't mean you're not cargo culting. If you can't explain why you believe what you believe, you're simply believing to follow a particular crowd, regardless of the validity of the belief.

[deltasevennine]

Sure.

I simply use this "world" example because everyone here is in the same cult as me: "The world is round cult." When I use it, they get it. If I were speaking to a different cult, I would use a different example.

You will note, both flat earthers and non-flat earthers have very detailed and complex reasoning for why they "believe" what they believe. But of course most members of either group have Not actually went to space to verify the conclusions for themselves.

[_gabe_]

My point was most people do cargo cult and that's bad, no matter what. And the notion that you have to go to space to know the earth is round is flawed, as I tried to illustrate using several examples that didn't necessitate traveling to space to infer that the earth is not flat.

After all, Eratosthenes was able to calculate the circumference of the earth with approximately 0.5% margin of error[0]. Since they didn't have rockets in 250 B.C, it should be clear that there are other empirical methods to test these hypotheses.

To reiterate, cargo culting is always bad. If you don't have a reason for what you believe, then there's a chance your belief is flawed and it would behoove you to research your question and prove to yourself the validity or invalidity of your belief.

[0]: https://oceanservice.noaa.gov/education/tutorial_geodesy/geo...

[deltasevennine]

Yeah I get it. But What I'm saying is that there are many times when nobody can truly prove which whether they're in the cargo cult or the other people are in the cargo cult.

So programming is one such thing. There are stylistic camps everywhere and nobody knows which one is the cargo cult, INCLUDING the neutral camp where people say everything is a tool depending on the context.

[AnimalMuppet]

Nope. You're the one who isn't listening or understanding. still_grokking's point is that even if one approach is better than the other, a slavish cargo-cult adherence to that approach will still produce bad results.

[still_grokking]

Thanks! Couldn't say this better.

I'm not arguing about the approaches as such, I've stated that cargo culting around any of them is a bad thing by itself.

Blindly imitating something for which you didn't fully grasp all pros and cons will at best not help you and in most cases make things worse.

[deltasevennine]

Nope. You aren't listening to me. I am getting exactly what he's saying. What I am saying is that the cargo culters could be right. You don't know. Nobody knows.

Additionally he DID say that the approaches were all tools in a toolbox.

[awgm]

yeah but sometimes its useful to use a flat earth model when for instance the ground youre going to build something like a shed on is relatively flat. in the big picture sense i agree but in different contexts an alternative abstract model can suffice and actually be more efficient if the aim is to build the shed in this case

[hnfong]

Software engineering is mostly a practical discipline. Religions are bad if dogma trump practical concerns.