User talk:Hout: Difference between revisions

From Rosetta Code
Content added Content deleted
(→‎Non-Pythonic code: What '''is''' this angry, destructive, and fantastical obsession ? Do you have someone with whom you could talk about it ?)
 
(17 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==Repairing lost visibility of formula elements==

Over the last six months, a well-intentioned but under-tested campaign of cosmetic edits accidentally eliminated the visibility of formulae (to the majority of browsers) in the task descriptions of over 60 different Rosetta tasks.

I have now restored the visibility of formulae to some of these tasks, generated a list of the tasks whose descriptions remain in need of repair,

(see below)

and added a note to the discussion page of each, identifying the date and time of the accidentally destructive edit.

I have, however, had enough of this now, and others are welcome to contribute to all or any of the outstanding repairs.

TECHNICAL NOTE Many of the inadvertently destructive edits accidentally choked the MediaWiki processor by introducing redundant spaces around the content of <math> tags, leading to the generation of defective HTML, and allowing only a minority type of browser to view the formula. Unfortunately, this turns out to have been the only kind of browser that was being used in the testing of the edits. The two types of browsers are: 1. The majority, including Chrome, Safari, IE, which display the <math> content from the 'fallback' graphic file on the server. 2. The minority, including FireFox, which, when requisite fonts are installed, generate the formula image by local processing of MathML expressions.

It is very important to test any edits involving <math> tags on '''both''' types of browser. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 22:22, 22 September 2016 (UTC)

===Update===

My thanks to user Wswiss for updating the Statistics/Basic page, which alerted me to the fact that I hadn't scanned tasks with a forward slash in their name, and that there are more damaged tasks (formula visibility accidentally removed during an under-tested cosmetic edit) than I had thought.

The current number of unrepaired tasks (with some or all formulae made invisible to most browsers), is 56.

In each case, the invisibility of formulae was caused by a specific edit, the date and time of which I have indicated in a note at the foot of the damaged tasks's discussion page. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 10:45, 24 September 2016 (UTC)

The current list (updated weekly) of damaged and repaired tasks is now at:
http://rosettacode.org/wiki/User_talk:Gerard_Schildberger#Restoring_formula_visibility_to_50.2B_tasks_for_Chrome.2C_IE.2FEdge.2C_Safari_etc [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 12:39, 7 November 2016 (UTC)

: Hi, I've marked few edits in the above list that I've made to fix the math visibility; I'm on Chrome/Win7Pro-SP1 and I see this problem too. -- [[User:WillNess|WillNess]] ([[User talk:WillNess|talk]]) 09:37, 15 October 2016 (UTC)
:: Thank you ! I've added your repairs to the active list at https://rosettacode.org/wiki/User_talk:Gerard_Schildberger#Restoring_formula_visibility_to_50.2B_tasks_for_Chrome.2C_IE.2FEdge.2C_Safari_etc [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 11:59, 15 October 2016 (UTC)

==Tasks vs syntax demos - the case of List Comprehensions==

Restored this on the grounds that it matches all three of the stated requirements:

- They should be distinct from (nested) for loops within the syntax of the language.
- They should return either a list or an iterator (something that returns successive members of a collection, in order).
- The syntax has parts corresponding to that of set-builder notation.

It uses no for loops,
returns a list,
and has the parts corresponding to set-building notation.

The previous alternative is useful, but is restricted to a smaller subset of JavaScript, and arguably uses for loops.

If we are to delete one, we should delete both, but I am not sure that either approach has much value.

Both examples are illustrative of such resources as JavaScript is currently able to provide for patterns of this kind.

: Hi Hout, unfortunately map & filter are the other way of doing things that are not list comprehensions. map&filter are arguably as well known a method as list comprehensions and some languages have both map & filter and list comprehensions as part of the language. The [[wp:List comprehension]] article also makes the distinction up front. Maybe I should add that fact to the task? --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 20:16, 7 September 2015 (UTC)


Clearly JavaScript 1.6 lacks built-in list comprehension syntax, and I understand your point, but this raises the issue of the value and purpose of of the Wiki. I would argue that users of Javascript seeking to solve the kind of problems that are addressed by list comprehension are better served by an example of how the resources of the language can be used than by a blank page.

Deletion might be intelligible if the purpose of the wiki was the support a narrow language partisanships or evangelisms ('my language has better built-in support for this than yours') but not if it is a public resource aiming to help those who look up a particular language under a particular heading.

If we were to delete that example, we would really also have to delete the preceding JavaScript example too (it uses a kind of for loop), and also the Mathematica example which is syntactically and formally identical. I am not sure that a chain of such deletions would really seem particularly constructive and helpful to users.

To concretise, why, for example, should we 'allow' users to find and reflect on the current Mathematica example:

<lang Mathematica>Select[Tuples[Range[100], 3], #1[[1]]^2 + #1[[2]]^2 == #1[[3]]^2 &]</lang>

but not line 1 of the second JavaScript example:

<lang JavaScript>select(nTuples(range(1, 100), 3), function ([x, y, z]) {
return x * x + y * y === z * z;
});</lang>

These two forms are clearly isomorphic, but more importantly, they are both clearly of relevance and potential interest to users.

:Hi Hout. This task is specifically about list comprehensions as a syntactic construct. It could have been about select statements where it would not suffice to get the result using if/elif.../elif/else blocks - again they may be isomorphic as you say but we want the construct asked for not merely a way to get the answer. map& filter can get the result but it is not what is asked for. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 21:08, 7 September 2015 (UTC)

I think we need to consult more broadly, to see how widely your understandable but perhaps slightly zealous appetite for deletion is felt to add value, rather than eroding it. Remember that when you asked to be allowed to do this kind of thing in the Discussion page, you were counselled to restrain yourself and restrict your targets to examples which relied on 'for loops'. This is not one of those examples. It uses functional set construction.

:Does it use a list comprehension? I think you must agree that it does not. In fact, this: [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Array_comprehensions] might give Javascript list comprehensions in 2016. If you had an interpreter with the feature you might state that the feature is experimental, give the link and code the task example and run it.
:The language spec I guess for now says that list comprehensions are missing but may be on the way. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 21:40, 7 September 2015 (UTC)


Yes, it writes a list comprehension, precisely as requested, and precisely in the manner that will be most helpful and instructive to current JavaScript 1.5 and 1.6 users who

1. need to write a list comprehension,
2. want help with writing one in JavaScript, and
3. turn to Rosetta Code for help.

We may still be waiting for syntactic sugar for list comprehensions in JavaScript, but we can write them in any Turing-complete language which supports higher-order functions. All syntax "just rewrites" lambda applications. Even in Haskell the list comprehension syntax desugars down to Haskell's lambda primitives.

The syntax in which I have written that list comprehension is identical to that of the Mathematica example: a boolean lambda applied to a functional set construction, and that is precisely what lies under *all* the various syntactic sugars in which list comprehensions can be written, without nested for loops, in any language in which they can be written, including in JavaScript.

Your proposal would, inadvertently of course, have no other effect than to prevent users of JavaScript from using Rosetta Code to find out how to do that.

Is that really what you want ? I wonder if some slight confusion has arisen in your mind about the nature and structure of compilers and interpreters ?

: I think that filter, with an appropriate generator, satisfies the requirements of the list comprehension task. I think that requiring syntax instead would violate the [[Rosetta_Code:Add_a_Task#Task_focus|Task focus]] aspect of Rosettacode. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 23:25, 7 September 2015 (UTC)

::Hi Rdm, unfortunately at least two sets of language ''implementors'' are seen to make the distinction in their language - having first had for-loops and map/filter, then bringing in list-comprehensions as a different syntactic construct at a ''later'' date: Python with its list comprehensions (expanded with other comprehensions at later dates), and now Javascript - the language example I am questioning.
::The task is about a particular syntactic construct. It does not go against my reading of your reference to Task Focus. Several languages, including popular languages, either already have or are considering adding the construct. The task is written to show those languages that have the construct.
::Admitedly we don't have many other tasks about language syntactic features, I have found [[Flow-control structures]], [[Exceptions]], [[Regular expressions]], [[Loop Structures]], [[Conditional structures]], [[Function definition]], and maybe [[Short circuit evaluation]]; but just as if a Task asks for a specific algorithm then that algorithm should be used, then I think that if a task asks for a specific syntax then that syntax should be what is shown - this applies especially to Javascript as it is made clear when in the future the construct might be added so telling you that before that date it is yet to be added.
::--[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 06:28, 8 September 2015 (UTC)

::: Why is this unfortunate? Do you think that this concept of "syntactic construct" is about the arrangement of characters used to form it? Or is it about the results which it achieves? --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 07:34, 8 September 2015 (UTC)

No claim that a Rosetta task is 'about a particular syntactic construct' is consistent with Rosetta Code's editorial terms of reference, or with the unconflicted exercise of editorial impartiality. In combination with undisguised evangelism of particular languages, it risks the appearance of destroying content in the name of over-vigilant gate-keeping. It can not be in the public interest to redefine tasks as exclusive built-in sugar tasting parties, with irritable bouncers at the door.

The Haskell wiki puts it well at https://wiki.haskell.org/Syntactic_sugar

They make that point that syntactic sugarings don't add functionality to a language, they are plain textual replacements for expressions that could also be written in a more analytic way.

Your interpretation that "The task is written to show those languages that have the construct" would imply that certain languages are not invited because equivalent expressions can not be written in them. That is technically quite simply incorrect, it is clearly in violation of Rosetta Code's editorial terms of reference, and it is obviously without value to the public.

Excluding entries which show how equivalent (unsugared) expressions can be written may be consistent with the kind of Pythonic evangelism which you openly admit, but it can not be consistent either with public interest or with the actual technical nature of syntactic sugar.

The entries for languages that have a built in sugar may well be interesting and helpful as demonstrations of a particular idiom, but the entries for languages that lack such sugar are arguably even more interesting as demonstrations of how equivalent expressions can be written when sugar is not provided for free.

If you feel that entries of the latter kind should be deleted, you may have to ask yourself how productively you are able to handle a conflict of roles. Is the quality and impartiality of your editorial work enhanced or diminished by your admitted 'use' of the site for Python evangelism ?

:OK, I'll try to be a little more clear as to why I think my edits are justified:
:# The task is about syntax. Having a list comprehension
:# ECMA - the standards body for Javascript says that the construct ''may'' arrive in 2016 and gives an example of what they think the syntax should be.
:# You give something other than the ecma proposed standard and argue that it should stand as an example of comprehensions in Javascript.
:Your use of the word sugar doesn't mitigate the above points. Your hint that my love of Python :-) is diminishing the quality of my argument would need further explanation - preferably with the regard to the points I have been making here, as I think your mention of Python is spurious.
:--[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 07:59, 8 September 2015 (UTC)


I think we can agree to differ and leave it at that. The code and the introductory remarks have now both benefited from your interventions. Thank you for that, and for a stimulating discussion.

The points on which we take different views are perhaps:

# The editorial principle of [[Rosetta_Code:Add_a_Task#Task_focus|Task focus]]. Your interpretation that tasks are "about syntax", or "to show languages which have XYZ" seem to me to violate that central principle. A difference of interpretation.
# Whether languages which lack a particular syntactic sugar should display blank pages, or should have illustrations of how the task can be achieved by writing an equivalent expression. I take the latter view, you appear to take the former.
# Whether ECMA's (welcome) proposal to introduce direct sugaring in the future is of immediate help to current users of existing JavaScript versions. I don't think that distant water relieves immediate thirst. Perhaps you do ? I don't know.

My concern about the notion that an editor can or should see themselves as an "advocate" of a particular language (hammers are "better" than saws ?) arises from your interpretation that it is legitimate to interpret tasks as "written to show those languages that have the construct".

A startling phrase, and one that logically leads (as we have seen) to 'edits' which are actually just wholesale deletions, as if there should be a Python entry in that list, but no entry for the versions of JavaScript that so many people are currently using.

As long as you are not going to attempt a deletion of the (syntactically identical) Mathematica entry too, I think we can leave things as they are and respectfully differ.

You appear to feel that syntactic sugar is just a word. That's fine. I think it's an engineering task (see https://wiki.haskell.org/List_comprehension) and I also think it is the heart of what we are discussing here. We just disagree, that's all.

Let's just set tasks, see how different languages can be used to achieve the same results, and be useful to the public.

No need to drift into this territory: http://www.explainxkcd.com/wiki/index.php/386:_Duty_Calls :-)

== Two formulae invisible in the GAP contribution on Machin-like formulas ==

: I notice that two of the &lt;math&gt; tagged formulae in the preamble to your GAP contribution:

: http://rosettacode.org/wiki/Check_Machin-like_formulas#GAP

: are invisible on the majority of browsers. Chrome, IE/Edge, Safari and most other browsers all display the server-side graphic for formulae, and something about two of your &lt;math&gt; tag contents/contexts seems to be tripping the MediWiki HTML generator into producing ill-formed display tags for them (zero image height, because, in each case, of a missing semi-colon between two attribute names);

: Perhaps these formulae were originally edited on Firefox, which, (installed fonts permitting) uses local MathML processing rather than displaying the graphic file ?

: Iterative experimentation with any of the browsers mentioned above should make it possible to find a representation which is visible both on on the majority of browsers, and on Firefox too. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 13:10, 7 November 2016 (UTC)
::Hello. This is valid LaTeX. Do I have to infer that LaTeX is broken in RC? If so, I'll remove every equation I have written in the tasks. I'm not going to try to find what is not broken in the LaTeX renderer to fix the formulas: it's not even able to print "\sin x" in the Opera web browser. FYI, the site http://math.stackexchange.com makes heavy use of MathJaX, and everything is printed correctly in every browser I have tested. Same with Wikipedia: everything looks fine.
::[[User:Arbautjc|Arbautjc]] ([[User talk:Arbautjc|talk]]) 16:30, 7 November 2016 (UTC)

== [[Faulhaber's formula#Python]] ==

Thanks to have added the note. I don't know how to change the formulas: they involve double sums with tricky indices, and they would hardly be legible as text only. On the other hand, they are not legible at all as is on many browsers. Not satisfying either way. [[User:Arbautjc|Arbautjc]] ([[User talk:Arbautjc|talk]]) 22:06, 22 November 2016 (UTC)

: Thanks for looking at that – it does seem intractable at the moment, but at least we have pointed people to the possibility of viewing it in Firefox [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 22:09, 22 November 2016 (UTC)


==Pythonic code==
Hi, You've stated that you don't think PEP-8 applies to your functional code. Have you tried to get PEP-8 updated as yet?

Currently your code adds commentsabove function definitions, where it is "Pythonic" to add such - given your reasons for those comments, to the Python [https://www.python.org/dev/peps/pep-0257/ docstring].

The difference is shown here:
<lang python>In [29]: # concatMap :: (a -> [b]) -> [a] -> [b]
...: def concatMap(f):
...: return lambda xs: list(chain.from_iterable(map(f, xs)))
...:
...:
...: help(concatMap)
Help on function concatMap in module __main__:

concatMap(f)
# concatMap :: (a -> [b]) -> [a] -> [b]


In [30]: def concatMap(f: Callable) -> Callable:
...: """\
...: Returns a function of one argument, a list, that:
...: chains the results of mapping function f over its list argument.
...: """
...: return lambda xs: list(chain.from_iterable(map(f, xs)))
...:
...:
...: help(concatMap)
Help on function concatMap in module __main__:

concatMap(f:Callable) -> Callable
Returns a function of one argument, a list, that:
chains the results of mapping function f over its list argument.


In [31]: </lang>

You have the chance to write more Pythonic code but but instead continue to add Haskell translations, under the guise that "Guido hated, and stymied functional programming in Python; and that you know better". Fine, you should put this to the language community and convince them of your superior methods. Until then, ''Post Python and not converted Haskell''. If you haven't converted Guido's community, then its not idiomatic Python.

[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 10:44, 28 October 2018 (UTC)

===Functional Python and pythonic Python===
: 'Pythonic' Python is an excellent subset of Python, well optimised for many purposes, but it is not the Python language itself.

That is right. One can write bad code in any language; Pythonic refers to the communities best attempts at guidelines for writing good Python. [[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 16:12, 28 October 2018 (UTC)

: Some useful parts of Python, including parts of the language which are well suited, or even essential, to functional programming, lie outside the scope of the Pythonic idiom, which is deliberately optimised for standardisation of imperative programming styles.

: Functional programming is a distinct and well-established use of Python. There is an introduction to it in the Python documentation. O'Reilly distributes a book about it. Chapters are devoted to it in other books. There is extensive discussion of it online, and significant use of it in projects.

: It is not constructive to attempt to exclude functional Python from Rosetta Code on the grounds that it differs from the Pythonic idiom which (for excellent and understandable reasons) you personally like, respect and use. Others do use, and benefit from using, functional Python.

I don't wish to exclude one of Pythons three main coding styles, and don't seek to. You misrepresent me, deliberately. You act as if all of Pythons good practices are beneath you because functional is best. You substitute your own type comments as comments - no need for docstrings. You create new functions hiding builtins willy-nilly; you create new functions with the same functionality, but different names to standard library functions; In short, you ignore Pythons best practices with the excuse that "it's Python isn't it"?

If your ideas have merit, then you should b able to convince the Python ''community''. That community that built those same libraries and eco-system that you stated you use'. That eco-system exists because of the actions of that community you eschew. [[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 16:12, 28 October 2018 (UTC)

: You often explain that the notion of 'idiomatic' is central to your own contribution to Rosetta Code. I respect that, and find it entirely understandable. You are an intelligent person, and therefore will also have no difficulty at all in understanding that the goal of the Rosetta project, summarised on the landing page as ''to demonstrate how languages are similar and different, and to aid a person with a grounding in one approach to a problem in learning another'' will attract both readers and contributors whose interests have varying balances of emphasis on '''similarity''' and '''difference'''.

: Perhaps you feel that crowds gather around the Rosetta Stone in the British Museum to be inspired and elevated by the exemplary idiomatic purity of its parallel Greek, Demotic and Hieroglyphic texts. If that is your belief, then I am very happy to respect it. No problem at all. The value that I personally attach both to the Rosetta Stone, and to the eponymous Code project, lies, however, in what is '''shared''' between languages. Meaning, deep structure, universal functions, shared reducabilty, to the Lambda calculus and the operations of Turing machines. I personally happen to be less interested in the surface phenomena and the differences, but I have no objection whatsoever to others being more preoccupied by difference than by similarity.

: It worries you that my functional Python bears some resemblance to Haskell. For me, and, I believe, for some other Rosetta Code readers, that constitutes a virtue – a visible sharing, beyond superficial differences, of deep structure. It can be very instructive to compare the implementations of '''concatMap''', for example, in different languages. The (concat . map) composition itself is '''not''' given to us by Haskell. It comes from a much deeper and more interesting level of shared meaning – mathematics, from which in the last analysis, no programming language can successfully escape, or fail to be structured by.

Compare and contrast the rise and fall of the Lisp language. Also said to be based on maths, and originally from academia. Lisp has enriched later languages, but has gone from being "The Next Big Thing", with Lisp processors and Lisp workstations, to its current marginal use. Python has functional programming as one of many styles it supports. It may not have fully embraced functional programming as you would like, but maybe you to are blinded by your "Lisp moment". [[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 16:12, 28 October 2018 (UTC)

: Two technical points, and then a general one. '''First – consistent idiom''' – Our interests in Rosetta Code may diverge in the balance of our emphases on '''deep and shared''' versus '''surface and different''', but we do overlap, I think, in feeling that well-linted code has a value. We won't agree on which idiom of Python we find most useful, but we can agree that it is useful to apply linter tools. I apply Linter-flake8, and use AutoPep8, with all my Python code, both for Rosetta, and for my working projects. Let's move on, avoid subjective idiom wars – they seem a slightly silly waste of time – and defer to the tooling.

: '''Second - Semantic type comments''' I think that the use of informal Hindley-Milner style semantic type comments in my Python code may be near to the heart of your aversion to my functional Python style as 'too Haskell-like' (let's ignore the offensive references to machine translation :-). I find these semantic type annotions very helpful to my planning and reading of code, and perhaps, since we are only talking about comment lines in code, it should really be enough to say that they are useful. But in case it reassures you: (1) the Pep8 linters which I use have no objection to the position of my comment lines, and (2), I am far from alone in using such comments in functional Python, and in functional uses of many other languages outside the family of ML and Haskell. See, for example, some of the slides in this very helpful presentation: https://speakerdeck.com/kachayev/monadic-parsing-in-python

''I find these semantic type annotions very helpful to my planning and reading of code, ...''<br>
And yet you ignore the Pythonic style of adding them to docstrings or of adapting and using the type annotations that Python has. It looks as if you steamroll your way through that which inconveniences '''you'''. Rather than convince the community, you independently profess yourself a special case and that the guidelines don't apply to '''you'''. [[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 16:12, 28 October 2018 (UTC)

: '''Finally, a suggestion''' rather than fight for years over whether particular instances of functional Python are 'Pythonic' enough for you, (they are unlikely to be – some central elements of functional programming were deliberately excluded from the Pythonic tent, though the community refused to have them removed from the Python language) let us instead just accept that functional Python, while real, documented, written about and used, is nevertheless distinct from the 'pythonic' Python. I am very happy to go on using PEP8 linters, indeed I think it's a good idea, but why don't we just develop a practice of dividing Python contributions into two subsections: '''Pythonic''' and '''Functional'''.
: Let's stop the silly campaign of attrition though – I believe that the spirit of Rosetta is to be more inspired what is '''shared''' than by what is different, and frankly, I begin to feel harassed.

'''A (repeated) suggestion''': If your ideas have merit then you should be able to convince the Python community of its merit.
Your style seems singular. Members of the Python community do change the language. What is Pythonic does evolve, but standing on the sidelines shouting "Don't you see"!! might not be the best way to create a change toward your style. [[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]])

::: Unlike you, it seems, I have no interest whatsoever in converting anybody else's style of programming at all, and I ask you to respect mine. Functional programming is already, and inevitably, a well-established and documented use of the Python language, even if it in some tension with the 'Pythonic' subset of the language (which I am not alone in finding to be better optimised for some contexts and uses than for others).
:: You appear to be interested in changing my style in a way that you genuinely consider an improvement, and your addition of compiler type-hints was interesting, but also involved deleting important and useful semantic information, written in a format with which many users of functional Python are familiar and actively use (see, for example the presentation on monadic parsing in Python).

:: Enough now, I respect your beliefs about Python, and I quite understand that they will inform the code which you contribute.
:: You must however understand, that my use of Python is different, and that it is inappropriate for you to continue to interfere with it in this persistent and intrusive manner. I believe that my regular use of PEP8 linters more than meets the requirements of Rosetta Code, and I know that others feel the same. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 17:10, 28 October 2018 (UTC)

Harass. Defined as "Subject to aggressive pressure or intimidation". I am not being aggressive. I disagree with you - it happens. Intimidation: I don't slap an improve tag on your entry without stating why. Pressure: I am trying to improve your Python; we unfortunately disagree. [[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 16:12, 28 October 2018 (UTC)

:: Paddy or Donald, is not up to you, or indeed a dictionary, to determine whether or not I feel harassed by your behaviour. I do. Enough now. Please be kind enough to desist. We can agree to differ, and the Python language is large and expressive enough for us both to offer alternative solutions within the rich resources of its syntax and libraries, and differing currents and traditions, with the the help of a linter. Thanks. It has been stimulating, but that is more than enough now. Please stop. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 17:10, 28 October 2018 (UTC)

: If you don't like my functional Python word-break parsing code, for example, just create a 'Pythonic' sub-header, and contribute a 'version which feels more 'pythonic' to you. No need at all to berate me. A different approach and better version is a much more interesting and constructive mode of criticism. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 12:08, 28 October 2018 (UTC)

::Wow. The [[wp:No_true_Scotsman|no-true-Scotsman]] is thick on the ground. Hey, If Python doesn't want you, come on over to Perl 6. We've quite cheerfully stolen many of the good bits from Haskell and are always happy to see functional implementations of various tasks. (I personally am ''interested'' in functional programming, but I suck at it. 🙄) --[[User:Thundergnat|Thundergnat]] ([[User talk:Thundergnat|talk]]) 12:52, 28 October 2018 (UTC)

:::Thanks ! The resources of Perl have found a way through many difficult moments for me (most memorably 4Gb of badly formed CSV files, in which commas sometimes delimited fields, and sometimes just expressed English pauses :-) Python too of course – 4 years later a single 4Gb file of (better formed) CSV was swiftly handled by the Python CSVReader. Fortunately, functional programming remains a well-embedded and well discussed part of Python use, and an unimpeded route to all the Python libraries :-) The community made sure of that ... [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 13:02, 28 October 2018 (UTC)
::import The Unwritten Rules of Python<br>
::1. You do not talk about the GIL.<br>
::2. You do NOT talk about the GIL.<br>
::3. Don't even mention the GIL. No seriously.<br>
::Unlike Perl6, Python uses Reference Counting (like Perl5) not Garbage Collection. Locking the refCount is a major problem when multithreading. Python overcomes this by having a global lock, which effectively means that only one thread can run at any one time. So Python can multithread but only for reasons other than speeding up CPU intensive tasks. If you try running a CPU intensive task across more than one thread it will run about half as fast as single core due to contention for the GIL. You are thus not going to achieve some of the advantage you think you will with functional code in Python<br>
::The style you use must be acceptable as it is the method used in Python 1.6 'reduce(lambda x, y: x+y, range(1,101))' was then the way to sum a range. Comprehension was introduced in python2 so perhaps you could mark your examples requires python1.6 and paddy could mark his requires python2.<br>
::Some imperative languages eschew Break and Continue. Plaese, please, no seriously please tell me that [[Sexy_primes#Imperative_.28iffy_.26_loopy.29_Style]] isn't Pythonic--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk:Nigel Galloway|talk]]) 13:56, 28 October 2018 (UTC)

::: Indeed, in fact Python itself is not Pythonic – it contains (and many actively use) reduce, map and filter. There was a move from the ex-BDFL to reduce Python to the Pythonic dialect, but the PEP processes rejected it, and he is, in any case, after other frictions, now gone.

::: Set comprehensions are exactly the kind of thing that we need – practical and mathematically well-founded enough to inspire complete confidence, as well as powerful and elegant. In the word-break example (and sometimes elsewhere) I have shown the desugared underlying list monad version, not just because it can be interesting or more flexible to understand what's going on under the hood or bonnet, but also because my experience has been that the insight helps my intuition in using even the sugared version (in Python, Haskell or elsewhere) more fluently, and with more clarity. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 14:11, 28 October 2018 (UTC)

:::: On Perl-6 and Haskell I guess <code>TIMTOWTDI + Haskell == TIMTOWTDI</code>, little change.<br>
:::: Pythons idioms are used to allow libraries initially coded in other languages to act like native libraries and datastructures. The Python community believes it makes it easier to use such libraries as they are expected to act similarly and be more easily maintained.<br>
:::: P.S. I genuinely wish Perl-6 good luck (again). If its new ideas gain traction who knows, Python might add a library... :-)<br>
[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 16:12, 28 October 2018 (UTC)
===def is too sweet===
An important functional axiom is that functions can be assigned to names. In python def n(g) is sugar for n=lambda g:....
So writing def n(g)=return lambda g:.... is a bit silly. I've changed # enumFromTo :: Int -> Int -> [Int]
to 'enumFromTo=lambda m: lambda n: list(range(m,1+n))' in McNuggets to see if you agree--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk:Nigel Galloway|talk]]) 12:55, 2 February 2019 (UTC)

:: I absolutely agree. The '''def'''s are only there in deference to the PEP linters, which get puzzled and heresiological when names are bound directly to lambdas (as they clearly should be).
:: I've been deferring in this way to the linters in search of middle ground, and in the hope of averting pietist and deletionary attention (now incipiently resurgent I notice) [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 14:19, 2 February 2019 (UTC)
::: (All a matter of context, I suppose – we have all seen workplaces in which evidence of elocution lessons appears to be more highly prized than mere reliability or effectiveness :-) [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 15:23, 2 February 2019 (UTC)

==None Pythonic code==
Hi Hout, having read your comments it seems that:

# Your style has been ''rejected'' by the Python community . (From your attack on Guido and his views on functional Python).
:: You think so ? Why did the PEP process reject Guido's proposals to remove map and reduce ? Presumably because of a recognition of their usefulness. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 01:57, 8 March 2019 (UTC)
::: Deflection. You have been givenevery opportunity to show your styles accepatance and do not. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 04:24, 8 March 2019 (UTC)
# Your writing style, far from omitting, or selecting from what would be Pythonic, actively goes against it in some instances:
:# Use of function comments when docstrings were introduced into the language to replace them ''and'' add functionality.
:: I use both. Docstrings are very useful, especially when complemented by type comments above the line [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 01:57, 8 March 2019 (UTC)
::: Subvert one with the other. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 04:24, 8 March 2019 (UTC)
:# Of course, a central part of your style is the adoption of a type comment system at odds with the newly introduced Python type hint system.
::: 'Of course' ? Perhaps you are confusing type hints for the compiler with type comments for the reader. When you deleted all my comments and replaced them with type hints, you apparently didn't realise that you had introduced a number of bugs. You don't feel that that speaks for itself ? [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 01:57, 8 March 2019 (UTC)
:::: You failed to persuade the community that your comments should be adopted. You were able to both debug and correct the type hints it seems. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 04:24, 8 March 2019 (UTC)
'''I propose that you ''clearly mark your style of code with its name'' so readers know that it is special and follows alternate style rules and is not merely un-styled; or badly styled.'''<br>
You might also want to add a separate page explaining or linking to those style rules.

::: I disagree. '''Functional''' or '''Composition of pure functions''' is more than enough. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 01:57, 8 March 2019 (UTC)

That way people may add both styles of functional Python examples to the site, and read examples without confusion as to what is idiomatic.

::: There are various idioms. The 'Pythonic' subset of Python was never intended for functional programming, and is only partially applicable to it. PEP 8 warns strongly against confusing 'foolish consistency' with code quality. The former is no substitute for (or guide to) the latter [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 01:57, 8 March 2019 (UTC)

:::: Your style is cross-language and you refuse to follow idioms that apply. Fine, but don't try and pass such off as idiomatic Python, in fact state what style it adheres to because you put your style above the Pythonic. Stop the subterfuge.--[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 04:24, 8 March 2019 (UTC)
I would suggest you use a sub-heading of:
: <h4>Python: Hindley-Miller style</h4>.

::: I disagree. '''Functional''' or '''Composition of pure functions''' is more than enough. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 01:57, 8 March 2019 (UTC)

:::: Further hiding your personal style. Name your style and state that it is an alternative and let the community decide rather than hiding it. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 04:24, 8 March 2019 (UTC)

--[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 23:46, 7 March 2019 (UTC)

:: Hindley-Miller (sic?) Is not a style of coding. Please learn a little more about functional programming before you make these unhelpful and uninformed interventions.
::: Then name to disambiguate. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 04:24, 8 March 2019 (UTC)
:: I am using PEP linters.
::: From the code you produce, ineffectively. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 04:24, 8 March 2019 (UTC)
:: Functional programming in Python is a minority use, but useful and legitimate. I am sorry that you find it threatening and disempowering. There is no need for you to feel that way.
:: If you prefer a different style of coding please use it, but please also stop this childish campaign of harassment. [[User:Hout|Hout]] ([[User talk:Hout|talk]])
::: I don't have an issue with functional programming, (I use that style of Python and other languages myself); You raise this to deflect the reader from the issue that you want to promote a distinctive, non-idiomatic style of coding as idiomatic. You use a poor substitute for function docstrings and replace idiomatic type hints with your type comments, without notice/warning.
::: If you prefer a different style of coding please use it, but please also stop this childish campaign of hiding it. Write it up! Shout it out! Are you not proud of the claimed superiority of your changes? Don't be sly. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 04:24, 8 March 2019 (UTC)
<br><br>So you chose not to disagree with my assesment that your style of coding was rejected by the community.<br>
You don't disagree with my points showing two fundamental ways in which your style ignores guidelines.<br>

I asked you to name your style and after many months, you gave a link to Hindley-Miller.

You state that you use "PEP linters" but make no mention of my specific points on good Python style that you flout. Tools and/or there use can be subverted or mentioned as misdirection.


It seems that:
# You promote a style of functional programming that is different the Python idiom.
# On not persuading the Python community to adopt such a style you intend to flood RC with your coding examples and need to have them masquerade as idiomatic Python.

I have no wish to stop you adding your example code, but I think it is underhanded and subterfuge on your part that is aimed at confusing the readership as to what constitutes idiomatic Python.

:: Such a silly and eccentric comment that I'm not sure it really needs an answer [[User:Hout|Hout]] ([[User talk:Hout|talk]])
::: Hmmm. Thhe comment's correct then. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 04:24, 8 March 2019 (UTC)

* Name and disambiguate your non-idiomatic Python examples.
* Don't remove content aimed at doing the above.
--[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 01:55, 8 March 2019 (UTC)

:: Donald this is all slightly strange and angry fantasy ...
:: "''On not persuading the Python community to adopt such a style you intend to [XYZ]''"
::: What makes you feel that I have ever tried to persuade 'the Python community' to a adopt a coding style ?
::: What is this 'rejection' that you are talking of ? I am not aware that anyone (apart from you, it seems) is or ever has been remotely interested by whatever aspect of my linter-compliant functionally-composed code so frantically exercises you. The comments ? It seems an odd kind of windmill to charge at .... [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 07:26, 8 March 2019 (UTC)
:::
::: And then, it grows even more bizarre ... "''you intend to flood RC with your coding examples and need to have them masquerade as idiomatic Python.''"
::: What ?
::: I am writing functional code in Python, not particularly (beyond compliance with the PEP8 linters) within the 'Pythonic' subset (its well known that that idiom is better optimised for procedural than for functional code - even reduce is deprecated)
::: Have I '''ever''' used the term 'Pythonic' to label or describe my code ? It's not a term I even think about – certainly not a totem that I wish to lay claim or waste to. The PEP8 linters are very helpful - but beyond that I am frankly more interested in whether or not code works, and how efficiently I can write and maintain it.
::: 'Pythonic' is simply not (and has never been) a word that I use, lay claim to, wish or have ever wished to influence or even, frankly, think about very much. I prefer to leave that to the (excellent) tooling.
::: I '''am''' interested composing pure functions wherever possible, simply because it works for me, and seems to lower the bug-count and time spent.
::: I am not alone in finding this a good and theoretically well-founded approach, but I have no interest in persuading anyone who doesn't like it, or feels somehow threatened by it ... [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 07:26, 8 March 2019 (UTC)
::: What on earth are you really talking about ?
::: Do you genuinely expect us to take all this seriously ?
::: Did you really expect us to take it seriously when you decided that my code was automatically generated by a machine ?
::: What '''is''' this angry, destructive, and fantastical obsession ? Do you have someone with whom you could talk about it ? [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 07:26, 8 March 2019 (UTC)
::: Good luck and good health to you. Enjoy your coding. Please leave mine alone. It is Python, it's not over-strictly Pythonic, though it is linter-compliant. It have never labelled it as 'Pythonic'. It does use map and reduce. So what ? [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 07:26, 8 March 2019 (UTC)

Latest revision as of 17:32, 18 March 2021

Retrieved from "https://rosettacode.org/wiki/User_talk:Hout?oldid=260587"