Difference between functional style and functional language?
Not necessarily- the functions can still be polymorphic. Rust does a particularly cool thing here, where any struct or trait method can be called in non-method syntax (or even passed as a first-class function!). I believe Julia also has type-based polymorphism while still being considered a functional-adjacent programming language. And then there are other languages where any function in scope can be called in method syntax, without being explicitly associated with the value's type (there's a name for this feature but I can't remember it)
> Difference between functional style and functional language?
I don't know the precise definitions well enough to distinguish them (though I'm not sure they have precise definitions)
Of course they don't. These "paradigms" like OOP or FP are just human made up terms _without any basis in theory_. Sometimes they can be practically useful when communicating with other humans, like we do now. But more and more people are starting to realize how meaningless/nonsensical these categorizations are (and always have been): FP vs OOP, compiled vs interpreted, static vs dynamic, etc. We might as well categorize languages based on the colour of their mascot.
See this for more https://old.reddit.com/r/ProgrammingLanguages/duplicates/6xt...
The closest thing to the definition of an FP language that I was able to come up with is "based on the Lambda calculus". Haskell is, Scheme is, F# is. But e.g. Scala isn't, it's fundamental building block isn't functions but objects. But many people do consider Scala to be an FP language.
So let's all be aware of the limitations of these (pseudo-)concepts.
In other words, this is not even a property of a programming language. It is a property of the code itself. It's just that some languages make it easy or impossible to build a program in that style - or they even enforce it. Haskell however has escape hatches. And Scala is considered an FP language because, unlike Javascript/Lisp/Clojure/ML/Rust/... it really allows and supports(!) to make the whole program referential transparent.
Yeah, this is a risk with any language that mixes some functional features/style in with non-functional features. Rust does a pretty good job of letting you mostly delineate the two, though there are still escape-hatches
I've actually been toying with a language design that has both, but draws a hard distinction between them. We'll see how it works out :)
But most of the time, if you're not using a totally pure functional language, functional programming is more a practice/style/ethos/feature-set than a hard constraint
sort(x)
sort!(x)
On the contrary, this helps with modularity, which is a good thing. You can then swap out the object for another object with the same interface, but where the functions (methods) have different implementations.
That is about name-scope. You can refer to your own method simply by its name via 'this', and when you call it you know it can access the state inside that particular object.
Without 'this' an object in JavaScript and other OOP languages could not access its own properties including it (possibly mutable) state.
Is there an equivalent to 'this' in purely FP languages?
Bundling data and functions has pros and cons but has nothing to do with functional programming it.
Also, there isn't really a good definition for either functional style or functional language. If anything, there is a good definition for pure functional programming, but that's another beast alltogether and still is orthogonal to bundling data and functions.