6 ms·

do functional languages mainly appeal to computer language enthusiasts/researchers? im just not seeing the benefit personally.

michaelsbradley 3y ago
Do you worry about side-effects that leak beyond the scope of the routines you're authoring? Why / why not?
- globalnode 3y ago
  i do, does functional programming make this a non issue? maybe im just not smart enough to wrap my head around it.
  - andrewflnr 3y ago
    Generally, yes. Some languages are really hardcore about it (notably Haskell), while others just strongly encourage you to write functions without side effects. Ed: that's the "purity" they're talking about in OP. The other major neat thing about functional languages is how they let you treat functions like objects, but most modern programming languages have adopted that as well, so it's not a big differentiator anymore.
  - imoverclocked 3y ago
    Functional languages that require calling out side-effects (eg: "\ IO" in Flix) allow you to write functions that are "pure" (aka: they can do no mutation of data or perform IO) and will always give you the same result for a given input. Writing the majority of your code as pure functions makes the code much easier to reason about, especially as the system scales. IMHO, it also makes testing simpler. It's definitely a different way of thinking and it has a lot of benefits. However, some of the downsides (which Flix seems to fix with region-based local mutation) might be implementing a sort that keeps two copies of a list in memory just to return the second list and discard the first. Depending on your list, this may not be an issue.
  - usrbinbash 3y ago
    Yes and no. In theory, writing in a functional language that allows only "pure" functions (aka. functions w.o. side effects), makes it easier to control state. In practice, side effects exists and are required for programs to do anything useful. In my opinion, one mistake of many purely functional languages was to be so focused on this purity, that it made it needlessly hard to write useful code in them, especially for people coming from an imperative/procedural/oop style of doing things. And you need these people if you want your method to gain traction, because the vast majority of code written, is imperative. The irony is, that FP could probably have had a lot more success if it didn't clamour on about pure functions so much, and was less focused on implementations (aka. languages) than on methodology (aka. coding style) Because it is perfectly possible to write pure functions in most languages, including OOP language, even if those functions are not "pure" internally, or are not "pure" all the time and under all circumstances. And yes, doing so has really nice advantages. I have refactored quite alot of codebases into using a more functional approach, and what I found was that this makes it harder to introduce bugs, makes it easier to track bugs, and makes it easier to reason about my code. So yeah, functional programming, used if and where it makes sense, does work, and is useful.
    - ReleaseCandidat 3y ago
      > The irony is, that FP could probably have had a lot more success if it didn't clamour on about pure functions so much Except functional languages like Lisps and the MLs never were pure, the only (used by a significant number of people) has been Miranda/Haskell (ignoring Coq and the other proof assistents). Or, to put it in other words: ML (no, not that ML) turned 50 this year, Scheme is oder than 50 too and Miranda/Haskell ~36. There never had been a shortage of "impure" functional languages since OOP existed.
      - usrbinbash 3y ago
        Yes, there have. And not a single one of them was able to even gain a sizeable fraction of the mindspace that imperative languages have, let alone replace or obsolete even a single one of them. So maybe it's time for FP as a whole to accept the fact, that there seems to be something fundamental about the way it's paraded implementations look and feel like, that puts off a lot of programmers. Maybe it's time for FP to accept that the paradigm as a whole has a lot to contribute that is useful to everyone, but doesn't need a new language with largely different syntactic constructs to do so.
  - mrkeen 3y ago
    Haskell makes it a compile-time issue. If you declare a function effect-free, and try to perform effects inside it, then you'll get a compiler error. You are still allowed (and it's common practice!) to declare your functions as effectful. Unfortunately the 'signal' of this message is often lost in the noise: For every Haskeller happily writing effects, there's 9 non-Haskellers writing that 'Haskell's big mistake was being pure and not allowing effects - you should use X instead'.
