3 ms·

The AdvantagesOfFunctionalProgramming - https://wiki.c2.com/?AdvantagesOfFunctionalProgramming https://wiki.c2.com/?AdvantagesOfFunctionalProgramming has incre

The AdvantagesOfFunctionalProgramming - https://wiki.c2.com/?AdvantagesOfFunctionalProgramming https://wiki.c2.com/?AdvantagesOfFunctionalProgramming has increasingly become to sound hollow or misleading, insofar as the properties and abilities described were solely found in "functional" languages of the time rather than being inherent benefits. > Most functional languages provide a nice, protected environment, somewhat like JavaLanguage. So Java, which isn't functional, provides a relatively "protected" environment. So what does "protected" mean and what does this have to do with functional languages again? > FP encourages safe ways of programming Depends on syntax and features. Only allowing one true way or providing one true api, is equivalent. > Functional programs tend to be much more terse The terseness can contain complicated subtlety. Up to the developer to read it carefully. Non-obviousness isn't a good thing and a level of verbose expression seems to be beneficial. > FP encourages quick prototyping Nope. > FP is modular in the dimension of functionality Not unique. etc etc etc The common assertions about having no-side effects are interesting because I was lured by this when I was younger. Sadly, there are always side effects, even if it's just resource usage or output to some device. The idea of limiting side effects is simple to achieve through modern language "static" functions and other mechanisms to the same degree. Has it made functional languages more popular/valuable or javascript (which has no such mechanism) less? blah blah blah.

nesarkvechnep 5y ago
I get aggressive when someone says “no side effects in functional programming”. There are always side effects but in pure FP they’re tracked and controlled.
lmm 5y ago
> Only allowing one true way or providing one true api, is equivalent. Only if that one true way is safe. I'd argue that hidden mutable state (which is the essence of non-functional programming) is inherently unsafe - non-threadsafe by default and, even more dangerously, confusing to the reader by default. > The terseness can contain complicated subtlety. Maybe it "can", but usually the terseness just comes from removing pointless clutter. > a level of verbose expression seems to be beneficial. Citation needed. > Sadly, there are always side effects, even if it's just resource usage or output to some device. Right, but you can isolate and control them, separate them from your business logic. > The idea of limiting side effects is simple to achieve through modern language "static" functions and other mechanisms to the same degree. No it isn't - if it were then we'd see non-functional languages that had effective control of side effects, and we don't.
- Supermancho 5y ago
  > a level of verbose expression seems to be beneficial. Quorumlang did studies on this. Brainfuck is a sufficient example. > Maybe it "can", but usually the terseness just comes from removing pointless clutter. Abstraction is not clutter. FP adds new abstractions which have variable syntax across languages or even within the same language. >> The idea of limiting side effects is simple to achieve through modern language "static" functions and other mechanisms to the same degree. > No it isn't - if it were then we'd see non-functional languages that had effective control of side effects, and we don't. This is circular logic. Languages would use FP if they saw the value because FP is worth using. A program can be written in a conceptually non-fp language, that is composed of functions without side effect. Practically, this has no advantage, so no effort is put into going farther in that direction with the syntax. > I'd argue that hidden mutable state (which is the essence of non-functional programming) is inherently unsafe - non-threadsafe by default and, even more dangerously, confusing to the reader by default. I know side effects are a feature that can be managed, but this requires discipline. People try FP-centric languages, but unless someone pays them, generally people stay away from it except in spurts (eg map, fluent chaining, etc). This should give some pause, as to what that means. GL with whatever.
  - lmm 5y ago
    > Brainfuck is a sufficient example. How so? It's both very verbose and not very maintainable. > Abstraction is not clutter. Most of the overhead in non-functional languages is not abstraction. > FP adds new abstractions which have variable syntax across languages or even within the same language. What are you talking about? Generally FP languages have less special-case syntax and less special-case concepts, e.g. fewer control flow keywords, exceptions are less prominent, coroutines don't use special keywords or new concepts, mutable variables aren't needed.... I guess do notation is more common in functional languages, but it's a very lightweight piece of syntax sugar that obviates a bunch of what would be special-case syntax in less functional languages: http://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ http://philipnilsson.github.io/Badness10k/escaping-hell-with... . > A program can be written in a conceptually non-fp language, that is composed of functions without side effect. Static doesn't mean side-effect free, and a binary distinction between "side effect" and "not side effect", while somewhat useful, is very crude. But the biggest issue is that it's not practical to write without side effects unless the language's standard library, ecosystem, and most of all culture support it. > People try FP-centric languages, but unless someone pays them, generally people stay away from it except in spurts (eg map, fluent chaining, etc). This should give some pause, as to what that means. On the contrary, popular programming culture creeps slowly in the FP direction every year. Five or ten years ago map was some wacky far-out functional thing.
