zlacker

>>todsac+(OP)
In fairness, Perl died because it was just not a good language compared to others that popped up after its peak. Sometimes people just move to the better option.

>>mmastr+53
Perl is a great language, the way Scala and Haskell are great: as openly experimental languages, they tried interesting, unorthodox approaches, with varied success. "More than one way to do it" is Perl's motto, because of its audacious experimentation ethos, I'd say.

Perl is not that good a language though for practical purposes. The same way, a breadboard contraption is not what you want to ship as your hardware product, but without it, and the mistakes made and addressed while tinkering with it, the sleek consumer-grade PCB won't be possible to design.

>>nine_k+c5
Couldn't they have figured out one decent way to do things before releasing features to all users? I tried Scala for a bit then decided it was complicated for no good reason.

Idk about Haskell, but I used Erlang which is also purely functional. No matter how long I used it and tried to appreciate its elegance, it became clear this isn't a convenient way to do things generally. But it was designed well, unlike Scala.

>>morshu+6b
Erlang is, by my accounting, not even a functional langauge at all. It takes more than just having immutable values to be functional, and forcing users to leave varibles as immutable was a mistake, which Elixir fixes. Erlang code in practice is just imperative code written with immutable values, and like a lot of other modern languages, occasional callouts to things borrowed from functional programming like "map", but it is not a functional language in the modern sense.

If you go to learn Haskell, you will find that it has a lot to say about functional programming that Erlang did not teach you. You will also find that you've already gotten over one of the major hurdles to writing Haskell, which is writing with immutable values, which significantly reduces the difficult of swallowing the entire language at once and makes it relatively easier. I know it's a relatively easy path because it's the one I took.

>>jerf+Kk
> Erlang is, by my accounting, not even a functional langauge at all.

How do you figure?

The essence of FP is functions of the shape `data -> data` rather than `data -> void`, deemphasizing object-based identity, and treating functions as first-class tools for abstraction. There's enough dynamic FP languages at this point to establish that these traits are held in common with the static FP languages. Is Clojure not an FP language?

> It takes more than just having immutable values to be functional, and forcing users to leave varibles as immutable was a mistake, which Elixir fixes.

All data in Elixir is immutable. Bindings can be rebound but the data the bindings point to remains immutable, identical to Erlang.

Elixir just rewrites `x = 1; x = x + 1` to `x1 = 1; x2 = x1 + 1`. The immutable value semantics remain, and anything that sees `x` in between expressions never has its `x` mutated.

> Erlang code in practice is just imperative code written with immutable values, and like a lot of other modern languages, occasional callouts to things borrowed from functional programming like "map", but it is not a functional language in the modern sense.

I did a large amount of Scala prior to doing Erlang/Elixir and while I had a lot of fun with Applicative and Monoid I'm not sure they're the essence of FP. Certainly an important piece of the puzzle but not the totality.