4 ms·

It has! Almost all major languages today let you pass functions (and closures with captured bindings) as values.

• iopq 11y ago
  That's not really what functional programming is about. Functional programming is more about avoiding state and referential transparency. Most programmers do not attempt to do this in mainstream programming languages.
  • scalatohaskell 11y ago
    avoiding global/shared state :) we are not avoiding state as per se. State if super important! That's why we care about it so much. But Im just nitpicking, sorry
    • iopq 11y ago
      I meant "hidden" state because functional programs still reason about state, but more explicitly. In a functional style you can't just call a function that relies on hidden state somewhere, you have to pass that state in! But with partial application and currying you could pass the state in at any point in the program, so all the functions on the inside are pure, while state exists on the edges.
      • hollerith 11y ago
        Well, using a state monad such as Haskell's IO monad is usually considered functional style, but the state is hidden. Moreover, any body of code in which state is passed around in explicit arguments can be transformed into code in continuation-passing style (or monadic style) in which the state is hidden -- and it's hard to argue that the code in continuation-passing style is not functional code. Whether or not the state is hidden is not one of the distinguishing features of functional programming. Referential transparency and being able to declare certain "values" to be immutable even though there are some mutable values around are. For example, if some code is referentially transparent, putting it into continuation-passing style preserves the referential transparency. BTW, some say that being able to specify the result that you want rather than needing to specify how those results are computed -- which is sometimes called "declarative programming" -- is what makes functional programming powerful, but I disagree: it is being referentially-transparent (or more precisely, more referentially-transparent that imperative code) and giving the programmer the ability to credibly assert that this or that data structure is immutable, combined with language and library support for working with immutable data structures. Another distinguishing feature of functional programming: being able to rely on (or hope for) certain compiler optimizations not available in imperative languages. (It is because of this feature that Scheme is considered by some to be a functional language.) Referential transparency might be necessary to make these optimizations tractable.
        • iopq 11y ago
          IO monad doesn't hide state, it says right in the type that it's IO. Neither do other monads that "hide" state according to you, because they actually specify that they use state right in the type signature. OOP approach hides state because it uses private variables that might be modified in the body of the function. Yet there is nothing in the type signature that states that this function is not referentially transparent!
  • the_cat_kittles 11y ago
    but good programmers? yes.
  • Avshalom 11y ago
    It's what functional programming was about for the first twenty years. That and everything being an expression that returns a value.
    • coldtea 11y ago
      20? More like 40. Until 2005 or so few considered this "pure" style essential to FP.
  • turkishrevenge 11y ago
    While state/referential transparency/immutability are important (and great features), they're more associated with pure FP. Purity is not a necessary precondition for a language to be classed as "functional". I'd argue that the defining feature of FP is the treatment as functions as first class values. Everything philosophically speaking, flows from this fact.
  • eru 11y ago
    Even Python has immutable strings and numbers. Mainstream languages are slowly moving towards more and more functional concepts. The progress towards referential transparency is slow, but ongoing.
  • api 11y ago
    Isn't performance a problem? Technically you can memoize to eliminate constant recomputing of state, but that itself is overhead. Sometimes I try to use a functional style in common languages and end up backing out when it comes time to optimize.
    • eru 11y ago
      It depends on what kind of performance problems you have. Some algorithms are hard to express in pure, strict functional settings. (There's even an impossibility theorem for a few algorithms, but that theorem doesn't apply to pure, lazy languages.) That being said, the worst asymptotic slowdown is logarithmic---because you can always simulate random access memory. On a more practical side, you have constant factors to worry about, and things like caches. Look at eg Don Stewarts work for how to deal with these in a functional language. (And, in practice, there's no shame in throwing in the towel and either interfacing with other languages, or even switching to them.)
  • girvo 11y ago
    React's new stateless components are very functional in that regard, and are being adopted rapidly