- discreteevent 3y ago
  I don't worry about side effects because in practice they don't cause me many problems (although I do focus on isolating mutable state). But if I thought about it a lot then I might start to worry about the theoretical possibilities. So I think the question is well phrased. "Worry" is mainly psychological. Other advantages of pure FP might be thread safety but queues take care of most of this (and often locks are not hard to use). Or low-level compositionality. But as Alan Kay said, what we need are bigger objects. John Ousterhout seems to agree. Re-use in the small increases complexity.
  - mrkeen 3y ago
    > I don't worry about side effects because in practice they don't cause me many problems You've selected for the work that you already do. If you wanted to use transactions, you'd find them impossible, give up and go back to not having transactions. And once you give up on the impossible dream of transactions, you're back to no problems in practice.
usrbinbash 3y ago
Functional Programming was, for a long time, talked about as yet-another-solution to solve the issue of complexity in larger codebases, primarily the complexity of controlling state getting out o hand. Similar to OOP, which promised to do this by encapsulating state, FP promised to do this via purity, aka. getting rid of as much state as possible, and only allowing stateful transition at certain well defined sections of the program. The "market advantage" of OOP was that, via Java, it was already so well established, and so many coders had been trained in OOP languages, that it remained alive. FP on the other hand, coming out of academia and requiring all these industry people to suddenly do things in syntactically and conceptually different ways, never really gained traction. OOP simply came first, it is as simple as that. Whether FP would have actually solved the problem is anyones guess, since it never gained the traction of OOP and Procedural languages. My best guess is that it wouldn't, because I don't believe in silver bullets. It should be noted that both approaches contributed valueable things to contemporary languages. E.g. first order functions being the norm comes from FP.
- brabel 3y ago
  > OOP simply came first Not really. Lisp is a functional programming language and has existed since at least 1960. Some claim there were many other proto-functional languages since the early 60's, and the FP language [1] (a clearly functional programming language and the result of the famous paper "Can Programming Be Liberated From the von Neumann Style?") appeared in 1977 - was inspired by much earlier efforts like APL. OOP really only became a thing with Simula in 1967, but was not popular until the 1980's with Smalltalk and Common Lisp's Object System (CLOS) came about (so yes, there was a OOP/FP hybrid already decades ago), and then C++ and finally Java much later... at which time Functional Programming languages already included Miranda (1985) which later evolved into Haskell, and Erlang (1986). That is, FPP languages were at least as common as OOP languages by the 80's. As far as I know, however, pure functional languages were not really very efficient until Haskell came about, while OOP languages were nearly on par with procedural style: which mattered a lot in 1980's machines. [1] https://en.wikipedia.org/wiki/FP_(programming_language) https://en.wikipedia.org/wiki/FP_(programming_language)
  - 3y ago
troupo 3y ago
You need a pragmatic combination of functional and non-functional. Many functional zealots aim for a purity beyond all reason and comprehension. When what you really want is something like Erlang/Elixir or even C#.
- sureglymop 3y ago
  What you want is something like Kotlin.
  - karmakaze 3y ago
    I would say F# or OCaml, or Flix as we see here--this language may not be for you.
kaba0 3y ago
Functional programming “won” in terms of getting many of their features implemented into mainstream programming languages. This is a paradigm, it doesn’t require 100% pure usage. It allows for additional safety in parallel contexts.
ben0x539 3y ago
I think for me the appeal is that just that all the big brain programming language research seems to happen in weird new functional languages. I assume they're just a better petri dish for experimenting with weird shit, or maybe they come up with all the weird shit to be able to get things done in the Haskell-du-jour, or maybe weird shit just gets branded as functional programming by default. (These days the fp people always talk about linear types, or effects, or other things that don't seem to involve functions at all, idk what's up with that...) I assume that all of this gets funding because ten years later it makes C# programmers more productive, not because of mass appeal.
ww520 3y ago
Unpopular opinion, functional programming style got a big push because the inability of languages and compilers to deal with state especially mutable state, so they bring out the purity big gun and ban all mutable states. However, state and mutable state are natural and useful for programmers to work with, thus functional programming never gains mainstream. With the advance of lifetime analysis, mutable value semantics, and local mutability, there’s no need to ban mutable state outright. The push for functional programming will be waning in regarding to purity.

