Talk:Fusc sequence: Difference between revisions
m (changed section header name.) |
(Deletion vs variation) |
||
| Line 1: | Line 1: | ||
== another definition of fusc == |
=== another definition of fusc === |
||
<big>'''fusc'''</big>: ''adj.'' (color) dark-brown; dusky-brown |
<big>'''fusc'''</big>: ''adj.'' (color) dark-brown; dusky-brown |
||
:::::::: -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 22:05, 20 February 2019 (UTC) |
:::::::: -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 22:05, 20 February 2019 (UTC) |
||
===Deletion vs variation=== |
|||
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 deferred to the tooling. Checking Python submissions with tools like pylint and autoPep8, for example, is clearly sensible and constructive. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 10:30, 11 March 2020 (UTC) |
|||
Revision as of 10:30, 11 March 2020
another definition of fusc
fusc: adj. (color) dark-brown; dusky-brown
- -- Gerard Schildberger (talk) 22:05, 20 February 2019 (UTC)
Deletion vs variation
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 deferred 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)