Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
There is still the Second Climacs editor, which uses a incremental and "proper" Common Lisp reader. scymtym recently did some impressive demos, including incremental parsing and a semantic analyser. I recall seeing more...somewhere.
I was wondering that what the author and other redditors here would think of/about Cursive, an affordable IDE for Clojure, while they have cider in Emacs as well.
I like the article, and the conclusion that if nobody takes the challenge, it does not exist. However I think that a lot of people have tried to make things happen, and of course took it as far as they thought necessary or sufficient, things like lem, LispIDE, climacs, and I'm sure there are may others. One of such efforts is what we have come to refer to as EMACS/SLIME, however there is more to it than that. EMACS is by design a good choice as the editor, because it was designed and has evolved with extensibility in mind, SLIME allowed us to connect EMACS to an underlying Common Lisp process, and gives you some extra superpowers, like access to the HyperSpec, Cross Reference, better code inspection tools, etc. We also have paredit or parinfer, auto-complete-mode, and some other things have been developed not just for Common Lisp but in order to accommodate the needs of larger groups of programmers including emacs-lisp programmers. To me EMACS/SLIME or EMACS/SLY (+ other modes) have become the paths of least resistance, both to create and customize a IDE experience, and EMACS will continue to be developed independent of its use as a environment to write lisp programs other than emacs lisp, because there is a loyal group of followers. The connecting tools (emacs minor and major modes) are just pieces of the whole machinery which are easier to maintain than a whole stand alone IDE, and it is kind of natural for common lisp programmers to contribute to the emacs set of solutions, becuase emacs lisp looks a lot like common lisp, I am sure it is not difficult for Scheme programmers to adapt too. The thing here is that the formal coordination of efforts does not exist, so everybody adopts either what they first find (through recommendation, cursory search, or .emacs copying), so there is no clear direction for improving on a single experience, which is what dedicated IDEs do, this also mean that you get to choose your experience, which dilutes the efforts but ends up creating an "survival of the fittest" scenario, where the more widely adopted solutions are the ones that dominate and get more attention and contributions. This is why I always advocate for the EMACS/Slime/Quicklisp/+useful-modes (I'll call it ESQ+) solution, because I think because of the nature of our community, this "natural evolution" has favored that beast. I don't know if the future will provide some other beasts that are as capable of adaptation as ESQ+, but I am sure ESQ+ can continue to evolve and adapt to what different users need.