I can't be the only one who thinks that implementing a toy function in one line of terse code doesn't demonstrate anything useful. What about programming in the large? What about efficiency of naive implementations? What about maintainability? These are things that actually matter in software engineering.
It's only anecdotal, but I find pure, immutable code far easier to maintain in any language. To a first approximation, a functional interface == a testable interface.
I've joined several projects in their maintenance phase which had no tests, and introduced some as I went about debugging, adding features, etc. Since the code was often untestable, I'd make a few refactorings over and over again to allow testing, and these just-so-happen to tease apart the pure computation from the effects; in essence making the code more functional.
An obvious example is to turn implicit state into explicit parameters, eg.
// BEFORE
function foo(x, y) {
b = x + y + a;
}
// AFTER
function foo(x, y) {
b = foo_pure(x, y, a);
}
function foo_pure(x, y, z) {
return x + y + z;
}
This doesn't make `foo` more functional or easier to test; but testing `foo_pure` is trivial. In particular this makes debugging logic errors much easier; since there's no need for elaborate/brittle test setup (eg. setting all the right globals, creating and cleaning up files, etc.).
Scrap the scare quotes, it is obviously false. Less code in the small does imply less code in the large. It doesn't need any justification, it is a tautology: if it takes less code to write all the small things in your program, the program itself will have less code overall.
Or did I misunderstood the meaning of "less code"?
Ok, sure, but I am sure there are related libraries for that kind of development. When talking about the real world, the majority of it is in web development or business apps.
