Anonymous user
Talk:Fusc sequence: Difference between revisions
→Deletion vs variation: On that paper...
(→Deletion vs variation: On that paper...) |
|||
| (5 intermediate revisions by 2 users not shown) | |||
Line 24:
:: My view (perhaps you will disagree) is that this sheds useful light on why it proves empirically rewarding (lower defect rates, higher rates of code reuse, less profligate use – and unscheduled interruption – of human time) to adopt functional methods of composition (particularly including avoidance, wherever possible, of mutable variables) in Python projects. Others have clearly had the same experience – we have only to look at the significant number of books and articles on functional programming in Python.
:: That article is also evidence for the helpfulness, particularly in the case of Python, of illustrating, next to procedural examples, how one might alternatively adopt functional methods of composition, including the relegation of any mutable variables to the internals of well-tested primitives. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 10:11, 12 March 2020 (UTC)
:::Hi Hout, your code isn't Pythonic, therefore making it much harder to understand. It is much longer, making it more error-prone and less maintainable. Worst of all, it is trying to write Haskel in Python, when the community at large rejected those extremes.
:::I'm with user Ledrug on this (as you know). --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 11:44, 17 March 2020 (UTC)
:::: We've heard all these arguments – no need to crank them out again – more helpful and Rosetta-ish to just write good procedural versions for any tasks which currently only have functional drafts.
:::: '''Pythonic''' - '''pylint''' and '''Autopep8''' are more rigorous and less subjective judges of that. It's clear that they haven't been applied to quite a lot of the procedural drafts on these pages.
:::: '''Readability''' varies with programming cultures. The procedural versions are there for those accustomed to threading through state changes, and the functional versions serve those familiar with immutability and functional composition, folds and maps.
:::: '''Haskell''' you will need, at some point, to learn how to spell :-) As for the language – it's essentially just math, which underlies all computations. Working with (rather than against) the math makes functional compositions much more likely to resemble each other across different idioms than the rather unconstrained complexities of the procedural state machines with which you do feel more at home, but which contribute, alas, to Python's unusually high bug rate (Davis 2014). [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 12:45, 17 March 2020 (UTC)
::::ps the paper you quote has its those questioning both its methodology and conclusions, as well as an industry that here's the hype and responds with less blind faith than they did for Lisp and OO before it. Python has a functional style that isn't what you push. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 16:01, 17 March 2020 (UTC)
| |||