Talk:Padovan sequence

From Rosetta Code
Revision as of 14:53, 19 March 2021 by Nigel Galloway (talk | contribs) (→‎Overnight graffiti: A case of déjà vu all over again)

Overnight graffiti

There was a spate of graffiti overnight, adorning the two Python versions as "Idiomatic" and "Unidiomatic" respectively.

People do feel strongly about their coding practices and their traditions of composition, but this a site for comparison, not for turf-wars or expositions.

The only interesting comment on a version is an alternative variant, and the only interesting measure of compliance with standards is the verdict of a linter.

Incidentally, FWIW, Pylint flags up various issues in the "Idiomatic" (sic) variant, including:

   Dangerous default value dict() (builtins.dict) as argument
   pylint(dangerous-default-value)

Shall we leave the aggressive labelling to kids, and just make more use of linters ?

Contributors can provide their own labels, where they really make the index easier to use. Hout (talk) 11:40, 28 February 2021 (UTC)

You have a valid point. Could you suggest some less-judgemental labels, maybe imperative/functional? --Pete Lomax (talk) 11:55, 28 February 2021 (UTC)
Thanks – good thought. Sometimes there is a clear (imperative | procedural) ⇄ functional divergence in the architecture of these things, but in this case, where both solutions are built from 'lazy' generators, the two approaches to composition converge quite a lot, and I don't think that separating labels are particularly illuminating or necessary.
The intervention here seems largely rhetorical.
(and possibly a bit-counter-productive from the perspective of the hostile party – it probably just increases the readership of the generic anamorphism variant).
My instinct would be to delabel, and just leave the flat sequence of alternative drafts intact. Hout (talk) 12:05, 28 February 2021 (UTC)
See below. You can't actually have "no labels", we just need to find useful and inoffensive ones. --Pete Lomax (talk) 13:45, 19 March 2021 (UTC)

As I stated on your talk page Hout, and without the personal attacks; One could write a lisp interpreter in Python and create examples for Lisp and a very similar example for Python that would pass a linter, but would not be idiomatic Python. You have ignored this and claim victimisation and bullying.

Your Python examples use functions that are standard in languages such as Haskel but are not mentioned as part of the standard Python distribution, (the style, as a whole was put to the community and rejected). You seem to do similar for Applescript in this task.

You could write similar libraries for concatMap, foldR, unfoldR, ... in C++, D, in fact in many languages and provide the same similar solution that passes a languages linter - which you know does not equate to a check for being idiomatic code, especially in these circumstances of how you write the code.

RC should not be filled by write once, translate by the same person to many language examples done on some treadmill, whilst ignoring how things are normally done in the target language. "It passes the linter" is a poor defense as I have pointed out, and you have ignored.

The idea of the site is to show idiomatic code examples for different languages. Hout, you flout that repeatedly.

I will, again, add the "improve" template to your Python submission, in the hope that you will refrain from pushing Haskel idiomatic code as idiomatic Python.

An aside: A large part of Raku's entries and updates where in getting the Raku style right - how Raku does things. That was great to see - I enjoyed other languages too because they showed off their languages quirks and idiosyncrasies. That is lost if they all just implement concatmap etc and adopt the Haskel-functional way - Which Hout is doing in Python, definitely; and possibly other languages too.

In short, some functional languages use an idiomatic style similar to that of Haskel. Python is not one of them. Many languages might compile or interpret this Haskel-esque style and pass their linters. This would not necessarily make the code idiomatic for that other language. Rosetta Code should strive for idiomatic examples in general - Hout is systematically attempting to pass off non-idiomatic Python in many tasks, not just this one.

--Paddy3118 (talk) 11:24, 19 March 2021 (UTC)

A number of misapprehensions there, though not quite enough to explain your insatiable hunger for trolling, graffiti and deletions, which a quick inspection of the Rosetta records shows to long precede my own contributions to this site, and clearly has sources entirely outside it.

  1. The goal of Rosetta Code is simply not as you describe it, and is clearly stated on the landing page. It includes 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.
  2. Languages do not (as you put it) "use styles". Coders and workplaces use styles, and they do so in varying contexts, seeking a varying balance of values. As the Python PEP 8 expresses very forcibly, "A Foolish Consistency is the Hobgoblin of Little Minds".
  3. "Foolish Consistency" is a direct translation of your own persistent misuse and abuse of the term "idiomatic", which features nowhere in Rosetta Code's own landing-page statement of its goals.
  4. Because languages are used in varying contexts, and within different traditions of composition (Imperative/Procedural vs Functional being the principle watershed) there will always be healthy disagreement between contributors to Rosetta Code. I happen, for example to find your Padovan code contrived, clumsy, and unclear. In short, a hack. Your code is also often poorly linted, shedding an ironic light on your hobgoblin misuse of the word "idiomatic". I would have significant misgivings, in a working context, about the reliability and maintainability of your contributions. Your most commonly used submission tag is 'Oops'. I absolutely do not, however, need to express that view on Rosetta Code. All I need to do is to enrich the Rosetta stock of contrastive insight – "to aid a person with a grounding in one approach to a problem in learning another" by contributing alternative versions.
  5. Because there will always be healthy disagreement on Rosetta Code, we have to rely on scrupulous use of the linter tooling provided by the language communities. Anything beyond that is entirely subjective, completely lacking in objectivity, and risks the rapid backsliding into the childish trolling which we are seeing here.


My suggestions to you are:

  1. Take the trolling elsewhere, or get help with it. Your deletionary zeal, and your aspirations to unearned authority have never been good, either for Rosetta Code, or for you.
  2. Improve the linting of your imperative code.
  3. If you disagree with the way in which I code, enrich Rosetta Code by contributing alternative submissions. Don't damage Rosetta Code with further trolling.
  4. Learn to spell Haskell. You will find the correct spelling in the first sentence of the documentation of the Python itertools module.

Hout (talk) 13:04, 19 March 2021 (UTC)

What we need to do here is find a way to label things that neither party finds offensive. Something with unfoldr in it, maybe, so I've (rudely) tried that, let's see whether that is acceptable. --Pete Lomax (talk) 13:26, 19 March 2021 (UTC) I will also suggest "Python: using a generator" instead of "Python: imperative".


Thanks Pete, I think what he's really addressing here is the 'Improve' notices which he's been slapping (every few hours, or sometimes even minutes) on the Python: Functional example in the N-Step Padovan task.
It's scrupulously linted for standards compliance, but he keeps screaming 'unidiomatic' (in an unwitting parody of PEP8) while declining to contribute a variant that he prefers.
The real problem, I suspect, is that he can see that the functionally composed versions of both Padovan recurrence functions (this one and the N step variant) are a little simpler and more expressive than his own contributions.
Perhaps he fears that others will notice that too ? Persistent graffiti and vandalism may not be the best response – they seem more likely to attract attention than to avert it ... Hout (talk) 13:50, 19 March 2021 (UTC)

A case of déjà vu all over again

I think this issue has been discussed at length, and that the Rosettacode Community has decided that these Python submissions are acceptable. The author of this solution has heard the bully's view and the continuous harassment is bullying, Rosettacode should take action against the bully. How can it be unidiotmatic to write a function in Python? Why is it unidiotmatic if that function is called unfold? I don't understand why a community outside Rosettacode which the bully feels he represents possibly has another option is relevant. Rosettacode should sort this once and for all.--Nigel Galloway (talk) 14:52, 19 March 2021 (UTC)