Common Lisp and Emacs

If something is not discouraged by a community years after its first release, then that something must have some merit subject to your own scrutiny. Vi is ubiquitous, and its modal-editing is a boon for editing - not necessarily writing - code. Emacs is extensible, and its community has provided Extensible VI Layer to provide the best of Emacs and Vi.

And if you ever feel annoyed by constantly switching between insert and edit mode in Vi, feel free to try out smart-god-mode. The only thing beyond it (barring minor tweaks) would be a brain-computer-interface itself.

If you know why exactly you need the IDE for, then, no. If you actually use the PyCharm or IntelliJ IDEA features dedicated to those languages, then, no, emacs - does not replace a full-blown IDE. But, you could always ask a community.

Although as far as Common Lisp is concerned, the Superior Lisp Interaction Mode for Emacs (SLIME) absolutely blows most things out of the water even though it has its own shortcomings.

Opinionated Common Lisp Resources 2020

If you are in it for the long haul, yes. But, something like emacs-noob/slime-company-modern or mousemacs can provide familiar (non-emacs/vi) key-bindings, so that you can focus on Common Lisp first, and then on Emacs.

All of these are immature projects. Wait for another 5-10* years to test their maturity.

With Emacs, there is

• smart-god-mode: if you'd wish to do me or emacs community a favour - or want to tinker around in emacs, look into merging it into its original god-mode repository
• emacs-noob: a simplified starter kit for emacs; you should check out awesome-emacs before sticking with it though! Again, here too, you could look into improving the code / repository structure by implementing DRY-principles while keeping the usage as simple as possible (drag 'n drop).

With Common Lisp, there is

• py4cl2-cffi: finally, we have a CFFI approach to using python libraries from common lisp!
• py4cl2: a bunch of incompatible changes and improvements over the original py4cl; the goal is to enable the use of python libraries in common lisp in non-performance-intensive use cases. compared to py4cl, py4cl2 is still immature; like most things Common Lisp, I'll let time decide when it becomes mature enough.
• extensible-compound-types: common lisp provides DEFTYPE that only allows defining type aliases aka derived type specifiers. That means there is no way through which users can define types with true type parameters. The closest is satisfies which gets ugly quickly. extensible-compound-types is an attempt to overcome this limitation.
• polymorphic-functions: a library that intends to bring type-based adhoc, subtype as well as (limited) parametric polymorphism to common lisp; yeah common lisp does already have a super neat class-based polymorphism known as CLOS with a MOP, and a few helper libraries; but I and a few others have wished for type-based polymorphism.
• dense-arrays: a numpy-like array object for common lisp
• numericals: a simd-based basic math library for common lisp
• common-lisp-libraries.readthedocs.io: an attractive documentation site for some of the defacto common lisp libraries

*If 5-10 years sounds like too much, then, welcome to the world of Common Lisp :). This language was ANSI standardized in 1994, which means if you stuck to the ANSI standard (or perhaps the then defacto libraries), then code written in the year 2000 should still be working in 2020. Well, that is in theory; in practice, I still lack much experience.

For my purposes, I absolutely do need Common Lisp implementations with a working CLTL2 (and some more) support. In my experience, SBCL does this reasonably. But the day this support vanishes from SBCL, I might as well drop Common Lisp in favor of another language.