pjmlp 5y ago
Having learned FP when what we had available was Lisp, Caml Light and Standard ML with Miranda on the horizon, for me the whole "no side effects" is cargo cult from Haskell curch followers that took over the meaning of FP.
kaba0 5y ago
I do find pureness a great feature. While I agree that many things are not unique to FP, or can be easily incorporated into multiparadigm languages, I think having a compiler-enforced “pure” keyword for example would benefit traditional OOP/imperative languages as well. E.g. C would not have to do ugly compiler hacks making common functions like strlen a macro so that the compiler can hoist it out from a for loops conditional for example. Currently they can only assume it through hacks or through inlining. Of course “pure” functions will have memory/CPU overhead, but that is inevitable. Perhaps you would prefer idempotent and memoizable?

nesarkvechnep 5y ago

I get aggressive when someone says “no side effects in functional programming”. There are always side effects but in pure FP they’re tracked and controlled.

lmm 5y ago

> Only allowing one true way or providing one true api, is equivalent. Only if that one true way is safe. I'd argue that hidden mutable state (which is the essence of non-functional programming) is inherently unsafe - non-threadsafe by default and, even more dangerously, confusing to the reader by default. > The terseness can contain complicated subtlety. Maybe it "can", but usually the terseness just comes from removing pointless clutter. > a level of verbose expression seems to be beneficial. Citation needed. > Sadly, there are always side effects, even if it's just resource usage or output to some device. Right, but you can isolate and control them, separate them from your business logic. > The idea of limiting side effects is simple to achieve through modern language "static" functions and other mechanisms to the same degree. No it isn't - if it were then we'd see non-functional languages that had effective control of side effects, and we don't.

Supermancho 5y ago
> a level of verbose expression seems to be beneficial. Quorumlang did studies on this. Brainfuck is a sufficient example. > Maybe it "can", but usually the terseness just comes from removing pointless clutter. Abstraction is not clutter. FP adds new abstractions which have variable syntax across languages or even within the same language. >> The idea of limiting side effects is simple to achieve through modern language "static" functions and other mechanisms to the same degree. > No it isn't - if it were then we'd see non-functional languages that had effective control of side effects, and we don't. This is circular logic. Languages would use FP if they saw the value because FP is worth using. A program can be written in a conceptually non-fp language, that is composed of functions without side effect. Practically, this has no advantage, so no effort is put into going farther in that direction with the syntax. > I'd argue that hidden mutable state (which is the essence of non-functional programming) is inherently unsafe - non-threadsafe by default and, even more dangerously, confusing to the reader by default. I know side effects are a feature that can be managed, but this requires discipline. People try FP-centric languages, but unless someone pays them, generally people stay away from it except in spurts (eg map, fluent chaining, etc). This should give some pause, as to what that means. GL with whatever.
- lmm 5y ago
  > Brainfuck is a sufficient example. How so? It's both very verbose and not very maintainable. > Abstraction is not clutter. Most of the overhead in non-functional languages is not abstraction. > FP adds new abstractions which have variable syntax across languages or even within the same language. What are you talking about? Generally FP languages have less special-case syntax and less special-case concepts, e.g. fewer control flow keywords, exceptions are less prominent, coroutines don't use special keywords or new concepts, mutable variables aren't needed.... I guess do notation is more common in functional languages, but it's a very lightweight piece of syntax sugar that obviates a bunch of what would be special-case syntax in less functional languages: http://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ http://philipnilsson.github.io/Badness10k/escaping-hell-with... . > A program can be written in a conceptually non-fp language, that is composed of functions without side effect. Static doesn't mean side-effect free, and a binary distinction between "side effect" and "not side effect", while somewhat useful, is very crude. But the biggest issue is that it's not practical to write without side effects unless the language's standard library, ecosystem, and most of all culture support it. > People try FP-centric languages, but unless someone pays them, generally people stay away from it except in spurts (eg map, fluent chaining, etc). This should give some pause, as to what that means. On the contrary, popular programming culture creeps slowly in the FP direction every year. Five or ten years ago map was some wacky far-out functional thing.

pjmlp 5y ago

Having learned FP when what we had available was Lisp, Caml Light and Standard ML with Miranda on the horizon, for me the whole "no side effects" is cargo cult from Haskell curch followers that took over the meaning of FP.

kaba0 5y ago

I do find pureness a great feature. While I agree that many things are not unique to FP, or can be easily incorporated into multiparadigm languages, I think having a compiler-enforced “pure” keyword for example would benefit traditional OOP/imperative languages as well. E.g. C would not have to do ugly compiler hacks making common functions like strlen a macro so that the compiler can hoist it out from a for loops conditional for example. Currently they can only assume it through hacks or through inlining. Of course “pure” functions will have memory/CPU overhead, but that is inevitable. Perhaps you would prefer idempotent and memoizable?