Lisp & Thinking in lisp

Wed, May 20, 2020 2-minute read

I am finally able to write common lisp code. Frankly, though, I don’t think I have arrived as far as Lisp goes. You can take a look at some of my work here:

Learning to write code, looking through CLHS for usage and figuring out a workable solution in a near-functional manner is how far I have gotten. I don’t yet know to write a macro. I mean, I know the construct to create a macro. But I am yet to arrive at a place where a macro would solve the problem in a more elegant manner. I am sure the mentors on the site are able to see multiple macros in my code, though.

But learning even this much has had its benefits. My python code has improved a tonne. I write functions with very little side-effects, I don’t alter the incoming arguments and the like. And my python code also looks a lot cleaner. I still don’t write fully functional code in python either. I don’t compose functions, or use partials or the like. My most functional code is when I use maps and reduces 🙂

The problem I am tyring to conquer now and which I expect will make me a better programmer is this: think in Lisp. I don’t think in Lisp at all. I mentally solve my problem in python and then transcode that in Lisp – manually. If you see the iterations in the exercism solutions, this should be immediately apparent. But ideally I should think in Lisp when I try to solve the problem in Lisp. Because I can easily see why the language is so powerful – there is so little syntax, if you think about it. It is infinitely extensible (many other languages are too) and brings in very little in the form of an opinion. I really see why so many people swear by this language.

That’s the next step for me. To hone my ability to think in Lisp. It takes a while but I am sure I’ll get there.