It's not easy to develop things so useful & elegant that you win people over... but it's easier than arguing the Internet into submission from a mailing list.
It's not easy to develop things so useful & elegant that you win people over... but it's easier than arguing the Internet into submission from a mailing list.
1) Default to functional ideas: Variables are immutable, recursion is encouraged, etc; but you can get access to imperative code when needed (Call this the Algoritmically functional languages)
2) Functional is the norm: You can't write non-pure functions with side-effects at all. These are the Pure Functional languages.
I am leaning towards 1 more than 2 personally, but many people would disagree with me on that one. The question is: Do you want a usable program written in class 1 or 2? Because there is a hell of a difference between them and how you build software for the two classes.
Interesting class 1 projects, where you can get the source code, are: ejabberd, mldonkey, unison, harmony/boomerang, coq, twelf, isabelle, coccinelle, and mlton.
Interesting class 2 projects could be xmonad, darcs, and GHC.
Of these projects, some would be easily implementible in imperative languages, some would be hard but doable and some would be insanely impossible to do. Please note that all things on the list are useful and elegant. But they might not have a user-base as big as other projects.
The closest thing I know is the website which became yahoo stores. It was originally written in lisp (no really functional, I know). The lisp worked great when they had a dedicated lisp manager managing it. When Yahoo took over, the rewrote it in something else, not because the something-else worked better but because they couldn't find/manage the development in lisp.
So functional might be failing this way. But it might just be hard to write big functional programming applications. I'd like to here more about this.
Hashlife algorithm might find some benefits from implementing it in a functional language.
Functional language helps a lot in building of side effect free code. But such code can be written even in pure assembler. I writing in such style in any language, including Bash.
Sometimes I need to refactor somebody else code. Code functionality remains exact same after refactoring. Things that changed are: better code clarity, better reusability, and better testability as part of reusability.
Unit tests creates additional contexts, in which main code can be used, thus they force to improve reusability of the code, thus code forced to make less or none side effects, thus programmer forced to rewrite code in functional style.
Use code convention to define which flags, registers, and memory areas, IO registers, etc. must be preserved by the called function. Just ignore any other changes.