4 ms·

> rather than being able to process any given object or objects of different types Not necessarily- the functions can still be polymorphic. Rust does a particu

> rather than being able to process any given object or objects of different types 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)

jemmyw 4y ago
I'm familiar with rust but not with Julia. One pitfall I can see with calling this method chaining style functional is that you might not be aware of when a mutation occurred. For example, I've made the mistake before of calling .sort() in js on an array chain and it mutates in place, which you don't really expect given the other methods. At least rust makes this explicit.
- brundolf 4y ago
  > you might not be aware of when a mutation occurred 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
- Hasnep 4y ago
  Julia has the convention that mutating functions have names that end with a bang, e.g. sort(x) returns the sorted object, but sort!(x) returns a "nothing" and mutates the object in place.
  - TchoBeer 4y ago
    iirc this is notation that they adopted from rust.
    - Jtsummers 4y ago
      More likely Scheme. Scheme used the ! signifier to indicate that something was being mutated. For instance `vector-copy` returns a fresh copy, `vector-copy!` copies into another vector, changing it.
      - TchoBeer 4y ago
        Whether Julia took it from Rust or Scheme, or Rust took it from Scheme or Scheme took it from somewhere else, my point was that Julia did not invent this notation (this kinda sounds like an insult but it's actually not at all), and it's just a notation common a lot of functional-ish languages that allow mutation.
        Jtsummers 4y ago
        We are in agreement that Julia is not the origin of ! for this, I was just pointing out that if you want a historical take (what influenced what), Julia most likely got it from Scheme (whether it originated in Scheme or not is immaterial). Rust doesn't use ! to signify "This is a mutating function", it uses it to signify "This is a macro". Whereas Julia and Scheme use it as an indicator for the same thing: functions that modify their arguments. And Julia is known to have been influenced by Scheme, which existed when Julia's development started while Rust (publicly) did not.
      - kaba0 4y ago
        I’m fairly sure Ruby predates both of these languages by a lot and it does use the ! notation for similar things.
    - brundolf 4y ago
      In rust ! signifies invoking a macro, so it couldn't be used like this in a function name even if you wanted to. Also, Rust allows you to notate immutable/mutating/owning for each individual argument type, so there wouldn't be much point: fn do_thing(a_owned: Foo, b_mutating: &mut Foo, c_immutable: &Foo) { There is a convention to separate the two kinds of functions (consume and return in some, mutate in others), but that's the only commonality
sideeffffect 4y ago
> 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/6xtg3e/what_if_anything_is_a_programming_paradigm_robert/ 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.
- valenterry 4y ago
  That's not really true. Yeah, the term "FP" has been watered down but there was a proper definition: "FP is whene every expression of a program is referential transparent" and that's it. (https://en.wikipedia.org/wiki/Referential_transparency https://en.wikipedia.org/wiki/Referential_transparency) 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.
  - kazinator 4y ago
    How do you define named functions in something that is referentially transparent? Can a function-defining expression be transparently replaced with the value it computes?
    - valenterry 4y ago

jemmyw 4y ago

I'm familiar with rust but not with Julia. One pitfall I can see with calling this method chaining style functional is that you might not be aware of when a mutation occurred. For example, I've made the mistake before of calling .sort() in js on an array chain and it mutates in place, which you don't really expect given the other methods. At least rust makes this explicit.

brundolf 4y ago
> you might not be aware of when a mutation occurred 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
Hasnep 4y ago
Julia has the convention that mutating functions have names that end with a bang, e.g. sort(x) returns the sorted object, but sort!(x) returns a "nothing" and mutates the object in place.
- TchoBeer 4y ago
  iirc this is notation that they adopted from rust.
  - Jtsummers 4y ago
    More likely Scheme. Scheme used the ! signifier to indicate that something was being mutated. For instance `vector-copy` returns a fresh copy, `vector-copy!` copies into another vector, changing it.
    - TchoBeer 4y ago
      Whether Julia took it from Rust or Scheme, or Rust took it from Scheme or Scheme took it from somewhere else, my point was that Julia did not invent this notation (this kinda sounds like an insult but it's actually not at all), and it's just a notation common a lot of functional-ish languages that allow mutation.
      - Jtsummers 4y ago
        We are in agreement that Julia is not the origin of ! for this, I was just pointing out that if you want a historical take (what influenced what), Julia most likely got it from Scheme (whether it originated in Scheme or not is immaterial). Rust doesn't use ! to signify "This is a mutating function", it uses it to signify "This is a macro". Whereas Julia and Scheme use it as an indicator for the same thing: functions that modify their arguments. And Julia is known to have been influenced by Scheme, which existed when Julia's development started while Rust (publicly) did not.
    - kaba0 4y ago
      I’m fairly sure Ruby predates both of these languages by a lot and it does use the ! notation for similar things.
  - brundolf 4y ago
    In rust ! signifies invoking a macro, so it couldn't be used like this in a function name even if you wanted to. Also, Rust allows you to notate immutable/mutating/owning for each individual argument type, so there wouldn't be much point: fn do_thing(a_owned: Foo, b_mutating: &mut Foo, c_immutable: &Foo) { There is a convention to separate the two kinds of functions (consume and return in some, mutate in others), but that's the only commonality

sideeffffect 4y ago

> 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/6xtg3e/what_if_anything_is_a_programming_paradigm_robert/ 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.

valenterry 4y ago
That's not really true. Yeah, the term "FP" has been watered down but there was a proper definition: "FP is whene every expression of a program is referential transparent" and that's it. (https://en.wikipedia.org/wiki/Referential_transparency https://en.wikipedia.org/wiki/Referential_transparency) 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.
- kazinator 4y ago
  How do you define named functions in something that is referentially transparent? Can a function-defining expression be transparently replaced with the value it computes?
  - valenterry 4y ago