4 ms·

Really interesting read for me as an experienced Go developer currently learning Lisp. Not sure if I will ever use Lisp or this for a real project, I see it mor

Really interesting read for me as an experienced Go developer currently learning Lisp. Not sure if I will ever use Lisp or this for a real project, I see it more as some kind of Sudoku in code, and a indirect training ground for Elixir (which is a wonderful complement to Go for backend tasks).

codr4life 10y ago
Do it. I spent years nervously fingering On Lisp on lunch breaks without really getting anywhere. But Paul Grahams early essays kept pulling me back into Emacs, and on each iteration something fell into place. It me took a long time to feel comfortable, but I wouldn't trade the feeling for anything. It's an alien chain saw; chain saws are intimidating enough in themselves, one with completely alien controls and instructions even more so. To paraphrase Graham, power looks weird from below.
progman 10y ago
I use Common Lisp for real projects. My recommendations: - Always follow the KISS principle (https://en.wikipedia.org/wiki/KISS_principle https://en.wikipedia.org/wiki/KISS_principle). Don't use Lisp's "super features" too much. The same applies to Haskell, by the way. - Use QuickLisp as much as possible. In many cases you don't need to add your own lib. Read Quickdos [QDC]. - Comment your code well, even if others don't ever see it lest you could not be able to understand your own code later. What's the purpose of the function, which arguments are expected, of which expected type are they, what are the possible results, possible side effects, etc. - Read and understand how Lisp's package system really works. This is important to avoid strange behaviors in your own code. - Use SLIME (https://common-lisp.net/project/slime/ https://common-lisp.net/project/slime/). It is an awesome interactive debugger which catches bugs and presents different options how to deal with that. SLIME is also useful as manual for Hyperspec (http://www.lispworks.com/documentation/HyperSpec/Front/ http://www.lispworks.com/documentation/HyperSpec/Front/) which is a basic tool to look quickly for code examples. - Don't use Hyperspec too much because it is really confusing. Use proper reference manuals like Peter Seibel's Practical Common Lisp [PCL] and Edi Weitz' Common Lisp recipes [CLR] - If you cannot get used to Emacs (which is a wonderful tool with a steep learning curve, really the best editor ever) then you can use proprietary IDE's like LispWorks or Franz Allegro. [QDC] http://quickdocs.org/ http://quickdocs.org/ [PCL] http://www.gigamonkeys.com/book/ http://www.gigamonkeys.com/book/ [CLR] http://weitz.de/cl-recipes/ http://weitz.de/cl-recipes/
- maxekman 10y ago
  Thanks for all the advice! Really helpful that you aimed it towards real world usage.

codr4life 10y ago

Do it. I spent years nervously fingering On Lisp on lunch breaks without really getting anywhere. But Paul Grahams early essays kept pulling me back into Emacs, and on each iteration something fell into place. It me took a long time to feel comfortable, but I wouldn't trade the feeling for anything. It's an alien chain saw; chain saws are intimidating enough in themselves, one with completely alien controls and instructions even more so. To paraphrase Graham, power looks weird from below.

progman 10y ago

I use Common Lisp for real projects. My recommendations: - Always follow the KISS principle (https://en.wikipedia.org/wiki/KISS_principle https://en.wikipedia.org/wiki/KISS_principle). Don't use Lisp's "super features" too much. The same applies to Haskell, by the way. - Use QuickLisp as much as possible. In many cases you don't need to add your own lib. Read Quickdos [QDC]. - Comment your code well, even if others don't ever see it lest you could not be able to understand your own code later. What's the purpose of the function, which arguments are expected, of which expected type are they, what are the possible results, possible side effects, etc. - Read and understand how Lisp's package system really works. This is important to avoid strange behaviors in your own code. - Use SLIME (https://common-lisp.net/project/slime/ https://common-lisp.net/project/slime/). It is an awesome interactive debugger which catches bugs and presents different options how to deal with that. SLIME is also useful as manual for Hyperspec (http://www.lispworks.com/documentation/HyperSpec/Front/ http://www.lispworks.com/documentation/HyperSpec/Front/) which is a basic tool to look quickly for code examples. - Don't use Hyperspec too much because it is really confusing. Use proper reference manuals like Peter Seibel's Practical Common Lisp [PCL] and Edi Weitz' Common Lisp recipes [CLR] - If you cannot get used to Emacs (which is a wonderful tool with a steep learning curve, really the best editor ever) then you can use proprietary IDE's like LispWorks or Franz Allegro. [QDC] http://quickdocs.org/ http://quickdocs.org/ [PCL] http://www.gigamonkeys.com/book/ http://www.gigamonkeys.com/book/ [CLR] http://weitz.de/cl-recipes/ http://weitz.de/cl-recipes/

maxekman 10y ago
Thanks for all the advice! Really helpful that you aimed it towards real world usage.