Talk:Fusc sequence: Difference between revisions

Content added Content deleted
(→‎Deletion vs variation: comparison and research – more helpful than shouting and fervour :-))
Line 21: Line 21:
:: Another constructive use of disagreement is stimulus to research and statistical analysis.
:: Another constructive use of disagreement is stimulus to research and statistical analysis.
:: On the question of reliability, code defects and the attendant waste of human time (rather than machine time), you may find it interesting to read the statistical analysis in ''A Large Scale Study of Programming Languages and Code Quality in Github'' (UC Davis, Ray et al.2014) which finds Python to be one of a small number of languages which are unusually defect-prone.
:: On the question of reliability, code defects and the attendant waste of human time (rather than machine time), you may find it interesting to read the statistical analysis in ''A Large Scale Study of Programming Languages and Code Quality in Github'' (UC Davis, Ray et al.2014) which finds Python to be one of a small number of languages which are unusually defect-prone.
:: The authors of that paper conclude that the data '''indicates functional languages are better than procedural languages; it suggests that strong typing is better than weak typing; that static typing is better than dynamic;'''.
:: The authors of that paper conclude that the data ''indicates functional languages are better than procedural languages; it suggests that strong typing is better than weak typing; that static typing is better than dynamic;''.
:: 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.
:: 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)
:: 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)