Talk:Evaluate binomial coefficients: Difference between revisions
Talk:Evaluate binomial coefficients (view source)
Revision as of 15:31, 24 February 2019
, 5 years ago→Please desist from deleting Functional Python examples
(→A Foolish Consistency is the Hobgoblin of Little Minds: It is not clear that you are speaking of the examples being disputed.) |
|||
| (28 intermediate revisions by 2 users not shown) | |||
Line 73:
: If you really think that your Python code is good, just let it shine in contrast to mine :-)
: Relax and allow others to judge for themselves – they will, anyway. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 08:18, 22 February 2019 (UTC)
:: I read your diatribe, and have noted my issues several times, above.<br> Your summary is misleading, (but our actions on the page seem to be converging). --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 09:44, 24 February 2019 (UTC)
::: We disagree, and that's fine - I have never deleted or interfered with your code, and I'm sure we can converge on an agreement that you don't continue to delete or interfere with mine, which is optimised for a different set of goals, and constructed and commented in a different way.
::: It must be difficult, and perhaps unexpected, to have Nigel and I reflecting back to you that your behaviour constitutes harassment and bullying, and I'm sure you would wish to avoid any repetitions.
::: A first step to helping yourself avoid this kind of behaviour might simply be to allow yourself the luxury of having an opinion, rather than depersonalising your pronouncements and seeking refuge behind imagined tablets of stone.
::: There is no need to replace a braver and more honest statement like 'I disagree with your summary' with a detached and unsupported olympian claim like 'your summary is misleading'.
::: Similarly, allow yourself to notice that your detached and impersonal expression 'hence the deletions' really means "so '''I''' deleted '''your''' work" – a real interaction between two real people.
::: If you can move away from depersonalising yourself, you will be in less danger of depersonalising others, and slipping back into unwitting bullying and harassment.
::: Give yourself a break. Allow yourself to have an opinion. There's no need to represent it as dissociated impersonal fact,
::: and there's no need to feel frightened or confused or angry about others having different opinions.
::: Nature is large and each human mind is a tiny candle. None of us really understands very much at all, and that's fine. As long as we cooperate, we can build cities, and sometimes even find our way to happy times and beautiful places.
::: In the meanwhile I'll compose code from pure functions, and annotate in a way that facilitates insight and Rosetta comparison, and you can write the kind of code that you prefer, and that has the qualities which you prefer to pursue.
::: Others can benefit from both, and judge for themselves what to emulate or avoid. That's their choice – not ours.
::: Happy coding and good luck ! [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 15:23, 24 February 2019 (UTC)
==A Foolish Consistency is the Hobgoblin of Little Minds==
Pep 8 starts with the following section:
Line 95 ⟶ 113:
: Thank you Nigel – I appreciate your kind comments and helpful observations. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 16:23, 22 February 2019 (UTC)
: Hi Nigel, It's a little more complex in example definition there are many functional examples, a comparison between functional and imperative is not the issue. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 18:45, 22 February 2019 (UTC)
:: Hi Donald, could you clarify that sentence ? (Perhaps some words are missing ? It doesn't seem to parse as intelligible English).
:: What is your view of the PEP 8 point that project consistency is more important than stylesheet consistency ?
:: Are you aware that your most recent edit (in which you have again deleted my original comments, replacing them with your own compiler type hints, and removed a number of my structural line breaks) has made the code less readable in more than one dimension, specifically '''against''' the recommendations of PEP 8 ?
:: Do you believe that it is up to '''you''' to decide whether or not the distinction between imperative and functional code is significant to other RC contributors ?
:: Is the gist of your somewhat evasive and (to be honest) unintelligible and syntactically unparseable sentence, that you intend to simply continue your campaign of '''bullying''' – abruptly deleting, or gratuitously reducing the quality of other people's code, even abusing privilege by '''locking down your own edits''', as if aggressively marking territory in the crudest canine tradition ?
:: Do you genuinely equate the quality of a piece of code with the degree of its consistency to your personal interpretation of PEP8 ? PEP 8 itself '''explicitly''' rejects that approach, as Nigel has reminded us ...
:: An Etonian accent is no substitute for (or guide to) intelligence or capacity, and 'foolish' guideline consistency is, as PEP 8 takes pains to make clear, no indication of (or lazy substitute for) reliability, readability, ease of refactoring, or general optimisation for particular and specific approaches and goals.
:: More importantly, '''theologising personal opinion''', treating it as authority to 'smite the wicked' – deleting and vandalising the code of other contributors (who never do this to you), is very bad for Rosetta Code, very bad for you, and very bad for Python. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 04:46, 23 February 2019 (UTC)
===Are type hints a good idea for RC Python examples ?===
I am very much in favour of static type-checking, so are the type hints now allowed by Python 3 a good idea for RC Python examples ?
[[User:Paddy3118|Paddy3118]] seems to suggest that they might be – he is not using them in his own examples, but he suggested an enthusiasm for their nativist credentials by deleting all my Hindley Milner type comments for the reader (mathematically based - used in comments across a range of languages and libraries, and in some languages used in the code to be read by the compiler) and replacing them with type hints for the compiler.
The main page now shows a side by side comparison – my original comments for the reader can be compared with the type hints for the compiler.
A few commments:
: The Python3 compiler tolerates, but '''does not use''', these type hints.
: The RC user could install the Python3 version of '''mypy''' and run a type check which did use them – my own test suggested that perhaps Donald himself had not done that – errors in the type annotations themselves were reported.
: The use of parseable type hints rather than comments introduces a '''larger surface for bugs''':
::Donald's first draft conflated the type of two functions which in fact had quite different type signatures, as had been clearly shown in the type comments which he deleted.
::His 'fix' of that bug introduced another bug, which created a Python3 compiler error (choking on a redundant square bracket)
::Once that compiler error was removed, an actual test with '''mypy''' revealed no errors in the code itself, but found more than one in the type hints (now fixed). To correct these, and to supply hints for functions over (or returning ) lists of items of various types, two additional symbols had to be imported from the typing module.
: For the human reader whose HM comments have been deleted, the parseable type hints to the '''mypy''' checker have a '''poorer signal to noise ratio'''. Cognitively redundant 'Callable' names are multiply inserted where HM needs none, each also bringing 4 additional square brackets. In some instances type names require lower case, in others upper case. The simply polymorphic HM `a` (any type) is replaced by the more verbose '''Any''' (or even '''typing.Any''').
:: For example, given an '''enumFromTo''' function which expands enumerations of any enumerable type,
:: (e.g. Char or Bool enumerations '''['a' .. 'z']''', '''[False .. True]'''
:: as well as Int and Float enumerations '''[1.. 10]''', '''[1.5 .. 10.5]'''),
:: The HM comment:
:::'''enumFromTo :: Enum a => a -> a -> [a]'''
:: (''A list of values derived from a start value and and end value of the same type'',
:: ''as long as that type is enumerable'')
:: is more informative to the reader, and less verbose, than the mypy type hint:
::: '''def enumFromTo(m: Any) -> Callable[[Any], List[Any]]:'''
:: Which is visually noisier, handles currying clumsily, and can not express the restriction to enumerable types.
: Additionally, the scope for Rosetta comparison is diminished – the links between implementations of standard abstractions across different languages are weakened and made less directly visible and comparable. (There are many Haskell, JavaScript, Python and ApplesSript examples on RC which use the same function name, and the same Hindley Milner type comments, for a given mathematically founded abstraction - we can learn a lot about a language, on a fine scale, by comparing these implementations).
: Increased bug counts for no actual checking by Python3 itself seems an unattractive deal to me. The 'nativist' argument for them (a purer or more Etonian Python accent – why adopt the broadly used Hindley Milner comments when our native Python allows actual type hints ?) makes no distinction between benefits to the '''reader''' and benefits to the '''compiler'''.
: It seems a pity, however, to impose something less readable on the reader, when the Python3 compiler:
:: 1) Makes '''no actual use''' of the type hints, i.e. receives no actual benefits at all, but
:: 2) Does throw compiler errors if the hints themselves are syntactically ill-formed, as they were in Donald's second draft.
: My personal verdict is that in languages like Idris, Agda, Haskell, where the compiler does use the type signatures, they are excellent and indispensable, but that in Python3, which doesn't yet use them, they are (at the scale of Rosetta Code examples) a nice idea, but no more in practice than a source of additional bugs, and, if used in place of type comments, just make things less clear and more difficult for the reader.
: Even Donald was clearly confused by them, assigning wrong types, and introducing (in what he presumably envisioned as an 'improvement'), both compiler and mypy errors ...
: On the scale of much larger projects, and as a complement to comments, rather than a substitute for them, the use of the '''mypy''' and the type hints which it can read, will doubtless begin to pay off the cost of the expanded bug surface which it initially introduces.
: For the small scale of Rosetta Code examples however - nice idea, but perhaps doesn't yet survive experiment, or actually benefit RC readers ? Maybe when Python4 comes ? [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 08:55, 24 February 2019 (UTC)
:: Donald [[User:Paddy3118|Paddy3118]]. Do feel free to introduce type hints into your own code - but please desist from deleting my type comments and replacing them with these hints. They damage the legibility of the code, demonstrably enlarge the surface for bugs, and in Python3, offer no benefit whatsoever to the compiler.
:: Not easy to think of a better example of the 'foolish consistency' against which PEP8 prominently warns on its opening page. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 09:02, 24 February 2019 (UTC)
| |||