Talk:Modular inverse: Difference between revisions

(Good code returns correct results. Bad code and incorrect results are not in any way redeemed by being 'Pythonic' or 'Guidonic')
 
(2 intermediate revisions by the same user not shown)
Line 17:
Python is already a very useful language, now dwarfed in its scale, as a project, by the extraordinary number of excellent libraries which have been built around it, and which now constitute a major public resource. As a self-declaredly 'multi-paradigm' language, the core of which did gain some useful coherence from the BDFL period, Python nevertheless retains a severe limp and some real scar tissue from that period. Guido's energies, and the quality of his analysis, were very unevenly divided between the imperative and functional modes of the multi-paradigm spectrum.
 
Detailed and technically resourceful on 'for loops', his reasoning on functional code consisted of slightly somatic and regressive references to lemon juice and 'things that don't interest me'. In explaining his failed attempt to remove 'reduce' from the language, against the grain of the Python community's needs, he appealed, rather petulantly, to his own personal need to use pencil and paper when thinking reductions through – he had clearly never taken the time to get his head around the notion of a fold – a deeply universal and expressive structure which underlies most computation.
 
The badness (failure to produce a correct result) of Paddy's scrupulously 'Pythonic' example for his recent new task, arose *precisely* because it was written *within* the Pythonic/Guidonic imperative tradition, with all the excessive complexity of undermodelled states which value mutations and indisciplined loop breaks are heir to.
 
Now that Python has matured, and outgrown its BDFL infancy, that scar tissue can begin to heal (`reduce` will in time emerge from the purdah of `functools`, to which the dictator truculently relegated it when the Python developer community would not let him trash it) and the huge community of Python library users can begin to be better served by a genuinely multi-paradigm and less damagingly limping corpus of Python use.
 
Functional code optimises more for correctness, speed of assembly, degree of code reuse, and ease of refactoring, than for compression of time and space. That may well make it 'bad' for some contexts and projects, but it also makes it excellent, and clearly preferable, for others. 'Pythonic' and good are *very* far from being natural synonyms, and there is room on Rosetta Code for Python code which explores both main areas of the multi-paradigm space, and is optimised for various different contexts. 'Good' code above all returns correct results, and is well optimised for a particular organisational context. Bad code, and incorrect results, are not *in any way* redeemed by being loyally 'Pythonic' or 'Guidonic'. That mould has now broken. The young Python has broken its shell and emerged from its egg. A cause for celebration. Don't try to sellotape it back into the fragments. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 22:21, 25 October 2018 (UTC)
9,655

edits