4 ms·

Or even more so, Racket. There are purists who don't consider Racket or even Scheme to be Lisps, either. FWIW, I do not agree with them (I also consider Clojur

Or even more so, Racket. There are purists who don't consider Racket or even Scheme to be Lisps, either. FWIW, I do not agree with them (I also consider Clojure a Lisp), but they exist. There's a certain highly vocal contingent of Lisp fans who consider the Common Lisp spec to be some kind of sacred document, and that anything that's been invented in the past 37 (!) years is useless. IMO, those people have done far more harm than good for Lisp and Lisp-like languages. And yeah, there's a lot of the same religion-like purity around Rust nowadays.

Zababa 5y ago
Same thing with Haskell, in the last month I had a few people argue with me that if a language isn't Haskell, it's not functional programming.
- tephra 5y ago
  I've talked to several people who equate fp with "advanced type system" and not "programming by function composition" (which for me is the correct definition).
  - erik_seaberg 5y ago
    Composition is table stakes now, I’d say pure functions (no side effects) are what make FP important with or without types.
    - Zababa 5y ago
      I think the focus on "pure functions" is a bit Haskell-centric, as those are the guarantees that Haskell gives easily, but that's it. For example, Koka has total functions (https://koka-lang.github.io/koka/doc/book.html#why-effects https://koka-lang.github.io/koka/doc/book.html#why-effects), which gives more guarantees that pure functions. Lack of side effect is, I think, a side effect of searching for greater function composition. The goal of purity is to make functions easier to compose after all.
      - JoelMcCracken 5y ago
        Well, you can still have pure functions without having an effects system. It just isn't checked. I think that's generally part of the mark of functional programming. If you do have side effects in some parts of the program then that part would be not functional.
      - erik_seaberg 5y ago
        That could be useful. Does Koka reject a total function that might not always terminate, or trust the author?
        Zababa 5y ago
        From what I understand, Koka relies on inference, so for example a function with a "while" or a recursive call will be marked as "div". I think the goal is to have the precision of Haskell, and even better, but without forcing the use of monads or something like that.

Zababa 5y ago

Same thing with Haskell, in the last month I had a few people argue with me that if a language isn't Haskell, it's not functional programming.

tephra 5y ago
I've talked to several people who equate fp with "advanced type system" and not "programming by function composition" (which for me is the correct definition).
- erik_seaberg 5y ago
  Composition is table stakes now, I’d say pure functions (no side effects) are what make FP important with or without types.
  - Zababa 5y ago
    I think the focus on "pure functions" is a bit Haskell-centric, as those are the guarantees that Haskell gives easily, but that's it. For example, Koka has total functions (https://koka-lang.github.io/koka/doc/book.html#why-effects https://koka-lang.github.io/koka/doc/book.html#why-effects), which gives more guarantees that pure functions. Lack of side effect is, I think, a side effect of searching for greater function composition. The goal of purity is to make functions easier to compose after all.
    - JoelMcCracken 5y ago
      Well, you can still have pure functions without having an effects system. It just isn't checked. I think that's generally part of the mark of functional programming. If you do have side effects in some parts of the program then that part would be not functional.
    - erik_seaberg 5y ago
      That could be useful. Does Koka reject a total function that might not always terminate, or trust the author?
      - Zababa 5y ago
        From what I understand, Koka relies on inference, so for example a function with a "while" or a recursive call will be marked as "div". I think the goal is to have the precision of Haskell, and even better, but without forcing the use of monads or something like that.