I'm working on modernizing Rosetta Code's infrastructure. Starting with communications. Please accept this time-limited open invite to RC's Slack.. --Michael Mol (talk) 20:59, 30 May 2020 (UTC)

Talk:Fusc sequence

From Rosetta Code

another definition of fusc[edit]

fusc:     adj.   (color)   dark-brown; dusky-brown

-- Gerard Schildberger (talk) 22:05, 20 February 2019 (UTC)

Deletion vs variation[edit]

No need for the (very welcome) addition of a procedural Python version to entail deletion of the functional draft (now restored).

The goal declared on the Rosetta landing page (to aid a person with a grounding in one approach to a problem in learning another) is better served by the usual practice of adding variants than by unnecessary deletions. Variant drafts can illustrate differing approaches and traditions, and they provide much more eloquent and useful commentary on each other than any number of words will ever do.

The quality of code is a function of its optimisation for particular contexts. In practice, qualities such as reliability, levels of code reuse, and ease of refactoring will often prove more relevant, and more valuable, than the single-minded shaving away of the number of seconds consumed in run-time. Contexts and code cultures vary, and real legibility varies with coding traditions too.

Rosetta code does not claim, and is not equipped, to present unique and canonical versions. It is not clear that such versions could in any case exist. Issues of compliance are less subjective, and more rigorous, if delegated to the tooling. Checking Python submissions with tools like pylint and autoPep8, for example, is clearly sensible and constructive. Hout (talk) 10:30, 11 March 2020 (UTC)

I disagree (I'm the one who initially removed the old entry). I removed it not because it was slow (it was), but because it was insane. I agree that speed optimization is not the ultimate goal of this site, and I hope you agree that our goal is to be helpful for readers. The Haskell-styled python code is not helpful. How does a reader benefit from seeing it, besides the initial "Ooh, people do that?"
For the supposed high virtues you listed, I see none in the code entry. Reliability? It's not proven, and it is not easy to prove by wading through 11 def blocks to ascertain its logic. Code refactoring and reuse? It's moot because no sane project would want to reuse this code when it takes less time to write something simpler from scratch. Code culture vary, sure, that's why there is a Haskell section up there somewhere, where you can find beautifully readable code, because you know, it is actually Haskell.
If people come to read something in the Python section and sees this behemoth, it's a sign that we have failed miserably at being helpful. --Ledrug (talk) 05:24, 12 March 2020 (UTC)

We disagree, and that's very helpful and productive – it generates additional Rosetta versions, illustrating different approaches, and, in this case, even generates an additional comparison-pair (unknowingly and briefly broken yesterday) between the JavaScript draft and one of the Python versions.
Another constructive use of disagreement is stimulus to research and statistical analysis.
On the question of reliability, code defects and the attendant waste of human time (rather than machine time), you may find it interesting to read the statistical analysis in A Large Scale Study of Programming Languages and Code Quality in Github (UC Davis, Ray et al. 2014) which finds Python to be one of a small number of languages which are unusually defect-prone.
The authors of that paper conclude that the data indicates functional languages are better than procedural languages; it suggests that strong typing is better than weak typing; that static typing is better than dynamic;.
My view (perhaps you will disagree) is that this sheds useful light on why it proves empirically rewarding (lower defect rates, higher rates of code reuse, less profligate use – and unscheduled interruption – of human time) to adopt functional methods of composition (particularly including avoidance, wherever possible, of mutable variables) in Python projects. Others have clearly had the same experience – we have only to look at the significant number of books and articles on functional programming in Python.
That article is also evidence for the helpfulness, particularly in the case of Python, of illustrating, next to procedural examples, how one might alternatively adopt functional methods of composition, including the relegation of any mutable variables to the internals of well-tested primitives. Hout (talk) 10:11, 12 March 2020 (UTC)
Hi Hout, your code isn't Pythonic, therefore making it much harder to understand. It is much longer, making it more error-prone and less maintainable. Worst of all, it is trying to write Haskel in Python, when the community at large rejected those extremes.
I'm with user Ledrug on this (as you know). --Paddy3118 (talk) 11:44, 17 March 2020 (UTC)
We've heard all these arguments – no need to crank them out again – more helpful and Rosetta-ish to just write good procedural versions for any tasks which currently only have functional drafts.
Pythonic - pylint and Autopep8 are more rigorous and less subjective judges of that. It's clear that they haven't been applied to quite a lot of the procedural drafts on these pages.
Readability varies with programming cultures. The procedural versions are there for those accustomed to threading through state changes, and the functional versions serve those familiar with immutability and functional composition, folds and maps.
Haskell you will need, at some point, to learn how to spell :-) As for the language – it's essentially just math, which underlies all computations. Working with (rather than against) the math makes functional compositions much more likely to resemble each other across different idioms than the rather unconstrained complexities of the procedural state machines with which you do feel more at home, but which contribute, alas, to Python's unusually high bug rate (Davis 2014). Hout (talk) 12:45, 17 March 2020 (UTC)
ps the paper you quote has its those questioning both its methodology and conclusions, as well as an industry that here's the hype and responds with less blind faith than they did for Lisp and OO before it. Python has a functional style that isn't what you push. --Paddy3118 (talk) 16:01, 17 March 2020 (UTC)