Talk:Practical numbers: Difference between revisions
m
→Rosettacode's purpose
(→Oh dear ... what is this addiction to angry vandalism ?: Haskell typing does not belong in so many Python examples.) |
|||
| (44 intermediate revisions by 6 users not shown) | |||
Line 1:
==One of many examples of using Haskell in Python.==
The following are excerpts from Houts Haskell and Python entries on [[Padovan n-step number sequences]] . Hout states that it is ''not'' Haskell typing and yet the valid Haskell type information ''is copied verbatim'' in the Python. It may have another name but he uses that
to hide that hie is deliberately obscuring Python by ignoring tits typing and substituting Haskell typing in examples.
Python has its own syntax for typing and its own syntax for typing in comments that is being deliberaterly ignored in by Hout who instead inserts abnother languages typing in Python examples. This is highly un-idiomatic, Python programmers learn would need Haskell knowledge to read this Python example, are highly unlikely to see this in idiomatic Python programs.
;Haskell:
<pre>
padovans :: Int -> [Int]
padovans n ...
recurrence :: Int -> [Int] -> Maybe (Int, [Int])
recurrence n = ...
main :: IO ()
main = ...
...
</pre>
;Python:
<pre>
# nStepPadovan :: Int -> [Int]
def nStepPadovan(n): ...
# recurrence :: Int -> [Int] -> Int
def recurrence(n): ...
# main :: IO ()
def main(): ...
...
</pre>
--[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 20:16, 1 April 2021 (UTC)
: Absolutely Donald – the Python and Haskell functions '''do indeed''' have the same type semantics, and the nested values defined by those two solutions '''are indeed''' intended to parallel each other, but those are '''comments''' in the Python code – '''very''' helpful to the mental clarity of the coder and reader, but, like any comment, '''not''' parsed by Python interpreters or compilers. They are not syntactic, they are not "in a language", they are just helpful comments, in a helpful and universal notation.
: The Python tooling is the only objective judge of whether I am doing what you call "using Haskell in Python". If I were, the interpreters and linters would very soon choke and tell us. No language that constrained the content of comments would be much use.
: Rosetta Code aims to show how languages are '''similar''' as well as different (as the landing page puts it).
: The composition of pure functions is not only a useful and coherent approach to general problem-solving, it is also deeply anchored in the underlying mathematics of function composition, and, like the Hindley-Milner notation which worries you, it is language-independent, and good at foregrounding what languages '''share'''.
: Are addition and concatenation Python 'features' ? Do we avoid them because other languages can also express them ?
: No. They are universal relationships which any useful language will have some way of expressing.
: Booleans and integers, and lists, tuples and strings are also sets of values which have mathematical and language-independent definitions, and we can represent these sets in more or less '''any''' complete and practically useful language.
: Hindley-Milner notation is useful precisely because it has a mathematical generality which lets us define (and reason about) value structures which are '''not''' language-dependent, and '''do''' help us think about how complex values can (or can't) click together into the patterns that we need. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 21:11, 1 April 2021 (UTC)
Hout wants to pass-off a Haskell like style of programming that was rejected by the Python community when put to members of the steering committee, as idiomatic Python. Hout wants to hide the Haskell style used and present his code as idiomatic Python when it is not.
--[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 20:16, 1 April 2021 (UTC)
: Ah ... so here we see the the focus '''already''' shifting away from an attack on '''comments''' to the admission of a broader intention to "discourage" the whole approach of composing pure functions in Python.
: Apparently the '''whole approach''' should be labelled "Haskell" or "not Python", and harassed ...
: You appeal to a story about "The Python Community", the details of which I haven't personally followed closely or been in any way involved in, though I '''am''' aware of not only of a largish literature on functional programming in Python, and of significant use of Python for this approach to composing code, let alone the acknowledgment in the opening paragraph of the Python itertools module of debts to languages like SML and Haskell,
: but isn't this the '''Rosetta Code''' community here ? Is dismissing my approach as "passing off" consistent with the goal of comparing and learning from '''different''' approaches ?
: I think we have a larger problem here ...
:[[User:Hout|Hout]] ([[User talk:Hout|talk]]) 21:11, 1 April 2021 (UTC)
:Incidentally, you make a statement about what I "want to do" (apparently this is "present my code as idiomatic Python")
: Well, how do you know ? Have you considered '''asking''' me what I want to do ?
: The answer is very simple, I want to contribute, to Rosetta Code, '''well-linted and reliable''' examples of how problems can be solved, by using Python to define and compose pure functions.
: I am very much aware that that is a minority approach. I happen, however, to find that it is a very '''good''', and actually rather interesting approach, which makes code more reliable, and faster to rewrite and refactor, and which increases levels of code reuse.
: I am certainly '''not''' alone in finding that to be the case. There's a whole literature on functional programming in Python.
: Others will take a different approach. The Rosetta value lies precisely in helping a person with a grounding in one approach to learning another.
: Divergent approaches are a form of '''wealth''' for Rosetta Code, not a source of threat.
:[[User:Hout|Hout]] ([[User talk:Hout|talk]]) 21:30, 1 April 2021 (UTC)
==Two of many examples of using Haskell in Python.==
Hout states that he is not using Haskell in Python below; until I show on this page what I had linked it is made too obvious for even Hout to sustain the lie.
Looking at function names used in this task and just one of the other tasks Hout has examples for Hout uses the names of many functions defined in the Haskell language in his Python, (and Applescript), examples, hiding that they are Haskell translations rather than trying to be idiomatic language entries - the kind of code the language community would have you write.
This table shows exact function names found in his examples that come with Haskell but not Python, which has it's own functional tools and library.
::{| style="text-align: left;" border="4" cellpadding="4" cellspacing="4"
|+ '''Functions defined in languages'''
|-
! Name || In Haskell || In Python
|-
| take || Yes || No.
|-
| unfoldr || Yes || No.
|-
| chunksOf || Yes || No.
|-
| primeFactors || Yes || No.
|-
| until || Yes || No.
|-
|}
Hout wants to '''pass-off''' idiomatic(?) Haskell as Python. He has denied this, and is now reduced to stating that it passes the linter; and personal jibes.
There is some progress however, Hout has taken on board that Python doesn't use Haskells <code>fst</code> function to get the first item in a Python list, for example.
I object to Houts lies and midirections in his attempts to pass off Haskell translations as idiomatic Python.
--[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 09:41, 2 April 2021 (UTC)
: Paddy I think we've already established that you disagree with my approach.
: (Those functions and function-names incidentally, are '''not''' peculiar to Haskell – they are part of a broader tradition of pure functional – i.e. mathematically based – programming. You will also find them, for example in SML, another of the languages to which the Python '''itertools''' module acknowledges a debt in the opening paragraph of its documentation. Borrowing functions and function names from that tradition is a well-established Python practice)
: All of that, however, is beside the point. We already know that you take a different approach. The question is, how to we '''handle''' differences of approach on Rosetta Code ?
: What is the solution ? (See the topic at the end of this thread for a summary of the solutions that various contributors have put to you, in the hope of some response).
: I notice that some rather dark themes are re-emerging in your discussion here. Are we now returning to the more exotic theories, perceptions and techniques which I thought you had put behind you in 2019 ?
:: See [Talk:Tree traversal - Rosetta Code]( http://rosettacode.org/wiki/Talk:Tree_traversal )
: [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 13:12, 2 April 2021 (UTC)
== Haskell type hints are not valid Python==
Hout, I have shown below that, contrary to your statement, you have used, and want to continue to use Haskell typing in a Python example. I have replaced the Haskell with Python typing. Please don't add Haskell typing to a Python example.
:: No, I don't want to use typing '''at all''' in small projects. Type '''comments''', however, are essential for clarity, during drafting, and also during refactoring. They serve a very different purpose from compiler hints, and they need to be much more human legible. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 21:10, 31 March 2021 (UTC)
Hout, Your arguments contradict yourself. You in one place state its not typing - then in another argue that your version is ''better'' than Python typing. You state that its not Haskell typing, and yet you use the same syntax in typing Haskell code as well as Python. You are dishonest! --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 19:27, 31 March 2021 (UTC)
:: Silly comment Paddy3118, I can't even follow it – no idea what you mean. Don't you think the Python linters and interpreters might '''notice''' if the syntax used was from another language ? You are worried that Bool is different from bool, and Int from int ? In a '''comment''' ?
:: I find it '''very''' useful to think in terms of a more general type semantics, and a clean notation for comments.
:: As we've seen, the Python type hints for the compiler, which you have insisted on (deleting my clearer comments) make the type of the key Python function there much '''harder''' to read. In fact, they are actually misleading, and make no contribution to the code ... The '''"Any"''' type symbol leads us to believe that '''any''' type will do in those positions, where as in fact any divergence from what my comments clearly show would simply cause the code to fail ... Is that what you are really hoping for ?
:: Would you prefer that I write my type comments in English ? They might be a bit verbose – MH is much quicker to read at a glance ...
:: I find it works very well for informal notes to the reader ...
:: I do understand that you take a different approach, but why delete ? Does it really feel so threatening to have two different approaches side by side ?
:: After all, that '''is''' what Rosetta Code is for ... and PEP8 does caution us against forms of compliance which diminish clarity without adding value. Compliance can be left to the linters, and doesn't protect us from writing code which is unreliable, hard to refactor, or simply slow. Very bad code and very unreliable solutions can easily be written in superbly "compliant" code. Compliance is not enough – its only purpose (read PEP8 again) is to serve clarity, in a given context, and contexts vary. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 21:05, 31 March 2021 (UTC)
::: Hout: '''So your response is that the comments are not typing, and that you cannot understand when I point to [[Padovan n-step number sequences]] and the [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-620004 Haskell typing] you added in the Haskell example being the same as the Python comments you added to your Python version?''' I use that as evidence of your comments being Haskell. Intentionally Haskell. You contradictory counter-claims are just that - You cannot prove my claim false.
::: I have updated and improved, (and certainly not deleted), your code to use Python typing and removed the Haskell typing as it is inappropriate to a Python example. Don't add it back. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 08:35, 1 April 2021 (UTC)
::: Comments are for readers, Donald, type hints are for compilers. Different goals.
::: You have '''repeatedly''' deleted my original version completely, each time I restored it for display in parallel to your formally typed version
::: I am '''very''' pleased, however, to see that you have now improved that typing to the point where it is no longer misleading and obscuring.
::: Very helpful to have both versions in parallel, in the proper Rosetta manner, for comparison. They aim for different things. Clarity for the reader in one case, formal type checking in the other. Thank you for putting in the effort to learn the type-hint notation and to debug that example. Enjoy !! I look forward to seeing you use more pure value-returning functions :-) [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 09:58, 1 April 2021 (UTC)
:::: In fact it looks like you've debugged all those compiler type hints – wonderful !! I hope that didn't take too long :-( [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 10:05, 1 April 2021 (UTC)
::::: The Padovan example shows that you add Haskell typing to Python examples. Your snide and inaccurate comments above show that you know Python typing and choose to ignore them in favour of adding Haskell typing information. I called you on it and you try misdirection and name calling. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 11:20, 1 April 2021 (UTC)
:::::: Take the olive branch when you get it :-)
:::::: We take different approaches, and the value and goal of Rosetta Code is to be able to look at differing languages and approaches (for example functional vs imperative, curried vs uncurried etc etc) side by side.
:::::: When projects are large, I '''do''' find that Python type hints are worth the extra work and testing.
:::::: When projects are '''small''', the approach that works well for me is to emphasize clarity, and save time, by just writing type '''comments'''
:::::: Its absolutely true that I '''could''' use the compiler hint notation in those comments,
:::::: but formal compiler hint notation is noisier – less clear at a glance. Not intended for comments.
:::::: I find that the simpler language-independent MH notation does work very well for comments,
:::::: and sometimes, if a project grows, or its context changes, I then translate to,
:::::: and debug, the more complex compiler type annotations.
:::::: I do understand that the sight of MH (you call it "Haskell") alarms your immune system, and looks like a foreign language to you.
:::::: (you have made that very clear, again and again. It's heard.)
:::::: but no language constrains the contents of comments – they are entirely up to the user –
:::::: and that notation, not least because it is brief, and language-independent,
:::::: is one which works well for me, and indeed, for many others.
:::::: We don't have to persuade each other.
:::::: If we did, Rosetta Code would have no content at all – it would first collapse to a single language, and then vanish entirely in a sulphurous puff of the One Truth and the One Way, for want of motivation.
:::::: One Rosetta Code we '''show''' different approaches. We don't need to '''tell''' them.
:::::: And we certainly don't need to "encourage" or "discourage".
:::::: We come here to share and learn, and think. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 12:05, 1 April 2021 (UTC)
::A long time ago when this started I read the PEP on Python typing. The document was the result of collaboration between a Python project and Cython. In order to compile their project with Cython, for efficiency they had to make changes to the Python such that it no longer ran in Python which they wanted to use for development (more fool them). The result is a type scheme which is written by humans, ignored by Python but read by Cython to produce more efficient code (could be called C typing rather than Python typing!!!). Them what be at Python encourage developers of official projects to use Python typing. Them what be at Python complain regularly that most submissions just use <b>Any</b> everywhere. Rosettacode is not Python and I don't care what them what be at Python think or want to achieve. Rosettacode is not the place for a self appointed spokesperson for them what be at Python to continually vandalize well produced and suitable Rosettacode submissions. The MH typing is meant to be deduced from the code by the compiler (good luck with that with a language like Python) and read by humans to explain functionality. The MH is richer than the Python typing and obviously is better as a comment (though I think it is an attempt to make a silk purse from a pig's ear), the Python typing would be needed if the object was to compile the code using Cython for efficiency.--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk:Nigel Galloway|talk]]) 14:28, 1 April 2021 (UTC)
::: Thanks Nigel.
::: The MH comments are just a brief summary to remind me of the value that I'm trying to define.
::: I could write them in English (to protect the nativist immune system from anaphylactic shock)
::: (though that would be wordier and harder to read at a glance – hardly a very obvious enhancement)
::: On past form though, I suspect that the "not to be encouraged" attack would then simply
::: shift its focus to new targets. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 15:30, 1 April 2021 (UTC)
==Python: Comment on type hints for the functional example==
Line 73 ⟶ 251:
::::: I suggest you learn more about Python then to understand your problem. No, your insistance that you are not adding Haskell typing to a Python program given the examples mentioned above, put you beyond reason. You systematically, and repeatedly add Haskell type annotations to your Python examples ignoring the Pythons typing wwhich includes Pythons type annotations as comments. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 16:26, 31 March 2021 (UTC)
:::::: How convinced are you feeling by the position that you are developing here ?
:::::: Python syntax distinguishes between comments for the reader and optional type annotations for a compiler.
:::::: Are you telling us that you reject that distinction ? (Your deletion labels appear to reject it now, with their talk of "Haskell type hints". Would such things parse ?). [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 16:02, 1 April 2021 (UTC)
==*Kick*==
Line 79 ⟶ 261:
: Repeated attempts to pass of Haskell as Python should not be encouraged. Hout has had many polite explanations that he chooses to ignore. I have translated his Haskell to Python type annotations in this case. Hout prefers the Haskell. This is a Python example. Your kick is misplaced. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 10:36, 31 March 2021 (UTC)
:: But that's not actually what you have done, is it ?
:: You've actually replaced '''comments''' with compiler hint '''code'''.
:: Not the same.
:: You are wasting valuable disagreement on crude deletion, when it could yield a harvest of additional material.
:: I have not "ignored" the expression of your views ("explanations" as you like to call them :-)
:: I simply '''disagree''' with them.
:: Disagreement is not a problem for Rosetta Code – it's an opportunity for additional parallel variants.
:: (Fortunately, we '''all''' disagree in our choices of languages and approaches. Without that disagreement, Rosetta Code would have no material).
:: "'''should not be encouraged'''" is a strange but illuminating phrase (I ignore your silly, tiresome and obdurate characterisation of my Python comments as "Haskell" :-)
Line 98 ⟶ 294:
::: I don't expect, given your exposed lie, that you will agree, but Rosetta code is about language comparison, which is not advanced when you try and pass-off Haskell typing as part of Python and then lie about it. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 16:17, 31 March 2021 (UTC)
:::: You know perfectly well that I am not "doing typing", and that I choose '''not''' to use compiler type hints on small Python projects
:::: What I definitely '''am''' doing is providing type '''comments''' in an MH format that is language-independent, and which I find clear and helpful, on language-independent type semantics.
:::: As we have seen in concrete examples that is much clearer, and '''much''' more Pythonically consistent with PEP8, than the misleading type hints which you installed after deleting my comments.
:::: If you wish to show a version of my code with type hints, that's up to you – their lack of clarity for the reader, in the context of curried functions, is instructive.
:::: You must not, however persistently delete my version, and then childishly scream "deletion" when I restore.
:::: You also know perfectly well that:
::::# I have *never* deleted any of your code and would not be remotely interested in doing so
::::# You have been consistently harassing and attempting to delete my code, on endlessly shifting grounds, for '''years''' now, despite other members of the community repeatedly calling you out for '''bullying'''. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 09:04, 1 April 2021 (UTC)
::::: Hout: '''You add Haskell typing to Python code, repeatedly'''. You seek to obscure this as an argument to use Language X's typing in language Y when language Y has typing of its own is untenable.
::::: Your code is improved ''Python'' when Pythoneers can read Python typing information instead of being confused and having to learn Haskell to follow your original. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 11:09, 1 April 2021 (UTC)
::::::We clearly mean different things by typing, but we don't need to discuss that here :-) Comments are just comments, the compiler ignores them, the coder and other users can find them useful.
::::::You say "Your code is improved when XYZ ..."
::::::I wonder if there is actually any meaning to words like "improved" if we extract them from particular contexts ?
::::::Even within a particular language, the balance of what we are aiming to optimise at any given moment, any particular piece of code, or any particular office, is '''hugely''' variable:
::::::# Reliability ?
::::::# Speed of writing under pressure ?
::::::# Levels of code reuse ?
::::::# Ease of refactoring later ? Possibly by others ?
::::::# Speed of execution ?
:::::: It seems unlikely that "improved" can ever have discernible meaning (beyond attempts at rhetoric :-) on its own.
:::::: It '''begins''' to have meaning when paired with things like "... in terms of X" or "... for the purposes of Y"
:::::: The trick is just be clear about '''what we are optimising for''' at any given point.
:::::: Formal type-checking hints, for example, require additional work and debugging, as you've just seen. Get them wrong, and compilation chokes, that costs real human time, the cost of which may be unrewarded.
:::::: Simple comments take almost no work, but provide no real type-checking.
:::::: Which works best ? We need to know the context.
:::::: The additional work will be worthwhile in some contexts.
:::::: The faster coding will be worthwhile in others.
:::::: Anyway, good work on those compiler annotations ! I appreciate the effort. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 11:33, 1 April 2021 (UTC)
== Create a new language code (my awkward attempt at a bit of diplomacy) ==
Can I just ask, would you (Hout) be opposed to creating a new language code? Call it anything you like: [[Python (Functional)]], [[Functional Python]], [[Python-H]], [[Phython]], and explain on that new Category page it is just standard Python [3] written with Haskell/MH type annotation comments (or however you want to phrase it), and perhaps add a link on the existing [[Python]] Category page to it. In fairness I have to ask whether you (Paddy/Donald) would object to such a link/category. It seems to me that could resolve this clash of styles and be independently useful anyway. (My apologies if that's all just crazy talk.)
Just so you both know, I have actually learnt a few things from these arguments, not that I'm suggesting they should continue. --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 13:06, 31 March 2021 (UTC)
Line 106 ⟶ 334:
:: Thanks – a new language code is an interesting and constructive thought, though it might also risk the fundamental health of Rosetta Code, by working around, and implicitly normalizing, this slightly dangerous and exogenous conception of "Encouraging" and "Discouraging" particular approaches, rather than simply displaying divergent approaches side by side, so that those familiar with one approach can learn about another.
I agree there is little reason to create a category of Python solutions based on how the code is documented. It seems to me that the
main way the solutions using Haskell style comments actually differ is the tendency to use currying to write multiple functions taking single arguments, replacing the usual Python way of making a single function taking multiple arguments. It does make sense to me to have someone create and index the subcategory of Python solutions that code in that way. --[[User:Wherrera|Wherrera]] ([[User talk:Wherrera|talk]]) 18:26, 1 April 2021 (UTC)
: Thanks Wherrera – that's a good thought.
: What I don't know is whether Donald/Paddy would feel that that was enough to enable him to then desist from interventions like replacing the comments with compiler type annotations.
: A problem with the result of making those annotations in my code (he doesn't, I think, generally apply them to his own code) is that we end up with an approach which '''nobody''' believes in.
:# Past interventions and comments have shown that he doesn't believe in the composition of pure curried functions, and
:# I don't personally believe in the cost/benefit of debugging type annotations for small (Rosetta-sized) Python projects. (This issue is well discussed on-line).
: i.e. the result would, if these interventions continue, be chimaeral, implausible, and not obviously an example of any coherent or sensible approach at all. (Perhaps that would seem like a welcome outcome to Paddy, but it would not, I think, be a good one for Rosetta Code.)
: (That is in fact the state of play with this task at the time of writing. He has repeatedly deleted attempts to show both approaches next to each other, insisting on retaining only the hybrid code that looks to him "compliant" (apparently the supreme value, crushing everything else, though, oddly, he often fails to lint his own code very thoroughly) and to me, implausible, chimaeral, and less clear for the reader than before).
[[User:Hout|Hout]] ([[User talk:Hout|talk]]) 18:57, 1 April 2021 (UTC)
:: See https://www.rosettacode.org/wiki/Rosetta_Code:Village_Pump/Discouraging_approaches
:: Can you advise me one how one adds such topics to the main listing of the Village Pump page ?
:::From the look of things new vptopic tags stopped working properly around 2015. --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 17:08, 1 April 2021 (UTC)
:::: Ah ... thanks. Sounds like I misread that. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 17:53, 1 April 2021 (UTC)
Line 117 ⟶ 361:
:: 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)
:::It is a shame that Donald has chosen not to respond. I agree it might not be ideal, but as that age-old saying goes: "The definition of madness is doing the same thing over and over again and expecting a different outcome." --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 17:08, 1 April 2021 (UTC)
:I like the way Wren has done this creating library pages under the main language page for each category of functionality. The tasks then just need to refer to something like Task::Python::Functional::Folding etc. --[[User:Nigel Galloway|Nigel Galloway]] ([[User talk:Nigel Galloway|talk]]) 15:16, 1 April 2021 (UTC)
::It would be really neat if they were available via CDN so entries could be run on tio etc without additional copy/pastes. I have not analysed these copf entries in any depth but I suspect many would be significantly shorter if they used a common lib. --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 17:08, 1 April 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)
==Acceptable Solutions ?==
We have a problem.
The Rosetta Code aim (defined on the landing page) "to aid a person with a grounding in one approach to a problem in learning another" is blocked here.
Disapproval of divergent approaches has again, after a respite of several months, degenerated into:
:# hostile retitling of entries as "unidiomatic", even when they are more thoroughly linted than those labelled "idiomatic"
:# hostile "improvement" notices applied to code that is working and linted
:# deletion of all type comments, and their replacement with compiler type notation which requires debugging and is less easily readable
:# multiply repeated deletions of attempts to show two approaches side by side.
:# rhetoric dismissing a particular approach as "not to be be encouraged" and not to be used with a particular language.
There is no need for us to change each others minds, but on Rosetta Code all contributors '''should''' be able to safely show a variety of working and well-linted approaches, without fear of "discouragement" and attack.
What is the way forward ?
Fellow contributors have suggested, as Wherrera puts it, creating and distinctly indexing the subcategory of Python solutions that code in a particular way. (My own description of the way that is again being attacked would be something like the ''composition of pure curried functions'', i.e. one approach to ''functional composition'' in general).
Particular suggestions have been:
:# A new language code, perhaps some variant of Functional Python, Curried Python etc
:# The labelling scheme used by Wren, leading to path names like Task::Python::Functional::Folding
:# Comments written in English rather than in the Hindley-Milner notation which you experience as "Haskell".
Paddy or Donald, you have not yet had a chance to respond to these proposals.
Can we ask you what it would take for you to feel that you didn't have to "discourage" approaches and views which differ from your own ?
Would you feel able to share with us why you were able to refrain from this kind of behaviour for a number of months, and have recently returned to it ?
It there anything we can do to help you "live and let live" again ?
[[User:Hout|Hout]] ([[User talk:Hout|talk]]) 07:23, 2 April 2021 (UTC)
== Rosettacode's purpose ==
Please keep in mind that the purpose of Rosettacode is to illustrate how a coding task can be implemented in multiple languages.
Please do not just delete code which was written with that purpose in mind.
If bulk becomes a problem, the code can be moved to a secondary page and linked from to the primary page. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 15:49, 2 April 2021 (UTC)
| |||