3 ms·

To me the problem with LISP's was never the syntax, I understand s-expressions and homoiconicity and all that, the problem was also....this is embarrassing...th

To me the problem with LISP's was never the syntax, I understand s-expressions and homoiconicity and all that, the problem was also....this is embarrassing...the dev setup/environment. In every single non-LISP language/environment - whether it be C, C++, Rust, Go, C#, Java - I can sit down comfortably in VIM or Vscode+VIM and just start hacking away. With LISPs, I always feel like I'm fighting my editor - and I am. I know about Emacs+SLIME, I know about paredit, I've seen it in action and it's impressive, I just can't force myself to expand the energy to dive into the Emacs eco-system. And yes I've tried vim fireplace and Cursive and VSCode's latest ...whatever.....but they all just feel "wrong" in a way, like a square peg in a round hole. I feel if I could just spend enough time to really understand Emacs and all of it's LISP-yness goodness, I'd enjoy LISPs a lot more and use them more in daily work

lispm 6y ago
You could use Lisp in a batch style. I would then propose to use a compiler-based implementation like SBCL, since the compiler gives a lot of feedback. That can help in batch programming -> write code, compile it, run it -> with the added error messages from the compiler or the runtime. Some people program Lisp with very primitive editors, but they better use the Read Eval Print Loop for interactive programming, too. That would be different from the usual C, C++, ... Java programming. You would need to understand interactive programming. That's a level one needs to master - especially in many situations (and where one does not use SBCL) the dynamic typing of much of Lisp requires interactive exploration/debugging.