5 ms·

I think one issue that pops up in many languages is the distinction between functions that have side effects and those that don't. In C++ you see standard libra

I think one issue that pops up in many languages is the distinction between functions that have side effects and those that don't. In C++ you see standard library higher-order-functions that accept lambdas or other functions, but the documentation says "the function passed should not produce side-effects." You also see this in Clojure functions, and functions you might write might also expect only side-effect-free functions. The problem is that the functions you pass may not be functions you wrote, they might come from another library and then to be most confident, you must go and look up the source or docs to feel sure. I don't think a naming convention is enough, since many may not use the convention. For languages where this is important, I wish there was a compiler or runtime check for these things so the user didn't have to take responsibility. Almost as if functions were split into two "function types", those with and those without side effects. Maybe starting at the lowest level of the core language library, some functions would be noted as causing side-effects, and then any function built that called those functions would automatically be categorized as such, and on up to the top, so that side-effects-beget-side-effects and function parameters that require non-side-effect-functions wouldn't allow those to pass. Anyway, it is a problem that is not solved by a naming convention.

germanier 11y ago
Haskell for example has exactly that with e.g. the IO monad.
- hellofunk 11y ago
  I don't know Haskell, but assumed it would probably tackle this problem based on all the praise I've seen it get for things like this and its general type system.
  - baldfat 11y ago
    It gets all the praise but the use of Haskell is still very low. For me the package system drove me into the Arms of Racket and Clojure.
    - kornish 11y ago
      You should revisit it, then! Stack, a new build tool, far surpasses the Cabal hell that drove people away in the past.
      - hellofunk 11y ago
        I have read many times that you need a solid understanding of the Haskell implementation as well as various extension to make the code as performant as it is elegant. True?
        kornish 11y ago
        Right now, that's truer than many would like. However, when GHC 8 (the new version of the compiler) drops in the next couple months, most of the performance tuning will involve putting a single line of code at the top of each performance-critical file. That line will make all evaluation within the file strict instead of lazy. A lot of the performance and predictability problems in Haskell come from its laziness, so the ability to toggle that on and off on a per-module (read: per-file) basis will be a game changer.
        hellofunk 11y ago
        That does sound significant. I will be curious to hear more about that. Can you recommend a good go-to resource for all the latest news and discussions on Haskell?
        kornish 11y ago
        Mostly I just read various people's blog posts and follow links (for example, I think I first found Stack on [1]). I also spend occasional time in the IRC, which can be useful but isn't a comprehensive news source by any means. I hear some of the mailings lists are informative - iirc there's a haskell-beginners one which will probably cover major updates in tooling, feature releases, and so on. Good luck! [1]: https://www.fpcomplete.com/blog/2015/08/new-in-depth-guide-stack https://www.fpcomplete.com/blog/2015/08/new-in-depth-guide-s...
  - tel 11y ago
    Yup. Here's an example. There is no function print :: String -> () (The type () implies "no interesting return value"). This function could only be written via deliberate subversion of the type system. Instead it must be print :: String -> IO () Which is similar, but the return is marked by this IO type. Essentially this restricts you to ensure that side effecting functions are executed in explicit sequence and cannot "poison" pure types.
greggman 11y ago
Jai proposed a solution where like c++ you have to name the variables you're closing over but optionally require that all functions called by the function not access any other variables
smrtinsert 11y ago
One hundred percent agree. Having come to places like this several times in my career I'm ready to start looking into lead. I'm getting bored of the deficiences of programming and would love someone else to deal with this crap.
nitrogen 11y ago
I haven't written any C++ in a while, but isn't that how const methods work? One would think there might be a similar concept of a const lambda.
- hellofunk 11y ago
  You are talking about object methods, in which const has meaning limited to the object's data, and nothing else -- you can still do side-effects. I'm talking about also anonymous lambdas (modern c++ feature) and non-object functions. There is no way to say in C++ (or even a more functional language like Clojure) if a function has side-effects or not.

germanier 11y ago

Haskell for example has exactly that with e.g. the IO monad.

hellofunk 11y ago
I don't know Haskell, but assumed it would probably tackle this problem based on all the praise I've seen it get for things like this and its general type system.
- baldfat 11y ago
  It gets all the praise but the use of Haskell is still very low. For me the package system drove me into the Arms of Racket and Clojure.
  - kornish 11y ago
    You should revisit it, then! Stack, a new build tool, far surpasses the Cabal hell that drove people away in the past.
    - hellofunk 11y ago
      I have read many times that you need a solid understanding of the Haskell implementation as well as various extension to make the code as performant as it is elegant. True?
      - kornish 11y ago
        Right now, that's truer than many would like. However, when GHC 8 (the new version of the compiler) drops in the next couple months, most of the performance tuning will involve putting a single line of code at the top of each performance-critical file. That line will make all evaluation within the file strict instead of lazy. A lot of the performance and predictability problems in Haskell come from its laziness, so the ability to toggle that on and off on a per-module (read: per-file) basis will be a game changer.
        hellofunk 11y ago
        That does sound significant. I will be curious to hear more about that. Can you recommend a good go-to resource for all the latest news and discussions on Haskell?
        kornish 11y ago
        Mostly I just read various people's blog posts and follow links (for example, I think I first found Stack on [1]). I also spend occasional time in the IRC, which can be useful but isn't a comprehensive news source by any means. I hear some of the mailings lists are informative - iirc there's a haskell-beginners one which will probably cover major updates in tooling, feature releases, and so on. Good luck! [1]: https://www.fpcomplete.com/blog/2015/08/new-in-depth-guide-stack https://www.fpcomplete.com/blog/2015/08/new-in-depth-guide-s...
- tel 11y ago
  Yup. Here's an example. There is no function print :: String -> () (The type () implies "no interesting return value"). This function could only be written via deliberate subversion of the type system. Instead it must be print :: String -> IO () Which is similar, but the return is marked by this IO type. Essentially this restricts you to ensure that side effecting functions are executed in explicit sequence and cannot "poison" pure types.

greggman 11y ago

Jai proposed a solution where like c++ you have to name the variables you're closing over but optionally require that all functions called by the function not access any other variables

smrtinsert 11y ago

One hundred percent agree. Having come to places like this several times in my career I'm ready to start looking into lead. I'm getting bored of the deficiences of programming and would love someone else to deal with this crap.

nitrogen 11y ago

I haven't written any C++ in a while, but isn't that how const methods work? One would think there might be a similar concept of a const lambda.

hellofunk 11y ago
You are talking about object methods, in which const has meaning limited to the object's data, and nothing else -- you can still do side-effects. I'm talking about also anonymous lambdas (modern c++ feature) and non-object functions. There is no way to say in C++ (or even a more functional language like Clojure) if a function has side-effects or not.