4 ms·

This is true, but it depends which language we're talking about. There are two definitions to FP. The stricter one is about having immutable data and pure funct

This is true, but it depends which language we're talking about. There are two definitions to FP. The stricter one is about having immutable data and pure functions. In that one, it's fundamentally only a computing language, not a programming language, in that by definition it cannot tell the computer to perform any action, as purity implies no side effects. That means you always need an additional layer which then drives the side effect. For a lot of programs, that adds some complexity to the program. The programmer has to model their side effects with this layer in mind. The layer means the programmer loses control over the fine grained details of the side effect as well, which might hurt performance, or make certain things more difficult. That said, there are impure FP languages. Where you can program the machine to do whatever you want, and also make computation functionally with immutable data and pure functions. Clojure is such a language. I'm very biased towards it FYI, as it's the language I enjoy most as of now. But I think it's important to bring it up. Defaulting to immutable and pure computations, but letting you perform all kinds of controlled mutation and side effect really seems like a good future to me. Rust in a sense is pretty similar. While it doesn't use a strict functional sense of immutability and purity of data and functions. The borrow checker tracks all changes to data and assigns ownership of access, which is kind of similar to immutability and purity. Yet it lets you do unsafe things when required, often for interopping with peripherals and the machine itself. Erlang like you mentioned is another example of this. I think those languages might have a better future, and are slowly starting to pick up on popularity. Even in JS for example, lots of people are adopting this style. So if not a programming language, at least the paradigm seems to become more and more popular. As an aside, for example, there is a Clojure dialect called ferret https://ferret-lang.org/ https://ferret-lang.org/ which is designed for use on microcontrollers. It has immutable data structures and support all the functional aspects of Clojure, yet targets real time control applications.

eru 6y ago
Immutable data and pure functions aren't as big as an obstacle as you might think. Uniqueness types allow you to use immutable variables and still directly model side effects and state changes. Arguably better than mutable variables do so. (Haskell is not a good language for that kind of control. Though you could make a language that looks quite a lot like Haskell that fits. And people have done so.)
- didibus 6y ago
  Isn't uniqueness typing just a more restrictive form to Rust's linear types? And since Rust itself is often forced to rely on unsafe blocks for programming tasks (as opposed to computing tasks), then wouldn't that be true of a language with uniqueness types as well? Also, I'm guessing you mean Clean or Miranda? Any idea why they aren't more popular than Haskell? Or why Haskell doesn't adopt uniqueness typing?
  - eru 6y ago
    Linear types and uniqueness typing are so close together that people often mix them up. Yes, that's basically what I am talking about. For general usage monads are much easier to deal with than Clean's "pass around the world" system. (I only used Clean for a bit, but haven't used Miranda, yet.) However, linear types for Haskell have been in the works for some time. See eg https://www.reddit.com/r/haskell/comments/dpr276/what_is_the_status_of_ghc_linear_types/ https://www.reddit.com/r/haskell/comments/dpr276/what_is_the... (Similarly, GHC now support strict Haskell, too, on a per module basis.) Uniqueness typing shines when you want to split up your 'real-world' object, so you can eg manipulate individual memory cells or ports etc independently. Rust goes into unsafe mode for multiple reasons. You could eliminate most of those, if you were willing to take the complexity of dependent types. Ie more or less that means the programmer taking on a greater burden of proving code to be safe to the compiler; instead of relying on Rust's more automatic but conservative system.

eru 6y ago

Immutable data and pure functions aren't as big as an obstacle as you might think. Uniqueness types allow you to use immutable variables and still directly model side effects and state changes. Arguably better than mutable variables do so. (Haskell is not a good language for that kind of control. Though you could make a language that looks quite a lot like Haskell that fits. And people have done so.)

didibus 6y ago
Isn't uniqueness typing just a more restrictive form to Rust's linear types? And since Rust itself is often forced to rely on unsafe blocks for programming tasks (as opposed to computing tasks), then wouldn't that be true of a language with uniqueness types as well? Also, I'm guessing you mean Clean or Miranda? Any idea why they aren't more popular than Haskell? Or why Haskell doesn't adopt uniqueness typing?
- eru 6y ago
  Linear types and uniqueness typing are so close together that people often mix them up. Yes, that's basically what I am talking about. For general usage monads are much easier to deal with than Clean's "pass around the world" system. (I only used Clean for a bit, but haven't used Miranda, yet.) However, linear types for Haskell have been in the works for some time. See eg https://www.reddit.com/r/haskell/comments/dpr276/what_is_the_status_of_ghc_linear_types/ https://www.reddit.com/r/haskell/comments/dpr276/what_is_the... (Similarly, GHC now support strict Haskell, too, on a per module basis.) Uniqueness typing shines when you want to split up your 'real-world' object, so you can eg manipulate individual memory cells or ports etc independently. Rust goes into unsafe mode for multiple reasons. You could eliminate most of those, if you were willing to take the complexity of dependent types. Ie more or less that means the programmer taking on a greater burden of proving code to be safe to the compiler; instead of relying on Rust's more automatic but conservative system.