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)

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)

Perhaps "concise" instead of "idomatic"? --Rdm (talk) 14:06, 2 April 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.

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.
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".
"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.
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.
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, and less than innocent bullying, which we are seeing here, yet again.

My suggestions to you are:

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.
Improve the linting of your imperative code.
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.
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)

Thank you Nigel. Hout (talk) 15:01, 19 March 2021 (UTC)

Thanks Pete Lomax for your attempt at mediation.

Hout, in amongst your repeated, tired vitriol, you don't address my accusations that you write in a style for one language and translate to others - and attempt to mask that. How else would Haskell type signatures appear in a Python script which has its own typing?

Your Applescript example has similar Haskell signatures as comments.

They are comments, so can get through linters, but its not Python typing. Its an artifact of your attempts to push a particular style of coding that stands rejected by the Python community. In the past, I seem to remember pointing out that you went as far as to create a function that came as standard in Python but not with the Haskell name. Your flow has improved since then, I think, but you seem to write once in Haskell or whatever, and translate to other languages without leaving explanation that you are doing so, and with the least respect for individual language norms.

--Paddy3118 (talk) 15:55, 19 March 2021 (UTC)

All of these questions have been asked and answered before.

You object to my comments, as if they were syntactic. They are not.

They are useful comments, maintaining clarity for the code writer and for the reader, because in functional composition every function returns a value, and successful composition requires clarity about the semantic type of that return value.

Hindley Milner type notation is not language-specific – it's a universal, language-independent and usefully compact way of representing the general semantics of types, in any language.

I find these comments invaluable, both for writing code, and for quickly refactoring it, and that is not your business.

If you wish to show a different approach, show it, and allow readers to obtain constrastive insight from it.

You say "I don't want RC to be flooded with XYZ"

That is not your business. Rosetta Code is not a venue for language wars or for the personal promotion or policing of particular approaches.

It is a venue for sharing contrastive insight in the form of differing solutions to the same problems, and its goals are those stated on the landing page. They are not those which you proclaim, in formulations of your own devising, possibly in genuine misunderstanding, but certainly in mockery of PEP8.

Rosetta Code is not a shop-window for parading (poorly linted) regimental uniform.

A bad soldier is not improved by a layer of uniform, and weak code is not made more reliable, or clearer, or faster to write or reorganise, by shrill proclamations that it is 'idiomatic', particularly when a standard linter is less than impressed.

If there was one Truth and one Way, the Rosetta Stone in the British Museum:

would display its message in one language in one canonical idiom, and
would therefore yield no contrastive insight, and be be of no interest whatsoever.
We would never have heard of it.
This site would not bear its name.

Hout (talk) 21:43, 19 March 2021 (UTC)

Nigel, On this being discussed and bullying. Hout fails to reply and states he is being bullied whilst ignoring points made. Even deleting them, and name calling. Do you also think it is right for RC to have code written for one language masquerading as being from another? Ignoring that other languages norms, repeatedly?

I don't. Hout fails to argue the point, instead crying bully. Can you not see the name calling?

I don't want RC to be filled with write-once auto-translated examples that may go through a linter, (If he is called on it), but tells you little about each individual language.

Hout, questions posed, or leave the template until this is resolved. You may feel bullied, but that is merely because your way is being questioned.

--Paddy3118 (talk) 15:55, 19 March 2021 (UTC)

"auto-translated" ? What on earth does that mean to you ? A few years ago you were actually asking for help on Reddit with tracking down a transpiler which you bizarrely imagined I must be using. Are you really drifting back into those fantastical eccentricities again ?

"write-once" ? Again, I have no idea what this means to you. Perhaps you disagree with Kernighan and Plauger's (The Elements of Programming Style, 1978) advice that we should aim, wherever possible, to write reusable functions ?

I personally think that it's not only a very sound (and very well established) approach, and one which contributes to productivity and code quality, but also happens to be an excellent match for Rosetta code, aiding contrastive insight at finer levels of granularity.

You have every right to disagree, but if you wish to contribute to Rosetta Code, rather than just vandalising it, it really is your duty to transmute that disagreement into the contribution of alternative functional drafts.

Deletion and harassment makes no contribution whatsoever to the contrastive insight which defines the value of both the Rosetta stone and Rosetta code – aiding a person with a grounding in one approach to a problem in learning another.

Hout (talk) 16:27, 19 March 2021 (UTC)

Incidentally, if the objection is simply to using a generic anamorphism, then remember that an anamorphism is a mathematical abstraction (dual to a catamorphism) which:

exists independently of any particular language,
turns out to capture what these three different Padovan generators have in common,
and can be implemented in any language which, like Python, supports higher order functions.

In the context of the defining Rosetta Code pursuit of contrastive insight into (quoting from the RC landing page) how languages are similar and different it then becomes instructive to explore both the similarities and and the differences, in how a generic anamorphism might be defined in each of the Rosetta Code languages.

This also enables us to foreground what is similar, as well as what is different, in each of the 3 Padovan generators.

Hout (talk) 17:53, 19 March 2021 (UTC)