4 ms·

Homoiconity, code as data, maros and DSLs aren't FP topics, but Lisp topics. FP has always been about preserving referential transparency when possible. That p

Homoiconity, code as data, maros and DSLs aren't FP topics, but Lisp topics. FP has always been about preserving referential transparency when possible. That philosophy is pretty evident in the difference between the more FP oriented Scheme and Lisp. Paul Graham is also a pretty poor example in my opinion. He has traditionally used a very Scheme like Lisp style. In 'On Lisp' he starts off by advising the reader to structure their programs by trying to keep side effects mostly in the outer layer of the program. He's not a FP purist who considers destructive procedures a sin, but he definitely advocated for immutability (just not under that name).

coldtea 7y ago
>Homoiconity, code as data, maros and DSLs aren't FP topics, but Lisp topics. FP discussion outside of the academic context (and especially on HN) before a certain date in the past 1-2 decades were all about Lisp(s) - and to a lesser degree Scheme(s). Doesn't matter whether that was "really FP" (real Scotsman), that what was was discussed, advocated, and practiced by most as "functional programming". ML(s) played very little into the discussion, and purity/immutability was discussed but not as the most important thing (rather as the more pure/mathematical version of FP, but not necessarily practical for professional programming, that came later, and Haskell and then Clojure popularized it).