I see mixed comments,
so let me add some praise.
I am one of countless, who match
his intro-filter:
repeatedly hearing 'enlightened'
people lament that the vast masses don't "get" lisp and FP,
and repeatedly attempting/failing to pick up the red string myself.
background - I am a computer science major with 30+ years experience. I did do a mandatory class of 'implement your own lisp' many eons ago.
It just never really 'clicked' for me.
I do, by accident, assimilation and lazyness,employ
FP style designs in my software.
And I guess fp techniques gradually rub off on me from e.g. javascript, lambdas,closures, and map-filter-reduce.
in particular, lambdas are useful to me.
But I am one of the guys who
continue to read the "let me tell you what monads really are", and every time I fall off the bicycle.
So, well, I appreciated this 'Xfor 5year olds" :-)
Lisp is "functional" in a 1970s sense in that it has functions as first-class objects you can pass as parameters to other functions, but those functions are basically subroutines which can have side-effects and un-functional behavior. As you allude to, this is pretty much par for the course in procedural languages now, and OO As She Is Spoke is procedural with some extra stuff added. Even garbage collection is common enough now that languages which don't have it trumpet the fact and make it their whole personality. Lisp is heady and revolutionary if your baseline is FORTRAN and maybe C, in other words, unless you actually do begin to write your own macros, at which point the C people begin to look at you funny.
Haskell is functional in that it demands its functions be functions, not subroutines. A function has inputs mapped to outputs and no side-effects. Functions can be composed and composition always works. Haskell uses monads to represent the regrettable fact that having an impact on the outside world is, in a very real sense, a side-effect, so it marks all side-effecting functions with an indelible stain. Haskell requires a different mode of thought from Python, or even from C++, and it's definitely not another Lisp.
To be fair, the fact that the IO Monad is in fact a monad is a sort of quality of life solution. Monads themselves don't have any side effect implications
I think Lisp is more on the liberal arts side of programming languages.
That the "enlightenment" of Lisp is that you can use functions everywhere. Write macros that look like functions and modify behavior, and build your code as a language.
Things like monads are more on the evolution of functional languages, and I also fall off the bike. It's as difficult as you want it to be, and I find scheme and lisp to be easier high level languages than javascript or python and makes more sense.
The Dan Friedman books are pretty good in general: "The Little Schemer,"
and the sequel "The Seasoned Schemer" which are both more "recursion" books. He also has another book "Scheme and the Art of Programming." Which I think is a great comp sci book that's not too difficult and doesn't seem too well known.
How to Design Programs is supposed to be a pretty good comp sci intro:
If we're naming names, for me personally, Lisp in Small Pieces by Christian Queinnec tops my Lisp books list. But, yes, only after perusing the SICP and The Little Schemer first.
my epiphany with lisp was that it is not a functional language in the modern sense, i.e. mutability is fine, loops are fine, etc. it's primarily a list processor, not lambda calculus.
background - I am a computer science major with 30+ years experience. I did do a mandatory class of 'implement your own lisp' many eons ago. It just never really 'clicked' for me. I do, by accident, assimilation and lazyness,employ FP style designs in my software. And I guess fp techniques gradually rub off on me from e.g. javascript, lambdas,closures, and map-filter-reduce. in particular, lambdas are useful to me. But I am one of the guys who continue to read the "let me tell you what monads really are", and every time I fall off the bicycle. So, well, I appreciated this 'Xfor 5year olds" :-)