5 ms·

What do you think "Functional Programming" means? Obviously people and various groups have their own made up definitions, but a commonly agreed upon definition

by runT1ME 10y ago

What do you think "Functional Programming" means? Obviously people and various groups have their own made up definitions, but a commonly agreed upon definition in the PL community might be "Programming with Functions". Functions, by definition, are pure.

deleted 10y ago
[deleted]
KirinDave 10y ago
> Functions, by definition, are pure. That's just not true in our domain. While it may be true in some categories, we do not program in an abstract category. In our domain, "pure" functions are distinct enough that we call them "pure" functions and even in Haskell we draw a line between effectful code and pure code. As a core concept in modern programming, the word "function" makes no judgement about how many side effects are there. I'm not sure why people think otherwise. Or perhaps all Lisp and OCaml programmers are just liars and cheats. EDIT: I just had a long conversation twitter about this and I'd like to offer an example of a functional style we commonly use even with side effects: tail recursive loops. We often use this modeling technique even in handling I/O because it dramatically simplifies the logic for consuming a stream.
- uryga 10y ago
  >> Functions, by definition, are pure. >That's just not true. I think there's some naming confusion here. That's because programmers overloaded the original meaning of "function" so that it's equivalent to "procedure". So now when something behaves like an actual mathematical function, we have to explicitly call it "pure". PS. i remember seeing you in some Yogscast videos, used to be a huge fan of those. funny to meet you like this.
  - KirinDave 10y ago
    It's perhaps confusing because people think the constructs they read about in category theory have 1:1 mappings to the world of programming and they don't. It's why we talk about the category Hask. Every single concept is overloaded. P.S., Wow. Someone here who knew about my hobby? I figured it'd never happen.
    - wz1000 10y ago
      > people think the constructs they read about in category theory have 1:1 mappings to the world of programming and they don't. Of course they don't. But they can still be considered a useful model for programming in the same sense that Newtonian physics is a useful model of our world.
      - KirinDave 10y ago
        Of course, but I still think it's important to remind people that functions need not be pure to invoke the benefits of functional programming. The article in question acts like it is a big surprise gotcha that functional programs have imperative elements. This shouldn't be a surprise to anyone and in fact it's a feature! The accessibility of that feature is often a major component of what languages are judged on. This isn't a point of semantics, it's definitely the case that we use functional techniques in an imperative paradigm to great success.
        yrashk 10y ago
        Thanks for the feedback! It's not that functional programs have imperative elements or not. That's kind of besides the point. The point is that putting functional components into workflows that deal with arbitrarily mutable data is reducing the potential we have with the functional model. The article is simply an open-ended invitation for a discussion on how to do this (and it spark a little bit of that conversation) with some of the proposed options on the same blog.
- runT1ME 10y ago
  We're talking about definitions, so you may continue to refer to 'functions' however you like, but from a functional programming perspective, I'm going to posit that it is useful to distinguish between functions and 'impure' functions. :) I think your position is that because there is an escape hatch in languages like Haskell, that negates the usefulness of equational reasoning. I'll argue this isn't true, in the same way it's useful to pretend ⊥ doesn't exist and that we don't bork our unbound recurison or whatnot. Once we do that, we now can reason about our functions as if they exist as arrows in a cartesian closed category (of types). This is incredibly useful. We just have to restrict ourselves to a subset of the language. We still get that same benefit even if part of our program call impure functions. This is the reason we want to model as many side effects as we can in the types (an IO monad or Task in Scala). I saw your twitter convo, I don't know what you mean by this: >"If we define functions as pure, then functional programming doesn't exist outside of extreme specialist applications." All kinds of Haskell applications are built with side effects. Are you under the impression UnsafePerformIO is the only way to interact with the world in Haskell?

by runT1ME 10y ago

deleted 10y ago

[deleted]

KirinDave 10y ago

> Functions, by definition, are pure. That's just not true in our domain. While it may be true in some categories, we do not program in an abstract category. In our domain, "pure" functions are distinct enough that we call them "pure" functions and even in Haskell we draw a line between effectful code and pure code. As a core concept in modern programming, the word "function" makes no judgement about how many side effects are there. I'm not sure why people think otherwise. Or perhaps all Lisp and OCaml programmers are just liars and cheats. EDIT: I just had a long conversation twitter about this and I'd like to offer an example of a functional style we commonly use even with side effects: tail recursive loops. We often use this modeling technique even in handling I/O because it dramatically simplifies the logic for consuming a stream.

uryga 10y ago
>> Functions, by definition, are pure. >That's just not true. I think there's some naming confusion here. That's because programmers overloaded the original meaning of "function" so that it's equivalent to "procedure". So now when something behaves like an actual mathematical function, we have to explicitly call it "pure". PS. i remember seeing you in some Yogscast videos, used to be a huge fan of those. funny to meet you like this.
- KirinDave 10y ago
  It's perhaps confusing because people think the constructs they read about in category theory have 1:1 mappings to the world of programming and they don't. It's why we talk about the category Hask. Every single concept is overloaded. P.S., Wow. Someone here who knew about my hobby? I figured it'd never happen.
  - wz1000 10y ago
    > people think the constructs they read about in category theory have 1:1 mappings to the world of programming and they don't. Of course they don't. But they can still be considered a useful model for programming in the same sense that Newtonian physics is a useful model of our world.
    - KirinDave 10y ago
      Of course, but I still think it's important to remind people that functions need not be pure to invoke the benefits of functional programming. The article in question acts like it is a big surprise gotcha that functional programs have imperative elements. This shouldn't be a surprise to anyone and in fact it's a feature! The accessibility of that feature is often a major component of what languages are judged on. This isn't a point of semantics, it's definitely the case that we use functional techniques in an imperative paradigm to great success.
      - yrashk 10y ago
        Thanks for the feedback! It's not that functional programs have imperative elements or not. That's kind of besides the point. The point is that putting functional components into workflows that deal with arbitrarily mutable data is reducing the potential we have with the functional model. The article is simply an open-ended invitation for a discussion on how to do this (and it spark a little bit of that conversation) with some of the proposed options on the same blog.
runT1ME 10y ago
We're talking about definitions, so you may continue to refer to 'functions' however you like, but from a functional programming perspective, I'm going to posit that it is useful to distinguish between functions and 'impure' functions. :) I think your position is that because there is an escape hatch in languages like Haskell, that negates the usefulness of equational reasoning. I'll argue this isn't true, in the same way it's useful to pretend ⊥ doesn't exist and that we don't bork our unbound recurison or whatnot. Once we do that, we now can reason about our functions as if they exist as arrows in a cartesian closed category (of types). This is incredibly useful. We just have to restrict ourselves to a subset of the language. We still get that same benefit even if part of our program call impure functions. This is the reason we want to model as many side effects as we can in the types (an IO monad or Task in Scala). I saw your twitter convo, I don't know what you mean by this: >"If we define functions as pure, then functional programming doesn't exist outside of extreme specialist applications." All kinds of Haskell applications are built with side effects. Are you under the impression UnsafePerformIO is the only way to interact with the world in Haskell?