6 ms·
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
by alayne 11y ago
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.
- collyw 11y agoYep, Django (or anything equivalent) will give you much more productivity in the real world than any of that functional style.
- istvan__ 11y agoI guess you were not joking but we are not talking about web development in this thread. How does Django help my embedded kernel development?
- collyw 11y agoOk, 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.
- chriswarbo 11y ago> What about maintainability? 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.
- denim_chicken 11y agoIt's only anecdotal, but I feel the opposite.
- chriswarbo 11y agoReally? I'd genuinely love to see some examples. 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.).
- istvan__ 11y agoHow about reading what I wrote before you reply? >What about programming in the large? less code -> less code at large -> win >What about efficiency of naive implementations? like a stack overflow version of it the starters always come up with in Java? what exactly are you talking about? >What about maintainability? What does FP or any of this thread for that matter do with maintainability? You can write unmaintainable code in any language. These are a very limited subset of what really matters in software engineering. (I would also remove the naive implementation part.)
- magmadiver 11y ago>less code -> less code at large that doesn't necessarily follow
- loup-vaillant 11y agoHow so? Your claim sounds "obviously false". We need an example.
- loup-vaillant 11y agoScrap 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"?