I got in to it myself. And, early on, it was a real struggle. Like many, books like SICP, Little Schemer, On Lisp, were all powerful testaments to the family of languages. But those all came later.
I poked around Lisp, very casually, for many years. But early on I really struggled with `lambda`.
It was a meaningless word to me. The classic complaints with CAR and CDR et al didn't help. More meaningless words.
Finally, I managed to stumble across the book "Simply Scheme". And the first thing it did was rename everything. It didn't take long to realize that `lambda` was a function. And then, the light clicked on.
"Oh."
During my learning of computer concepts, etc. there were a few events of true "epiphany", and learning what lambda really was, and how it worked, closures, that was one of them.
The secret for picking it up is to just use it.
Not for some huge project, not for bolting together a bunch of pre-built libraries. But for some actual processing. Something that needs little more than to read some file, do something to it, and write it back out. Baby steps.
And, certainly, don't get intimidated by the development environments. I use emacs for my work simply because it paren matches and auto-indents. All of the integration, I don't bother with. My projects aren't that big. A few thousand lines of code. I'm spoiled by auto-indent (and re-indent), so that's my crutch.
The key point being it takes very little to get started.
Working the problems in Little Schemer is fun. Doing SICP exercises is fun. On Lisp is an inspiring, opinionated book, and fun to read because of it. So, you can start there.
Go "write Fortran in Lisp", as they say. All of the stuff about macros and lambdas and functional or not etc. doesn't do you much good when you're searching and staring at an 8 page document on LOOP. Just write some simple stuff to get familiar with the things every piece of code has to do: input data, calculate on it, iterate on it, and print it out. Looking up the stuff that's muscle memory for your other languages kills momentum and motivation. So, work some simple stuff first. Write some crummy code first, then work on idiomatic code. Work on using new concepts later.
I’m interested to know what are common epiphanies for developers.
For me, I can remember:
- objects are closures and closures are objects
- properly getting the JS asynchrony model
- pointers and the whole memory addressing model
- HTTP being stateless
I must have had an early epiphany with function return values, since I remember not writing functions correctly at first, but I don’t remember the actual epiphany.
I don't remember specifically what it was as I started quite young, but especially starting out there were a couple of major "lightswitch flipped on" a-ha moments like that.
I think realizing that execution in imperative languages was one after the other and that there's a sort of "cursor" that goes through the code (execution flow/instruction pointer/whatever) was one of the first things that made things click.
I miss them, as they were incredibly endorphin-releasing moments.
For me the big 3 were arrays, dynamic memory, and lambda/closures.
But I must admit, the day I saw a guy run, essentially, "cpio ... | rsh otherhost cat > /dev/tape", that was a very "aha" moment in terms of overall system design and what networking brought to the table.
I poked around Lisp, very casually, for many years. But early on I really struggled with `lambda`.
It was a meaningless word to me. The classic complaints with CAR and CDR et al didn't help. More meaningless words.
Finally, I managed to stumble across the book "Simply Scheme". And the first thing it did was rename everything. It didn't take long to realize that `lambda` was a function. And then, the light clicked on.
"Oh."
During my learning of computer concepts, etc. there were a few events of true "epiphany", and learning what lambda really was, and how it worked, closures, that was one of them.
The secret for picking it up is to just use it.
Not for some huge project, not for bolting together a bunch of pre-built libraries. But for some actual processing. Something that needs little more than to read some file, do something to it, and write it back out. Baby steps.
And, certainly, don't get intimidated by the development environments. I use emacs for my work simply because it paren matches and auto-indents. All of the integration, I don't bother with. My projects aren't that big. A few thousand lines of code. I'm spoiled by auto-indent (and re-indent), so that's my crutch.
The key point being it takes very little to get started.
Working the problems in Little Schemer is fun. Doing SICP exercises is fun. On Lisp is an inspiring, opinionated book, and fun to read because of it. So, you can start there.
Go "write Fortran in Lisp", as they say. All of the stuff about macros and lambdas and functional or not etc. doesn't do you much good when you're searching and staring at an 8 page document on LOOP. Just write some simple stuff to get familiar with the things every piece of code has to do: input data, calculate on it, iterate on it, and print it out. Looking up the stuff that's muscle memory for your other languages kills momentum and motivation. So, work some simple stuff first. Write some crummy code first, then work on idiomatic code. Work on using new concepts later.