Talk:Padovan sequence
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)
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.