6 ms·

But why would you want a "functional programming" language when you can have a modern multiparadigm language (JavaScript 6, Swift, Java 8, C#)? The author seem

by chvid 11y ago

But why would you want a "functional programming" language when you can have a modern multiparadigm language (JavaScript 6, Swift, Java 8, C#)? The author seems to believe that no side effects is the key property of a functional language. But for me most problems I deal with (user interface, various business domains, integration with other systems over network etc.) are filled with state and procedures. Sure you can deal with that in a purely functional way but to me it is a bit like doing object-orientated programming in C with macros and a lot of conventions. Why not simply use a programming language with suitable primitives? In particular now that multiparadigm languages are the most widely used in our industry.

seanwilson 11y ago
Controlling state the way functional languages do makes code significantly easier to test. Besides this, functional languages have many great features such as strong typing, pattern matching and inductive types that have yet to be adopted by any mainstream languages.
- chvid 11y ago
  Don't get me wrong; I think "no side effects" is a very useful way of programming for a large number of problems. But not all problems. In particular problems related to user interface and system integration. And languages I listed (JavaScript, C#, Swift and Java) have all stolen large chunks of ideas pioneered by functional programming and put it into their latest release.
  - tombert 11y ago
    If you take a language like Haskell, you can utilize an FRP framework like Netwire to write pure-ish code whilst having reactive things. I'm currently writing an ncurses application that does exactly that.
- davexunit 11y ago
  Static typing is not a requirement for a functional programming language.
  - lmm 11y ago
    It's a requirement for being able to write library functions that work with custom effects, which is perhaps the biggest advantage of a functional programming language.
murbard2 11y ago
The value of functional programming is not in what it brings, it's in what it takes away. It is easier to reason about functional programs because they maintain certain properties. These could be types, an absence of side effect, etc. This is the point of the entire article. You get none of those benefits if your "multi paradigm" language allows you to break those guarantees. For a multi paradigm language to derive benefits from functional programming, it should allow developers to explicitly write guarantees that can be enforced at compile time. This is a promising direction but, to my knowledge, it's not available in any of the languages you mentioned.
- asonge 11y ago
  I think this is exactly it. If you had a multi-paradigm language, you'd need not only just some way to break the rules easily and have that bubble up, you'd also want this rule-breaking behavior to be exposed up the chain from any libraries. You'd also have to enforce the benefits of immutability and such through social pressure in order for users to see large parts of the benefits of side-effect isolation. A lot of the choices FP languages make that are less about side-effects (like strict typing systems) are also often an all-or-none proposition. Optional typing systems have very limited benefits if libraries aren't well-typed. The static analyzers can only do so much.
  - dozzie 11y ago
    Oh, they can do surprisingly much. See how Erlang works with its optional typespecs and dialyzer.
- sohcahtoa 11y ago
  Code Contracts for .NET, maybe?
- the_af 11y ago
  > The value of functional programming is not in what it brings, it's in what it takes away. That's what I used to think, and in fact I still think like that somewhat, but do note it's explicitly mentioned as a red herring in John Hughes' well-known and often quoted paper "Why Functional Programming Matters". From the paper: > Such a catalogue of “advantages” [things that FP lacks or constraints] is all very well, but one must not be surprised if outsiders don’t take it too seriously. It says a lot about what functional programming isn’t (it has no assignment, no side effects, no flow of control) but not much about what it is. The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these “advantages” are totally unconvincing. > [...] > Functional programmers argue that there are great material benefits — that a functional programmer is an order of magnitude more productive than his or her conventional counterpart, because functional programs are an order of magnitude shorter. Yet why should this be? The only faintly plausible reason one can suggest on the basis of these “advantages” is that conventional programs consist of 90% assignment statements, and in functional programs these can be omitted! This is plainly ridiculous. If omitting assignment statements brought such enormous benefits then Fortran programmers would have been doing it for twenty years. It is a logical impossibility to make a language more powerful by omitting features, no matter how bad they may be. He then goes on to argue that the real benefit of FP languages is that they excel at modularity, a widely agreed upon trait of good software, and that they have an excellent mechanism for "gluing" stuff together, i.e. lazy evaluation. (I've since read that some FP devs disagree about the importance Hughes placed on laziness).
bad_user 11y ago
I've tried working in an FP style in the "multiparadigm" languages you've mentioned, but it's hard, really hard. Well actually, the irony is that JavaScript is the one that's bearable and that's because (1) you can find some Javascript libraries that are doing FP and (2) it's very flexible. Static languages such as Java and C# are not OK though. For one they lack features that are essential for statically typed languages. For example higher kinded types is an essential feature for FP. Without that you can't build libraries of reusable FP stuff. Comparing it with Scala for example you can't build Scalaz or the newer Cats or Shapeless [1]. The other problem is that FP programming languages come with FP libraries. You can't underestimate the importance of having good implementations for persistent collections be the default. On having "no side effects", that's not what FP is about. After all, without side-effects you couldn't get any output out of a program. FP is about encoding those side-effects in types and abstractions you can reason about, or in other words it's about controlling side-effects. Haskell developers are fond of their IO monads. FRP is another way of doing that, being particularly good at dealing with user interfaces. And for example FRP-related libraries that were born by playing to the strengths of the mainstream languages we are dealing with are Facebook's React and Microsoft's Rx. BTW, this is one of the best books on functional programming available today: http://www.manning.com/bjarnason/ http://www.manning.com/bjarnason/ [1] https://github.com/scalaz/scalaz https://github.com/scalaz/scalaz, https://github.com/non/cats https://github.com/non/cats, https://github.com/milessabin/shapeless https://github.com/milessabin/shapeless
- cygx 11y ago
  I beg to somewhat differ: As far as purely functional languages go, it is about reification of side effects (eg via monads or uniqueness types) in such a way that you do get to use pure functions. My personal definition of 'functional' is based on this lack of side-effects (or, more abstractly, on modelling computation as a declaration of relations between sets, which is what mathematical functions are), but it gets fuzzy once you leave the realm of purely functional languages. If you prefer another definition for pragmatic reasons, I'm fine with it, it's just not my choice.
- felixgallo 11y ago
  While HKT are pretty neat, they're hardly essential, and to claim that without them you literally can't build reusable FP libraries is ridiculous.
rdtsc 11y ago
> (user interface, various business domains, integration with other systems over network etc.) are filled with state and procedures. Procedures can be modeled as functions, state can be passed around, user interface hotness currently is also trending to functional / immutable (Elm, React). > bit like doing object-orientated programming in C with macros and a lot of conventions. If you are forced to use C and macros yeah it is no fun. But if you have tail call optimizations, a good type system (even optional one like Erlang does), immutable data structure support, monitoring and tools (Erlang VM), you can build large systems that handle lots of mutable state in a sane way. Doesn't matter what language or OO heavy framework (worked on Python, C++, C, C#, Java over the years) if there is lots of mutable state stored in class instances, it makes it very hard to jump in and understand a new large code base. While say something written in Erlang the state is explicitly passed around, it is minimized, and looking at a piece of code it easy to understand what happens vs say looking at somethingSomethingManagerInstance with 100 methods and 100 private data attributes, and understand when something breaks how it go to that broken state. That's just my observation based on systems I worked over the years.
kwhitefoot 11y ago
I keep seeing C# referred to as modern. Would someone please explain what is modern about it?

by chvid 11y ago

seanwilson 11y ago

Controlling state the way functional languages do makes code significantly easier to test. Besides this, functional languages have many great features such as strong typing, pattern matching and inductive types that have yet to be adopted by any mainstream languages.

chvid 11y ago
Don't get me wrong; I think "no side effects" is a very useful way of programming for a large number of problems. But not all problems. In particular problems related to user interface and system integration. And languages I listed (JavaScript, C#, Swift and Java) have all stolen large chunks of ideas pioneered by functional programming and put it into their latest release.
- tombert 11y ago
  If you take a language like Haskell, you can utilize an FRP framework like Netwire to write pure-ish code whilst having reactive things. I'm currently writing an ncurses application that does exactly that.
davexunit 11y ago
Static typing is not a requirement for a functional programming language.
- lmm 11y ago
  It's a requirement for being able to write library functions that work with custom effects, which is perhaps the biggest advantage of a functional programming language.

murbard2 11y ago

The value of functional programming is not in what it brings, it's in what it takes away. It is easier to reason about functional programs because they maintain certain properties. These could be types, an absence of side effect, etc. This is the point of the entire article. You get none of those benefits if your "multi paradigm" language allows you to break those guarantees. For a multi paradigm language to derive benefits from functional programming, it should allow developers to explicitly write guarantees that can be enforced at compile time. This is a promising direction but, to my knowledge, it's not available in any of the languages you mentioned.

asonge 11y ago
I think this is exactly it. If you had a multi-paradigm language, you'd need not only just some way to break the rules easily and have that bubble up, you'd also want this rule-breaking behavior to be exposed up the chain from any libraries. You'd also have to enforce the benefits of immutability and such through social pressure in order for users to see large parts of the benefits of side-effect isolation. A lot of the choices FP languages make that are less about side-effects (like strict typing systems) are also often an all-or-none proposition. Optional typing systems have very limited benefits if libraries aren't well-typed. The static analyzers can only do so much.
- dozzie 11y ago
  Oh, they can do surprisingly much. See how Erlang works with its optional typespecs and dialyzer.
sohcahtoa 11y ago
Code Contracts for .NET, maybe?
the_af 11y ago
> The value of functional programming is not in what it brings, it's in what it takes away. That's what I used to think, and in fact I still think like that somewhat, but do note it's explicitly mentioned as a red herring in John Hughes' well-known and often quoted paper "Why Functional Programming Matters". From the paper: > Such a catalogue of “advantages” [things that FP lacks or constraints] is all very well, but one must not be surprised if outsiders don’t take it too seriously. It says a lot about what functional programming isn’t (it has no assignment, no side effects, no flow of control) but not much about what it is. The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these “advantages” are totally unconvincing. > [...] > Functional programmers argue that there are great material benefits — that a functional programmer is an order of magnitude more productive than his or her conventional counterpart, because functional programs are an order of magnitude shorter. Yet why should this be? The only faintly plausible reason one can suggest on the basis of these “advantages” is that conventional programs consist of 90% assignment statements, and in functional programs these can be omitted! This is plainly ridiculous. If omitting assignment statements brought such enormous benefits then Fortran programmers would have been doing it for twenty years. It is a logical impossibility to make a language more powerful by omitting features, no matter how bad they may be. He then goes on to argue that the real benefit of FP languages is that they excel at modularity, a widely agreed upon trait of good software, and that they have an excellent mechanism for "gluing" stuff together, i.e. lazy evaluation. (I've since read that some FP devs disagree about the importance Hughes placed on laziness).

bad_user 11y ago

I've tried working in an FP style in the "multiparadigm" languages you've mentioned, but it's hard, really hard. Well actually, the irony is that JavaScript is the one that's bearable and that's because (1) you can find some Javascript libraries that are doing FP and (2) it's very flexible. Static languages such as Java and C# are not OK though. For one they lack features that are essential for statically typed languages. For example higher kinded types is an essential feature for FP. Without that you can't build libraries of reusable FP stuff. Comparing it with Scala for example you can't build Scalaz or the newer Cats or Shapeless [1]. The other problem is that FP programming languages come with FP libraries. You can't underestimate the importance of having good implementations for persistent collections be the default. On having "no side effects", that's not what FP is about. After all, without side-effects you couldn't get any output out of a program. FP is about encoding those side-effects in types and abstractions you can reason about, or in other words it's about controlling side-effects. Haskell developers are fond of their IO monads. FRP is another way of doing that, being particularly good at dealing with user interfaces. And for example FRP-related libraries that were born by playing to the strengths of the mainstream languages we are dealing with are Facebook's React and Microsoft's Rx. BTW, this is one of the best books on functional programming available today: http://www.manning.com/bjarnason/ http://www.manning.com/bjarnason/ [1] https://github.com/scalaz/scalaz https://github.com/scalaz/scalaz, https://github.com/non/cats https://github.com/non/cats, https://github.com/milessabin/shapeless https://github.com/milessabin/shapeless

cygx 11y ago
I beg to somewhat differ: As far as purely functional languages go, it is about reification of side effects (eg via monads or uniqueness types) in such a way that you do get to use pure functions. My personal definition of 'functional' is based on this lack of side-effects (or, more abstractly, on modelling computation as a declaration of relations between sets, which is what mathematical functions are), but it gets fuzzy once you leave the realm of purely functional languages. If you prefer another definition for pragmatic reasons, I'm fine with it, it's just not my choice.
felixgallo 11y ago
While HKT are pretty neat, they're hardly essential, and to claim that without them you literally can't build reusable FP libraries is ridiculous.

rdtsc 11y ago

> (user interface, various business domains, integration with other systems over network etc.) are filled with state and procedures. Procedures can be modeled as functions, state can be passed around, user interface hotness currently is also trending to functional / immutable (Elm, React). > bit like doing object-orientated programming in C with macros and a lot of conventions. If you are forced to use C and macros yeah it is no fun. But if you have tail call optimizations, a good type system (even optional one like Erlang does), immutable data structure support, monitoring and tools (Erlang VM), you can build large systems that handle lots of mutable state in a sane way. Doesn't matter what language or OO heavy framework (worked on Python, C++, C, C#, Java over the years) if there is lots of mutable state stored in class instances, it makes it very hard to jump in and understand a new large code base. While say something written in Erlang the state is explicitly passed around, it is minimized, and looking at a piece of code it easy to understand what happens vs say looking at somethingSomethingManagerInstance with 100 methods and 100 private data attributes, and understand when something breaks how it go to that broken state. That's just my observation based on systems I worked over the years.

kwhitefoot 11y ago

I keep seeing C# referred to as modern. Would someone please explain what is modern about it?