3 ms·

I had to audit a web app and the back end code was all written in Erlang. I had never seen the language in use before, so it took me a little while to get the h

I had to audit a web app and the back end code was all written in Erlang. I had never seen the language in use before, so it took me a little while to get the hang of reading it. Now that I've spent some time playing around with it, I think I like Erlang better than I like Haskell; I used to think I disliked dynamic typing but it turns out I just don't like the way Ruby handles it. Erlang feels really good to write code in, and it feels a bit less finicky than Haskell is. If anybody wants to try functional programming and feels like they just can't get along with Haskell, I'd definitely recommend you give Erlang a try. It's not great at everything but I'd highly recommend it as something to try.

lomnakkus 12y ago
There's no accounting for taste, but as "jerf" posted in a sibling comment Erlang's not really functional[0]. All that's really happening is that the mutable state is "hiding" in the message passing portion of the application. Just as an example: It's pretty simple to implement a mutable reference cell as an actor which contains only pure functional code. I'm not sure where I first saw it demonstrated, I think it was one of Erik Meijer's talks/videos. [0] I mean in the "no/minimal mutable state" sense. EDIT: Removed potentially confusing aside. EDIT#2: I guess I should elaborate: The idea is that you just have the MutableRef actor accept two messages: Set(X), Get(X). The basic idea was to just have the actor continually send itself Set(X) messages with the current value -- thus exploiting the messaging to keep mutable state.
- felixgallo 12y ago
  Of what use is this distinction, especially when zero languages fall within its definition? Honestly.
  - lomnakkus 12y ago
    Hm? Haskell is purely functional. (Alright, you can theoretically use unsafeCoerce and unsafePerformIO, but in practice it doesn't actually happen.)
    - felixgallo 12y ago
      Can you please point me to any real-world Haskell program that is purely functional? I am interested in seeing what a program without I/O looks like.
      - lomnakkus 12y ago
        All of them. Remember that "IO a" is just a value. :) It's really the "interpreter" of the IO monadic values which causes all the side effects. I am aware that there are some issues with this interpretation, but if you want to get pragmatic it's really a question of X% pure/(100-X)% impure while keeping X as close to 100% as possible. Haskell can do that for X arbitrarily close to 100% (depending on how much abstraction/effort you're willing to go through).

lomnakkus 12y ago

There's no accounting for taste, but as "jerf" posted in a sibling comment Erlang's not really functional[0]. All that's really happening is that the mutable state is "hiding" in the message passing portion of the application. Just as an example: It's pretty simple to implement a mutable reference cell as an actor which contains only pure functional code. I'm not sure where I first saw it demonstrated, I think it was one of Erik Meijer's talks/videos. [0] I mean in the "no/minimal mutable state" sense. EDIT: Removed potentially confusing aside. EDIT#2: I guess I should elaborate: The idea is that you just have the MutableRef actor accept two messages: Set(X), Get(X). The basic idea was to just have the actor continually send itself Set(X) messages with the current value -- thus exploiting the messaging to keep mutable state.

felixgallo 12y ago
Of what use is this distinction, especially when zero languages fall within its definition? Honestly.
- lomnakkus 12y ago
  Hm? Haskell is purely functional. (Alright, you can theoretically use unsafeCoerce and unsafePerformIO, but in practice it doesn't actually happen.)
  - felixgallo 12y ago
    Can you please point me to any real-world Haskell program that is purely functional? I am interested in seeing what a program without I/O looks like.
    - lomnakkus 12y ago
      All of them. Remember that "IO a" is just a value. :) It's really the "interpreter" of the IO monadic values which causes all the side effects. I am aware that there are some issues with this interpretation, but if you want to get pragmatic it's really a question of X% pure/(100-X)% impure while keeping X as close to 100% as possible. Haskell can do that for X arbitrarily close to 100% (depending on how much abstraction/effort you're willing to go through).