michaelsbradley 3y ago

Do you worry about side-effects that leak beyond the scope of the routines you're authoring? Why / why not?

globalnode 3y ago
i do, does functional programming make this a non issue? maybe im just not smart enough to wrap my head around it.
- andrewflnr 3y ago
  Generally, yes. Some languages are really hardcore about it (notably Haskell), while others just strongly encourage you to write functions without side effects. Ed: that's the "purity" they're talking about in OP. The other major neat thing about functional languages is how they let you treat functions like objects, but most modern programming languages have adopted that as well, so it's not a big differentiator anymore.
- imoverclocked 3y ago
  Functional languages that require calling out side-effects (eg: "\ IO" in Flix) allow you to write functions that are "pure" (aka: they can do no mutation of data or perform IO) and will always give you the same result for a given input. Writing the majority of your code as pure functions makes the code much easier to reason about, especially as the system scales. IMHO, it also makes testing simpler. It's definitely a different way of thinking and it has a lot of benefits. However, some of the downsides (which Flix seems to fix with region-based local mutation) might be implementing a sort that keeps two copies of a list in memory just to return the second list and discard the first. Depending on your list, this may not be an issue.
- usrbinbash 3y ago
  Yes and no. In theory, writing in a functional language that allows only "pure" functions (aka. functions w.o. side effects), makes it easier to control state. In practice, side effects exists and are required for programs to do anything useful. In my opinion, one mistake of many purely functional languages was to be so focused on this purity, that it made it needlessly hard to write useful code in them, especially for people coming from an imperative/procedural/oop style of doing things. And you need these people if you want your method to gain traction, because the vast majority of code written, is imperative. The irony is, that FP could probably have had a lot more success if it didn't clamour on about pure functions so much, and was less focused on implementations (aka. languages) than on methodology (aka. coding style) Because it is perfectly possible to write pure functions in most languages, including OOP language, even if those functions are not "pure" internally, or are not "pure" all the time and under all circumstances. And yes, doing so has really nice advantages. I have refactored quite alot of codebases into using a more functional approach, and what I found was that this makes it harder to introduce bugs, makes it easier to track bugs, and makes it easier to reason about my code. So yeah, functional programming, used if and where it makes sense, does work, and is useful.
  - ReleaseCandidat 3y ago
    > The irony is, that FP could probably have had a lot more success if it didn't clamour on about pure functions so much Except functional languages like Lisps and the MLs never were pure, the only (used by a significant number of people) has been Miranda/Haskell (ignoring Coq and the other proof assistents). Or, to put it in other words: ML (no, not that ML) turned 50 this year, Scheme is oder than 50 too and Miranda/Haskell ~36. There never had been a shortage of "impure" functional languages since OOP existed.
    - usrbinbash 3y ago
      Yes, there have. And not a single one of them was able to even gain a sizeable fraction of the mindspace that imperative languages have, let alone replace or obsolete even a single one of them. So maybe it's time for FP as a whole to accept the fact, that there seems to be something fundamental about the way it's paraded implementations look and feel like, that puts off a lot of programmers. Maybe it's time for FP to accept that the paradigm as a whole has a lot to contribute that is useful to everyone, but doesn't need a new language with largely different syntactic constructs to do so.
- mrkeen 3y ago
  Haskell makes it a compile-time issue. If you declare a function effect-free, and try to perform effects inside it, then you'll get a compiler error. You are still allowed (and it's common practice!) to declare your functions as effectful. Unfortunately the 'signal' of this message is often lost in the noise: For every Haskeller happily writing effects, there's 9 non-Haskellers writing that 'Haskell's big mistake was being pure and not allowing effects - you should use X instead'.
