Talk:Practical numbers: Difference between revisions

Content added Content deleted
Line 124: Line 124:
:: I would certainly never presume to edit it directly :-)
:: I would certainly never presume to edit it directly :-)
:: (I am more than content to do the proper Rosetta thing, and just submit a constrasting variant, illustrating the possibility of another approach). [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 13:21, 31 March 2021 (UTC)
:: (I am more than content to do the proper Rosetta thing, and just submit a constrasting variant, illustrating the possibility of another approach). [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 13:21, 31 March 2021 (UTC)

==Would the deletionary campaign continue if my type comments were in English ?==

You appear to believe that Rosetta Code is a vehicle for "encouraging" some approaches and "discouraging" others.

"Discouragement" in your sense appears to require active harassment and unilateral deletion and over-writing.

Your current animus and deletionary excitement has now latched onto my '''comments''' on the type of particular pure curried functions. Three points. One question.

:# I find the composition of pure curried functions works well in contexts in which I need to emphasise reliability, fast coding and refactoring and high levels of code reuse. Curried functions are particularly flexible when composing with higher-order functions, such as those which the Python itertools module documentation attributes to the SML / Haskell languages, and adopts gratefully, and with no hint of nativist resistance.

:# Working with pure curried functions requires '''clarity''' about types, both in drafting compositions, and in refactoring them later.
:# The Python type-hint idiom happens, alas, to be poorly optimised for clarifying the type of '''curried''' functions. It is designed to solve a different kind of problem (for the compiler, rather than the reader) particularly in much larger projects.

For example, my central function for this task was represented, in my Hindley-Milner type commments as:

<code># sumOfAnySubset :: [Int] -> Int -> Bool</code>

which shows at a glance (precisely what we need) that it returns a '''boolean''' value, and that its second argument is an '''integer''' value.

You keep unilaterally deleting this rather clear and simple comment, and replacing it with something quite different – '''a formal type hint for the Python compiler''' which, alas, is much less clear, and in practice, '''misleading'''.

In your angry and repeated edit, which fiercely insists on confusing comments with compiler hints, we can no longer see the return type, or the type of the second argument, and are now forced to waste time retrieving these types inductively by interpreting the code:

Here is what you keep writing (though the value of formal type hints for short Python scripts is known to be uncertain at best, and probably a waste of time):

<code>sumOfAnySubset(xs: List[int]) -> Callable[[Any], Any]</code>

Your own (slightly sheepish?) meta-comment above this is now '''"Note: Although mypy compliant, type Any below could be improved."'''

In other words, you are '''well aware''' that you have unilaterally made my code '''less''' clear, and you indicate that in your view, that clarity is less important than a certain conception of "compliance".

'''You are, in short, launching a direct attack on Rosetta Code''' (which aims to '''show''' varying approaches) and does '''not''' aim to eliminate them.

'''You are also launching a direct attack on PEP8''', which centrally reminds us that the goal should be to '''increase readability.''', and that "foolish consistency" is dangerously counter-productive and '''not''' at all "Pythonic".

https://www.python.org/dev/peps/pep-0008/#:~:text=for%20that%20project.-,A%20Foolish%20Consistency%20is%20the%20Hobgoblin%20of%20Little%20Minds,says%2C%20%22Readability%20counts%22.

Let me ask you two questions:
:# if my type comments were in English, would you still be repeatedly deleting them ?
:# what exactly do you fear will happen if my comments are allowed to remain in their existing MH format ?

I am far from being the first to find MH-style comments useful for clarifying and recording types in Python code.
Python does nevertheless appear to have survived ...

The Pythonic thing is to optimise for '''clarity''', the Rosetta thing is to show differing approaches '''side by side'''. Angry unilateral deletion, and the enforced reduction of clarity in the name of "compliance" is not just sad and foolish – it constitutes direct and disgraceful attack on the health and wealth of Rosetta Code, and on the principles of PEP8 itself.
[[User:Hout|Hout]] ([[User talk:Hout|talk]]) 20:01, 31 March 2021 (UTC)