4 ms·

>> 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 me

by 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.

by uryga 10y ago

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.