discreteevent 3y ago
I don't worry about side effects because in practice they don't cause me many problems (although I do focus on isolating mutable state). But if I thought about it a lot then I might start to worry about the theoretical possibilities. So I think the question is well phrased. "Worry" is mainly psychological. Other advantages of pure FP might be thread safety but queues take care of most of this (and often locks are not hard to use). Or low-level compositionality. But as Alan Kay said, what we need are bigger objects. John Ousterhout seems to agree. Re-use in the small increases complexity.
- mrkeen 3y ago
  > I don't worry about side effects because in practice they don't cause me many problems You've selected for the work that you already do. If you wanted to use transactions, you'd find them impossible, give up and go back to not having transactions. And once you give up on the impossible dream of transactions, you're back to no problems in practice.

usrbinbash 3y ago

Functional Programming was, for a long time, talked about as yet-another-solution to solve the issue of complexity in larger codebases, primarily the complexity of controlling state getting out o hand. Similar to OOP, which promised to do this by encapsulating state, FP promised to do this via purity, aka. getting rid of as much state as possible, and only allowing stateful transition at certain well defined sections of the program. The "market advantage" of OOP was that, via Java, it was already so well established, and so many coders had been trained in OOP languages, that it remained alive. FP on the other hand, coming out of academia and requiring all these industry people to suddenly do things in syntactically and conceptually different ways, never really gained traction. OOP simply came first, it is as simple as that. Whether FP would have actually solved the problem is anyones guess, since it never gained the traction of OOP and Procedural languages. My best guess is that it wouldn't, because I don't believe in silver bullets. It should be noted that both approaches contributed valueable things to contemporary languages. E.g. first order functions being the norm comes from FP.

brabel 3y ago
> OOP simply came first Not really. Lisp is a functional programming language and has existed since at least 1960. Some claim there were many other proto-functional languages since the early 60's, and the FP language [1] (a clearly functional programming language and the result of the famous paper "Can Programming Be Liberated From the von Neumann Style?") appeared in 1977 - was inspired by much earlier efforts like APL. OOP really only became a thing with Simula in 1967, but was not popular until the 1980's with Smalltalk and Common Lisp's Object System (CLOS) came about (so yes, there was a OOP/FP hybrid already decades ago), and then C++ and finally Java much later... at which time Functional Programming languages already included Miranda (1985) which later evolved into Haskell, and Erlang (1986). That is, FPP languages were at least as common as OOP languages by the 80's. As far as I know, however, pure functional languages were not really very efficient until Haskell came about, while OOP languages were nearly on par with procedural style: which mattered a lot in 1980's machines. [1] https://en.wikipedia.org/wiki/FP_(programming_language) https://en.wikipedia.org/wiki/FP_(programming_language)
- 3y ago

troupo 3y ago

You need a pragmatic combination of functional and non-functional. Many functional zealots aim for a purity beyond all reason and comprehension. When what you really want is something like Erlang/Elixir or even C#.

sureglymop 3y ago
What you want is something like Kotlin.
- karmakaze 3y ago
  I would say F# or OCaml, or Flix as we see here--this language may not be for you.

kaba0 3y ago

Functional programming “won” in terms of getting many of their features implemented into mainstream programming languages. This is a paradigm, it doesn’t require 100% pure usage. It allows for additional safety in parallel contexts.

ben0x539 3y ago

I think for me the appeal is that just that all the big brain programming language research seems to happen in weird new functional languages. I assume they're just a better petri dish for experimenting with weird shit, or maybe they come up with all the weird shit to be able to get things done in the Haskell-du-jour, or maybe weird shit just gets branded as functional programming by default. (These days the fp people always talk about linear types, or effects, or other things that don't seem to involve functions at all, idk what's up with that...) I assume that all of this gets funding because ten years later it makes C# programmers more productive, not because of mass appeal.

ww520 3y ago

Unpopular opinion, functional programming style got a big push because the inability of languages and compilers to deal with state especially mutable state, so they bring out the purity big gun and ban all mutable states. However, state and mutable state are natural and useful for programmers to work with, thus functional programming never gains mainstream. With the advance of lifetime analysis, mutable value semantics, and local mutability, there’s no need to ban mutable state outright. The push for functional programming will be waning in regarding to purity.