Talk:Cheryl's birthday: Difference between revisions

# The former BDFL's visceral but unreasoned ('reminds me of lemon juice' etc etc) hostility to the composition of pure functions, and the disentanglement of value definition from IO, leaves the notion of 'Pythonic' *at best* limping on a pair of very uneven legs, with one (imperative) leg fairly muscular, and the other etiolated and deliberately shackled. In short, 'Pythonic' goals, well-defined and helpful for imperative coding, are quite '''deliberately''' bad, and completely dysfunctional, for functional code. This is a problem. Not an aspirational ideal.

# While 'Pythonic' constraints are good only for imperative code, mathematical constraints are deeply and inevitably structuring in the composition of pure functions. Research on, and exposition of, these constraints, and of their mathematical underpinning, can certainly use language-independent notations, (See the classic Bird and Wadler 1988, for example) but tends, in practice, to use Haskell/ML notation, and to adopt generic function names from the ML tradition (used even in Bird and Wadler), which serve as a kind of lingua franca for functional programming. The function names (and style of type annotations) used in Haskell (which is the main vehicle of the academic research) are also commonly used in projects aiming to strengthen the functional use of other languages. This is true not only of projects in other languages (see for example Ramda and other JS functional libraries) but '''even of Python itself'''. When Python library developers need names for functional abstractions, they '''also''', like others, naturally turn to the norms established by the ML/Haskell tradition. Haskell and Standard ML (SML), together with APL, are indeed '''explicitly mentioned''' at the top of the '''itertools''' documentation page. Hence we see in Python not only the standard functional terms like '''map''' and '''filter''', but also '''dropwhile, takewhile, groupby, cycle, repeat''', etc etc. In Python, as in other languages, when you need to strengthen functional muscle, established best practice is to turn to the Haskell/ML abstractions and names, which provide the widely shared lingua franca of the research.

 

The particular points of visceral resistance which you list above arise, almost without exception, from the difference between imperative and functional code, and from the scar tissue of Guido's now overturned dictatorship, which deliberately made 'Pythonic' guidelines incompatible with best functional practice.