On Wed, 26 Jul 2000, Eric S. Raymond wrote: > functional style: > > Refers to a language in which everything is pure function calls, without > side-effects or variables. Backus's F is one of the better-known > examples. LISP would be functional if there were no (setq ...). Typo, i think: that would probably be "FP". Quite cool language, from the guy also primary in bringing us fortran. > The advantage of functional language is the same as their disadvantage: > no side-effects. Makes them easy to reason about, but you have to jump > through hoops to do statefulness. I think "easy to reason about" in this case is mostly in the line of rigorous mathematic reasoning - algebraic/provability - than it is about approachability for novices/non-mathematicians! My impression is that in functional programming, you use functions to manipulate functions to get results - combinators, which are extremely powerful, expressively and mathematically, are also quite difficult to approach for the uninitiated. (I always thought APL presented similar challenges, but in the medium of programs as arrays/matrices.) I think one big advantage of the procedural style is how much easier it is for people to get what loops do, where applicative (map/reduce/apply) and combinatory logic operators are a lot harder. And list comprehensions as proposed capitalize on the greater approachability of loops. However, i do think a function like zip()/pairwise()/whatever can help for the tricky bit where the loop approach breaks down... (And i would be surprised if jeremy, who was steeped in MIT's scheme-based programming fundamentals curriculum, was asking for definitions. ?) Ken klm@digicool.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4