User talk:Hout
Repairing lost visibility of formula elements
Over the last six months, a well-intentioned but under-tested campaign of cosmetic edits accidentally eliminated the visibility of formulae (to the majority of browsers) in the task descriptions of over 60 different Rosetta tasks.
I have now restored the visibility of formulae to some of these tasks, generated a list of the tasks whose descriptions remain in need of repair,
(see below)
and added a note to the discussion page of each, identifying the date and time of the accidentally destructive edit.
I have, however, had enough of this now, and others are welcome to contribute to all or any of the outstanding repairs.
TECHNICAL NOTE Many of the inadvertently destructive edits accidentally choked the MediaWiki processor by introducing redundant spaces around the content of <math> tags, leading to the generation of defective HTML, and allowing only a minority type of browser to view the formula. Unfortunately, this turns out to have been the only kind of browser that was being used in the testing of the edits. The two types of browsers are: 1. The majority, including Chrome, Safari, IE, which display the <math> content from the 'fallback' graphic file on the server. 2. The minority, including FireFox, which, when requisite fonts are installed, generate the formula image by local processing of MathML expressions.
It is very important to test any edits involving <math> tags on both types of browser. Hout (talk) 22:22, 22 September 2016 (UTC)
Update
My thanks to user Wswiss for updating the Statistics/Basic page, which alerted me to the fact that I hadn't scanned tasks with a forward slash in their name, and that there are more damaged tasks (formula visibility accidentally removed during an under-tested cosmetic edit) than I had thought.
The current number of unrepaired tasks (with some or all formulae made invisible to most browsers), is 56.
In each case, the invisibility of formulae was caused by a specific edit, the date and time of which I have indicated in a note at the foot of the damaged tasks's discussion page. Hout (talk) 10:45, 24 September 2016 (UTC)
The current list (updated weekly) of damaged and repaired tasks is now at: http://rosettacode.org/wiki/User_talk:Gerard_Schildberger#Restoring_formula_visibility_to_50.2B_tasks_for_Chrome.2C_IE.2FEdge.2C_Safari_etc Hout (talk) 12:39, 7 November 2016 (UTC)
- Hi, I've marked few edits in the above list that I've made to fix the math visibility; I'm on Chrome/Win7Pro-SP1 and I see this problem too. -- WillNess (talk) 09:37, 15 October 2016 (UTC)
- Thank you ! I've added your repairs to the active list at https://rosettacode.org/wiki/User_talk:Gerard_Schildberger#Restoring_formula_visibility_to_50.2B_tasks_for_Chrome.2C_IE.2FEdge.2C_Safari_etc Hout (talk) 11:59, 15 October 2016 (UTC)
Tasks vs syntax demos - the case of List Comprehensions
Restored this on the grounds that it matches all three of the stated requirements:
- They should be distinct from (nested) for loops within the syntax of the language. - They should return either a list or an iterator (something that returns successive members of a collection, in order). - The syntax has parts corresponding to that of set-builder notation.
It uses no for loops, returns a list, and has the parts corresponding to set-building notation.
The previous alternative is useful, but is restricted to a smaller subset of JavaScript, and arguably uses for loops.
If we are to delete one, we should delete both, but I am not sure that either approach has much value.
Both examples are illustrative of such resources as JavaScript is currently able to provide for patterns of this kind.
- Hi Hout, unfortunately map & filter are the other way of doing things that are not list comprehensions. map&filter are arguably as well known a method as list comprehensions and some languages have both map & filter and list comprehensions as part of the language. The wp:List comprehension article also makes the distinction up front. Maybe I should add that fact to the task? --Paddy3118 (talk) 20:16, 7 September 2015 (UTC)
Clearly JavaScript 1.6 lacks built-in list comprehension syntax, and I understand your point, but this raises the issue of the value and purpose of of the Wiki. I would argue that users of Javascript seeking to solve the kind of problems that are addressed by list comprehension are better served by an example of how the resources of the language can be used than by a blank page.
Deletion might be intelligible if the purpose of the wiki was the support a narrow language partisanships or evangelisms ('my language has better built-in support for this than yours') but not if it is a public resource aiming to help those who look up a particular language under a particular heading.
If we were to delete that example, we would really also have to delete the preceding JavaScript example too (it uses a kind of for loop), and also the Mathematica example which is syntactically and formally identical. I am not sure that a chain of such deletions would really seem particularly constructive and helpful to users.
To concretise, why, for example, should we 'allow' users to find and reflect on the current Mathematica example:
<lang Mathematica>Select[Tuples[Range[100], 3], #11^2 + #12^2 == #13^2 &]</lang>
but not line 1 of the second JavaScript example:
<lang JavaScript>select(nTuples(range(1, 100), 3), function ([x, y, z]) {
return x * x + y * y === z * z;
});</lang>
These two forms are clearly isomorphic, but more importantly, they are both clearly of relevance and potential interest to users.
- Hi Hout. This task is specifically about list comprehensions as a syntactic construct. It could have been about select statements where it would not suffice to get the result using if/elif.../elif/else blocks - again they may be isomorphic as you say but we want the construct asked for not merely a way to get the answer. map& filter can get the result but it is not what is asked for. --Paddy3118 (talk) 21:08, 7 September 2015 (UTC)
I think we need to consult more broadly, to see how widely your understandable but perhaps slightly zealous appetite for deletion is felt to add value, rather than eroding it. Remember that when you asked to be allowed to do this kind of thing in the Discussion page, you were counselled to restrain yourself and restrict your targets to examples which relied on 'for loops'. This is not one of those examples. It uses functional set construction.
- Does it use a list comprehension? I think you must agree that it does not. In fact, this: [1] might give Javascript list comprehensions in 2016. If you had an interpreter with the feature you might state that the feature is experimental, give the link and code the task example and run it.
- The language spec I guess for now says that list comprehensions are missing but may be on the way. --Paddy3118 (talk) 21:40, 7 September 2015 (UTC)
Yes, it writes a list comprehension, precisely as requested, and precisely in the manner that will be most helpful and instructive to current JavaScript 1.5 and 1.6 users who
1. need to write a list comprehension, 2. want help with writing one in JavaScript, and 3. turn to Rosetta Code for help.
We may still be waiting for syntactic sugar for list comprehensions in JavaScript, but we can write them in any Turing-complete language which supports higher-order functions. All syntax "just rewrites" lambda applications. Even in Haskell the list comprehension syntax desugars down to Haskell's lambda primitives.
The syntax in which I have written that list comprehension is identical to that of the Mathematica example: a boolean lambda applied to a functional set construction, and that is precisely what lies under *all* the various syntactic sugars in which list comprehensions can be written, without nested for loops, in any language in which they can be written, including in JavaScript.
Your proposal would, inadvertently of course, have no other effect than to prevent users of JavaScript from using Rosetta Code to find out how to do that.
Is that really what you want ? I wonder if some slight confusion has arisen in your mind about the nature and structure of compilers and interpreters ?
- I think that filter, with an appropriate generator, satisfies the requirements of the list comprehension task. I think that requiring syntax instead would violate the Task focus aspect of Rosettacode. --Rdm (talk) 23:25, 7 September 2015 (UTC)
- Hi Rdm, unfortunately at least two sets of language implementors are seen to make the distinction in their language - having first had for-loops and map/filter, then bringing in list-comprehensions as a different syntactic construct at a later date: Python with its list comprehensions (expanded with other comprehensions at later dates), and now Javascript - the language example I am questioning.
- The task is about a particular syntactic construct. It does not go against my reading of your reference to Task Focus. Several languages, including popular languages, either already have or are considering adding the construct. The task is written to show those languages that have the construct.
- Admitedly we don't have many other tasks about language syntactic features, I have found Flow-control structures, Exceptions, Regular expressions, Loop Structures, Conditional structures, Function definition, and maybe Short circuit evaluation; but just as if a Task asks for a specific algorithm then that algorithm should be used, then I think that if a task asks for a specific syntax then that syntax should be what is shown - this applies especially to Javascript as it is made clear when in the future the construct might be added so telling you that before that date it is yet to be added.
- --Paddy3118 (talk) 06:28, 8 September 2015 (UTC)
No claim that a Rosetta task is 'about a particular syntactic construct' is consistent with Rosetta Code's editorial terms of reference, or with the unconflicted exercise of editorial impartiality. In combination with undisguised evangelism of particular languages, it risks the appearance of destroying content in the name of over-vigilant gate-keeping. It can not be in the public interest to redefine tasks as exclusive built-in sugar tasting parties, with irritable bouncers at the door.
The Haskell wiki puts it well at https://wiki.haskell.org/Syntactic_sugar
They make that point that syntactic sugarings don't add functionality to a language, they are plain textual replacements for expressions that could also be written in a more analytic way.
Your interpretation that "The task is written to show those languages that have the construct" would imply that certain languages are not invited because equivalent expressions can not be written in them. That is technically quite simply incorrect, it is clearly in violation of Rosetta Code's editorial terms of reference, and it is obviously without value to the public.
Excluding entries which show how equivalent (unsugared) expressions can be written may be consistent with the kind of Pythonic evangelism which you openly admit, but it can not be consistent either with public interest or with the actual technical nature of syntactic sugar.
The entries for languages that have a built in sugar may well be interesting and helpful as demonstrations of a particular idiom, but the entries for languages that lack such sugar are arguably even more interesting as demonstrations of how equivalent expressions can be written when sugar is not provided for free.
If you feel that entries of the latter kind should be deleted, you may have to ask yourself how productively you are able to handle a conflict of roles. Is the quality and impartiality of your editorial work enhanced or diminished by your admitted 'use' of the site for Python evangelism ?
- OK, I'll try to be a little more clear as to why I think my edits are justified:
- The task is about syntax. Having a list comprehension
- ECMA - the standards body for Javascript says that the construct may arrive in 2016 and gives an example of what they think the syntax should be.
- You give something other than the ecma proposed standard and argue that it should stand as an example of comprehensions in Javascript.
- Your use of the word sugar doesn't mitigate the above points. Your hint that my love of Python :-) is diminishing the quality of my argument would need further explanation - preferably with the regard to the points I have been making here, as I think your mention of Python is spurious.
- --Paddy3118 (talk) 07:59, 8 September 2015 (UTC)
I think we can agree to differ and leave it at that. The code and the introductory remarks have now both benefited from your interventions. Thank you for that, and for a stimulating discussion.
The points on which we take different views are perhaps:
- The editorial principle of Task focus. Your interpretation that tasks are "about syntax", or "to show languages which have XYZ" seem to me to violate that central principle. A difference of interpretation.
- Whether languages which lack a particular syntactic sugar should display blank pages, or should have illustrations of how the task can be achieved by writing an equivalent expression. I take the latter view, you appear to take the former.
- Whether ECMA's (welcome) proposal to introduce direct sugaring in the future is of immediate help to current users of existing JavaScript versions. I don't think that distant water relieves immediate thirst. Perhaps you do ? I don't know.
My concern about the notion that an editor can or should see themselves as an "advocate" of a particular language (hammers are "better" than saws ?) arises from your interpretation that it is legitimate to interpret tasks as "written to show those languages that have the construct".
A startling phrase, and one that logically leads (as we have seen) to 'edits' which are actually just wholesale deletions, as if there should be a Python entry in that list, but no entry for the versions of JavaScript that so many people are currently using.
As long as you are not going to attempt a deletion of the (syntactically identical) Mathematica entry too, I think we can leave things as they are and respectfully differ.
You appear to feel that syntactic sugar is just a word. That's fine. I think it's an engineering task (see https://wiki.haskell.org/List_comprehension) and I also think it is the heart of what we are discussing here. We just disagree, that's all.
Let's just set tasks, see how different languages can be used to achieve the same results, and be useful to the public.
No need to drift into this territory: http://www.explainxkcd.com/wiki/index.php/386:_Duty_Calls :-)
Two formulae invisible in the GAP contribution on Machin-like formulas
- I notice that two of the <math> tagged formulae in the preamble to your GAP contribution:
- are invisible on the majority of browsers. Chrome, IE/Edge, Safari and most other browsers all display the server-side graphic for formulae, and something about two of your <math> tag contents/contexts seems to be tripping the MediWiki HTML generator into producing ill-formed display tags for them (zero image height, because, in each case, of a missing semi-colon between two attribute names);
- Perhaps these formulae were originally edited on Firefox, which, (installed fonts permitting) uses local MathML processing rather than displaying the graphic file ?
- Iterative experimentation with any of the browsers mentioned above should make it possible to find a representation which is visible both on on the majority of browsers, and on Firefox too. Hout (talk) 13:10, 7 November 2016 (UTC)
- Hello. This is valid LaTeX. Do I have to infer that LaTeX is broken in RC? If so, I'll remove every equation I have written in the tasks. I'm not going to try to find what is not broken in the LaTeX renderer to fix the formulas: it's not even able to print "\sin x" in the Opera web browser. FYI, the site http://math.stackexchange.com makes heavy use of MathJaX, and everything is printed correctly in every browser I have tested. Same with Wikipedia: everything looks fine.
- Arbautjc (talk) 16:30, 7 November 2016 (UTC)
Faulhaber's formula#Python
Thanks to have added the note. I don't know how to change the formulas: they involve double sums with tricky indices, and they would hardly be legible as text only. On the other hand, they are not legible at all as is on many browsers. Not satisfying either way. Arbautjc (talk) 22:06, 22 November 2016 (UTC)