Talk:Cheryl's birthday: Difference between revisions
Type hints for the compiler are good, but not an alternative to semantic type comments for the reader
(Type hints for the compiler are good, but not an alternative to semantic type comments for the reader) |
|||
Line 69:
:: Functional composition is, in fact, and fortunately, simply one of the ways in which Python interpreters are actually used. That is why '''map''', '''filter''' and '''reduce''' entered the language, and that is why Guido simply failed, in the end, to expunge them, despite his strongest and most truculent efforts. Composition of pure functions has a higher entry barrier – it requires more concepts – but it yields more reliability, reduced debugging time, and greater code reuse. It is absolutely the right way to write good Python for some contexts, and for some users, and there is no value whatsoever in trying to shoe-horn real Python code (officiously, and frankly, somewhat ignorantly) into the residual shackles and deficiencies which Guido rather perversely and self-absorbedly sought to put in the way of composing pure functions, against the grain of the needs and better judgement of the Python community as a whole. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 15:56, 26 October 2018 (UTC)
==Type hints for the compiler are not an alternative to semantic type comments for the reader==
Paddy's addition of type hints is a very constructive and interesting idea, and useful spur to experimenting with the mypy type checker, which I have been wanting to do. His deletion of the informal Hindley-Milner style type comments from Python draft, however, probably arises from a misunderstanding, and simply deprives the reader of clarity about the semantics denoted by the function.
For example, it doesn't help the reader at all to replace:
'''uniquePairing :: DatePart -> [(Month, Day)] -> [(Month, Day)]''' with a bald '''(int -> Callable)'''
The type hints for the compiler, and the informal Hindley Milner type signature comments for the human reader serve two entirely different purposes, and are not at all in tension with each other. As the useful notes on this JS project point out https://github.com/ramda/ramda/wiki/Type-Signatures comments/annotation of this kind have become a kind of language-independent standard in functional programming generally. In some projects, like Purescript, they do have a role in compilation as well as providing clarity for the reader, but in other projects, like Ramda, they are entirely for the reader, and simply serve to summarise the semantics of the function in a brief and relatively standardized way. No need to deprive the reader of them simply on grounds of tribal shibboleth zealotry, border patrolling, or heresiology. A comment is just a comment. :-) [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 23:05, 26 October 2018 (UTC)
| |||