Anonymous user
Talk:List comprehensions: Difference between revisions
m
fixed section header name.
(→Ruby notes: new section) |
m (fixed section header name.) |
||
| (5 intermediate revisions by 3 users not shown) | |||
Line 1:
==Pop11 example==
The Pop11 example does not use the sort of syntax specified in the requirements. --[[User:TBH|TBH]] 09:22, 23 May 2008 (MDT)
Line 71 ⟶ 72:
--[[User:Kernigh|Kernigh]] 04:38, 4 February 2011 (UTC)
== Minor correction in Prolog code ==
I'm not a Prolog pro, yet I'm curious why define my_bind predicate, if it does the same thing as member predicate?
== What can we learn, in retrospect, from a defective Rosetta 'task' ? ==
All human works fall somewhere in between complete success and complete catastrophe, and nearly 8 years later, after much productive work, but also, frankly, after too many skirmishes, objections and actual or attempted deletions, it's all too clear that there was something about this 'task' which, from the beginning, didn't quite ring true for everybody, and which has continued to prove divisive, and less than entirely satisfactory, even in recent weeks.
What can we learn from this, with the benefit of hindsight ? What additional work on the framing of this question, back in 2007, might have yielded more value and less friction in the years that followed ?
Let's look at it in relation to Rosetta's 3 goals, which are captured well, and formulated clearly, on the landing page:
:# "The idea is to present solutions to the same task in as many different languages as possible,
:# 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."
'''As many different languages as possible'''
:'''Problem''' – An immediate failure in this axis. Many languages were effectively excluded by sacrificing Rosetta's principle of [[Rosetta_Code:Add_a_Task#Task_focus|Task focus]] to a preoccupation with a particular notation. This was immediately noticed and commented on at the the time, and was later argued to authorise moves to entirely delete notionally or notationally 'ineligible' entries for particular languages.
:'''Solution''' – In retrospect, more work should have gone into thinking beyond the surface notation, and clarifying the underlying class of problem. Entries could have been harvested from ''as many different languages as possible'' by framing the task in terms of efficiently defining and populating complex sets.
'''to demonstrate how languages are similar and different'''
:'''Problem''' – Not only was the number of eligible languages diminished by the slippage from task toward surface notation, but the scope for contrastive insight was also reduced. What is interesting about the definition and population of sets is that it can be done in various ways – for example with a monadic 'do' notation, with iteration, with structured recursion, etc. Ironically, the list comprehension notation, which is never part of core syntax, actually happens to conceal the variation in what is really going on in different languages. Python's list comprehensions are implemented, under the hood, as for loops (see http://morepypy.blogspot.co.uk/2008/06/list-comprehension-implementation.html) while Haskell's are syntactic sugar for a 'do' notation which in turn desugars down to lambda applications (see http://www.haskellforall.com/2014/10/how-to-desugar-haskell-code.html).
:'''Solution''' - Richer insight into the differences and similarities between languages could have been yielded by explicitly inviting demonstration of ''differing'' approaches to defining and generating sets. List comprehensions could have appeared as notationally elegant solutions, compared and contrasted with other solutions.
'''to aid a person with a grounding in one approach to a problem in learning another'''
:'''Problem''' – Reduced language coverage and reduced scope for insight converged here to offer no help at all to learners of some languages, and reduced insight for those whose languages were covered.
:'''Solution''' – Understandable distraction away from the underlying concepts (and core editorial values) by what was, at the time, a novel notation, could have been mitigated by a discipline of stepping through Rosetta's 3 core goals, using them both as a kind of check-list, and as a stimulus to raising the game, and reflecting a little harder both on what the underlying issues really were, what list comprehensions really were (useful syntactic sugar for deeper processes in the core syntax of particular languages) and on what it would take to reach the largest number of languages, and the deepest and most useful levels of contrast, comparison and insight.
The Rosetta stone was useful precisely because the focus was on meaning and task, without distraction by notation.
If Ptolemy the V had said "use all the languages of the realm, but ONLY if they are written in hieroglyphics" then the stone would simply have been another lump of granodiorite, with much less lasting value.
| |||