Readit NewsI think you miss the whole point of this website!
I've had never before to flag here something. Now you force me to do it again. That makes me really sad right now.
But you're constantly only trolling. Continue elsewhere, please.
What I said was true. You were going off on tangents. It's the only logical conclusion.
Well, if you think so, then consider yourself the tautological winner.
Dead Comment
Yeah, but then the context is optimizing for shorter time. You said context does not matter. But it always does. And depending on the greater context, there would be plenty of examples where running is not adequate, even when optimizing for short time, because maybe you don't want to raise attention, you don't want to be sweaty when you reach the goal, or then your knee would hurt again, etc.
Is this pedantic, well yes, but if you make absolutistic statements then this is what you get.
But again, no one here ever said, it is all the same. It was said that it is always about context, to which I agree.
When you only have a low quality tool avaiable, or your people only trained in that low quality tool(and no time to retrain), than this is still the right tool for the job.
I made an absolutist statement which is definitely true. You failed to prove it wrong. Instead you had to do the pathetic move of redefining the statement in order to get anywhere. You weren't pedantic, you changed the entire subject with your redefinition.
As for context I am saying I can make absolute statement about things and this statement is true for all contexts.
My point for this entire thread is that I can say OOP is horrible for all contexts and this statement cannot be proven wrong. Neither can the statement OOP is good for all contexts or OOP is good for some contexts. All of these statements are biased.
If you were to be pedantic here you would be digging into what context means. You might say if the context was that everyone was trained on OOP and not fp then oop is the superior choice. To which I respond by context I mean contexts for practical consideration. If you can't figure out what set of contexts lives in that set for "practical consideration" then you are just too pedantic of a person for me to have a reasonable conversation with.
There are shit paradigms out there, shit design patterns and shit programming languages. But without proof this is an endless argument. You can't prove your side either, you're just going to throw me one off examples to which I can do the same. No point. I'm sorry but let's end it here, I don't want to descend further into that rabbit hole of endless qualitative arguments.
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.
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.
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.
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.
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?
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.
No, it doesn't.
All functions are in fact objects and most are methods in JavaScript, and there is nothing else.
Methods (== properties assigned function object values) are the natural way to express things in JavaScript.
Trying to pretend that this is not the case, and trying really hard to emulate (free) functions (which, to stress this point once more, do not exist in JavaScript) makes on the other hand's side everything more complicated than strictly needed.
> Why not just have state and logic separated?
That's a good idea.
This is also completely orthogonal to the question on how JavaScript is supposed to be used.
JavaScript is a hybrid langue. Part Small Talk, part Lisp.
It's common in JavaScript since inception to separate data (in the form of objects that are serializable to and from JSON) from functionality (in the form of function objects).
JavaScript was never used like Java / C++ / C#, where you glue together data and functionality into classes, and still isn't used like that (nevertheless they've got some syntax sugar called "class" at some point).
> Why force everything into some horrible combination?
Nobody does that. At least not in JavaScript.
Still that does permit to use methods.
Functions themself are objects. Using objects is the natural way for everything in JavaScript as there is nothing else than objects. Everything in JavaScript is an object. And any functionality the language provides is through methods.
Working against the basic principles of a language is a terrible idea! (In every language, btw). It complicates everything for no reason and has horrible code abominations as a consequence.
> If I want to use my method in another place I have to bring all the state along with it.
No, you don't. You need only to bring the data that you want to operate on.
The nice thing is: You get the functionality right at the same place as the data. You don't need to carry around anything besides the data that you work on.
The alternative is needing to bring the modules that carry the functionality that you want to apply to the data you need also to have around… As an example: `items.map(encode)` is nicer to write and read than `List.map items encode`.
You don't need to carry around the `List` module when the method can already be found on the prototype of the data object. Also it's more clear what's the subject and what's the object of the operation.
> I can't move my logic anywhere because it's tied to the contextual state.
That's just not true in JavaScript.
Nothing is easier then passing functions objects around, or change the values of properties that reference such function objects.
JavaScript is one of the most flexible languages out there in this regard!
You can even rewrite built-in types while you process them. (Not that I'm advocating for doing so, but it's possible).
> The style of the program itself is a weakness […]
You did not present any facts that would prove that claim.
> […] that's why people imitate another style.
No, that's not the reason.
You don't need to imitate Haskell when you want to write functional programs in a Lisp derived language… ;-)
People are obviously holding some cargo cult ceremonies when trying to write Haskell in JavaScript.
Your other opinions are based on wrong assumptions. I'm not going into that in detail, but some small remarks:
> For example we know the shortest distance between two points is a line.
In Manhattan¹? ;-)
> O(N) is definitively more "good" then O(N^2).
Maybe it's more "good"…
But it's for sure not always faster, or even more efficient, in reality.
Depending on the question and your resources (e.g. hardware) a brute force solution may be favorable against a solution with a much lower complexity on paper.
Welcome to the physical world. Where practice differs from theory.
> 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).
You don't need to look into non-euclidean geometry.
Actually, even there the shortest distance between two points is a "straight line". Only that the straight line may have some curvature (because of the curved space).
But you didn't even consider that "distance" is actually something² about that one can actually argue…
> You can't. The definition of bias is that the person who is biased is unaware of it.
No, that's not the definition³.
> Nobody truly knows who is blind and who is not.
Nobody truly knows anything.
What's the point?
What was actually the point of your comment, btw?
---
¹ https://en.wikipedia.org/wiki/Taxicab_geometry ² https://en.wikipedia.org/wiki/Distance ³ https://en.wikipedia.org/wiki/Bias
It is, I just worded it differently. See the "cognitive biases" part on your citation. They use "reality" in place of what I mean by "unaware". If you think something incorrect is reality, then you are "unaware" of how incorrect your thinking is, because you think it's reality. These are just pedantic factoids we're throwing at each other.
>What was actually the point of your comment, btw?
The point is that FOR PROGRAMMING, nobody truly knows which camp is the cargo cult. Everyone is blind. Stick with the program.
>Welcome to the physical world. Where practice differs from theory.
This is called pedantism. Like did you really think you're telling me something I'm not aware about? Everyone knows this. But the pedantic details of the optimizations the compiler and the CPU goes through to execute code is besides the point, obviously I'm not referring to this stuff when I'm trying to convey a point.
>In Manhattan¹? ;-)
Your again just being pedantic. I'm perfectly aware of non-euclidean geometry, but you had to go there. I had a point, stick to the point, pedantism is a side track designed to muddy the conversation. Why are you muddying the conversation?
Is it perhaps that you're completely and utterly wrong and you're trying to distract me from that fact?
>Trying to pretend that this is not the case, and trying really hard to emulate (free) functions (which, to stress this point once more, do not exist in JavaScript) makes on the other hand's side everything more complicated than strictly needed.
Bro, my little paragraph arguing against you was just a random factoid. I don't care for your argument and I don't even care for mine. The whole main point is to say that we can endlessly spew this garbage at each other the needle doesn't move forward at all. Nobody can win, because we have no way of establishing an actual winner. Thus with no way of knowing who's right there's no POINT in it.
All I am saying and this is the heart of my argument, is that YOUR topic, your team of "don't be a cargo cult" is no different from all the other teams.
I thought I made that obvious that my factoid was sarcastic, but you fell for that quick and instantly retaliated with your own factoid. Man Not gonna go down that rabbit hole.
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...
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.
"Nothing is true, nothing is false."
No one ever claimed that in this debate, except you.
No personal attack was conducted here. It's just you're sensitive. I mean I could take this: "where you consistently insist of understanding the other side wrong" as an insult.
I could also take this: "Well, if you think so, then consider yourself the tautological winner. " as a sarcastic insult as well.
But i don't. Because I'm not sensitive. Nobody was insulted here. You need to relax. Calling you a loser was just me turning your sarcastic "tautological winner" statement around and showing you how YOU are at the other side of the extreme. I'm not saying you're a "loser" anymore then you were sarcastically calling me a "winner."
Put it this way, the "loser" comment is an insult IF and ONLY if you're "winner" comment was an insult too. If it wasn't we should be good.
>No one ever claimed that in this debate, except you.
You never directly claimed this, but it's the logical consequence of your statements. You literally said my statement was flawed because it was "absolute". You're like "this is what you get when you make absolute claims." And my first thought was, "what on earth is wrong with an absolute claim?" We do not live in a universe where absolute claims are invalid because if we did then "Nothing is true and nothing is false" and everybody loses.
If this isn't the case then go ahead and clarify your points.