3 ms·

> but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life t

> but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. 1) Once upon a time, almost no one used object oriented languages except for Smalltalk weirdos. 2) Ruby, javascript and a host of other languages have "functional" features. Does your language have a "lambda" feature, where you can define nameless functions and pass them around as arguments to other functions? Then you are already working with functional language paradigms. There's nothing really "magically hard" about it, you're overselling how hard it is. This is not rocket science. Most existing programmers can handle it. The hardest thing I had to wrap my mind around when switching my work to Elixir was letting go of mutable state. And attributes and methods on objects. And guess what... It seems that it's a good idea, generally! If you see enough bugs that are only there because something modified an attribute in some unpredictable way which impacted upstream code... You will realize mutable state is bad. If you still aren't convinced that mutable state is evil, watch this Rich Hickey presentation http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... which basically proves that mutable state actually makes state a function of a hidden/conflated "time" variable, proving it's not just wrong from a practical standpoint (in the form of extra bugs that are hard to reason about, and all this brittle mutex code) but from a theoretical one, too. Mutable state comes from a time when memory was expensive, and it's time to ditch the training wheels so we can get the real work done. Both Javascript and Ruby use mutable state extensively, and it's unfortunately not something you can just slap onto the language after the fact (although ClojureScript must make a valiant effort!) And if the high-level language wasn't built with it from the get-go, then you're stuck dealing with legacy libraries using the poorer-written code (see: Ruby gems).

ab5tract 11y ago
Right... Another fad brought up for the sheer fashionability of it. Saying "mutable state is bad" is just as inane as saying "immutability is bad". There are tradeoffs for either. There is absolutely no reason to pretend that one trumps the other in all cases. Other than looking cool to your peers, I guess.
- yellowapple 11y ago
  Nobody's "pretending" that immutability trumps mutability. Rather, we're observing it firsthand. By making immutability the rule rather than the exception thereof, one eliminates a huge swath of bugs and makes an even bigger swatch much more difficult to achieve. That said, you're right that there are tradeoffs, which is why languages like Rust - while defaulting to immutability - allow a programmer to define variables as mutable, and why Elixir (unlike Erlang) allows variables to be reassigned (though the data stored in those variables is still immutable; this is something that's enforced by BEAM). And of course, you can still get many of the benefits of immutability with mutable variables by being careful about how you're using those variables; the difference, however, is that a language which assumes immutability will be able to catch those bugs more easily, forcing the programmer to fix them (either by making the variable mutable (in applicable languages) or refactoring until mutability isn't necessary).
- lectrick 11y ago
  I spent over 10 years writing and working on (and debugging... many hours of debugging) Ruby code. Towards the end I started to write all my Ruby code, as much as possible, as so-called PORO objects (Plain Ol' Ruby Objects). These feature zero inheritance, and are initialized with all the state they need to do their work. I started doing this because I found that writing code that way produced more easily testable, more maintainable, more stable code. Then I realized that functional languages basically all already forced you to do those things, by not holding state anywhere, forcing you to pass it around. These were all logical steps (with the end goal optimization of "useless work elimination"). There was no faddiness involved, other than having "a good feeling" about working with Elixir (over, say, Clojure, Haskell or the other options out there).

ab5tract 11y ago

Right... Another fad brought up for the sheer fashionability of it. Saying "mutable state is bad" is just as inane as saying "immutability is bad". There are tradeoffs for either. There is absolutely no reason to pretend that one trumps the other in all cases. Other than looking cool to your peers, I guess.

yellowapple 11y ago
Nobody's "pretending" that immutability trumps mutability. Rather, we're observing it firsthand. By making immutability the rule rather than the exception thereof, one eliminates a huge swath of bugs and makes an even bigger swatch much more difficult to achieve. That said, you're right that there are tradeoffs, which is why languages like Rust - while defaulting to immutability - allow a programmer to define variables as mutable, and why Elixir (unlike Erlang) allows variables to be reassigned (though the data stored in those variables is still immutable; this is something that's enforced by BEAM). And of course, you can still get many of the benefits of immutability with mutable variables by being careful about how you're using those variables; the difference, however, is that a language which assumes immutability will be able to catch those bugs more easily, forcing the programmer to fix them (either by making the variable mutable (in applicable languages) or refactoring until mutability isn't necessary).
lectrick 11y ago
I spent over 10 years writing and working on (and debugging... many hours of debugging) Ruby code. Towards the end I started to write all my Ruby code, as much as possible, as so-called PORO objects (Plain Ol' Ruby Objects). These feature zero inheritance, and are initialized with all the state they need to do their work. I started doing this because I found that writing code that way produced more easily testable, more maintainable, more stable code. Then I realized that functional languages basically all already forced you to do those things, by not holding state anywhere, forcing you to pass it around. These were all logical steps (with the end goal optimization of "useless work elimination"). There was no faddiness involved, other than having "a good feeling" about working with Elixir (over, say, Clojure, Haskell or the other options out there).