- SBCL (very fast lisp implementation)
- Quicklisp (lisp package manager)
- ASDF (builder)
- SLIME (Common Lisp mode for Emacs)
- Paredit (allows easier editing of s-expressions)
- and other tools that make CL development a pleasure.
The combination of the tools above are effectively a very powerful Common Lisp IDE.
- SBCL (or whatever Common Lisp implementation you can get your hands on)
- a text editor
- (maybe rlwrap)
Only if you want to teach people to hate s-expressions and write stuff like:
IMHO: For pedagogical reasons Lisp editors should show parens with a color that makes them transparent and almost hides them into background. Parens are there for the editor to find patterns not people to see and match (except maybe one or two most inner levels). You use proper indentation to see the structure just like you do with Python.
This must be stressed. It is very important to use a lisp-aware editor. It doesn't have sense to do stuff that a lisp-editor can do automatically, such as auto-indent, and keeping parens balanced all the time.
Also, a good IDE (such as Portacle) gives very good on-the-fly documentation of function parameters/etc, which makes learning CL much faster.
They are very complicated to use and understand.
Then I abandoned Common Lisp...
Emacs isn't the only editor too: https://lispcookbook.github.io/cl-cookbook/editor-support.ht... Lem is also a ready-to-use editor (ncurses or Electron)(but Emacs+Slime is still the best experience (maybe vim?))
You can follow this guide to get started too: https://lispcookbook.github.io/cl-cookbook/getting-started.h...
And hopefully this Cookbook will help you along the way: https://lispcookbook.github.io/cl-cookbook/
Quicklisp takes a couple commands to install, then it's easy. To install a library: `(ql:quickload :my-lib)`. Thinks of it closer to apt than to pip/npm, so you don't upgrade one lib but a QL distribution.
You don't really have to deal with asdf. It is used to create a project declaration, which can be generated for you (see "getting started", cl-project). ASDF helps in creating executables, it's also explained in the cookbook.
Um... basically the only command you need to learn is ql:quickload followed by the name of the system you want to load.
Perhaps you had problems with the concepts of Lisp packages (namespaces)?
Rather unlikely. The namespaces are pretty easy to understand conceptually, and their interface is pretty minimal. Same goes for Quicklisp, very easy to start with, practically one function call needed in most cases.
Now there's ASDF. I know, it's a thing of beauty, but it's not simple to use or to understand.
Well, it's actually that way for good reasons: the problem it solves is complex and hard. The only comparable system I know of is Erlang releases mechanism, which is also a solid tool, but definitely not the simplest one in Erlang repertoire.
Anyway, if someone cites ASDF as a reason for struggling with Common Lisp, I find it very believable.
> Rather unlikely. The namespaces are pretty easy to understand conceptually, and their interface is pretty minimal.
Packages can definitely give beginners trouble. I don't think it's that uncommon for newcomers to Lisp to have REPL sessions like this:
CL-USER> (ql:quickload :iterate)
CL-USER> (iter (for i below 10) (collect i))
;; Error: 3 undefined functions and two undefined variables
CL-USER> (use-package :iterate)
;; Error: 3 NAME-CONFLICTs saying that the symbols ITER and friends
;; are already accessible
I would like to see this applied to other language environments to lower the barrier to entry. Maybe Erlang, Haskell, Racket, Ocaml.
Bozhidar Batsov's Prelude is another excellent one. It's got a lot of good pre-selected choices, and almost no bad ones. I can highly recommend it.
Emacs is best thought of as a special-purpose virtual machine, a little bit like the JVM och Python VM. Maybe this will help people understand that something like Magit is not just a Git integration for Emacs users -- it is a full, standalone end-user Git interface that just happens to be written for the Emacs VM.
I'm not too keen on oackaging the VM with an application for easy deployment, but I do hope it helps people view Emacs modes as not just "an X for Emacs users" but rather "an alternative X that happens to run on Emacs".
Calc is another thing a lot of people could use to great effect but don't because it runs in Emacs.
I've spent a long time going back and forth between Atom/VSCode (too slow on my machine) and [neo]vim (where language integration/autocomplete/file tree/etc. still feel like bolted-on hacks). The I discovered doom-emacs. It's the best of all three worlds: the speed and power of Emacs, the modal editing agility of Vim, the beautiful UI of Atom (after some configuration).
Back before Eclipse, it wasn't uncommon for emacs to be bundled into development environments. Xemacs is a famous example of this (being forked by Lucid for their dev tools). My recall is that SunWorkshop used to use emacs as the IDE frontend back in the 90s. Allegro Common Lisp also used to include it.
I think I came across other examples, but currently Google isn't providing enough help to 20 year old memories.
I assume it would be non-trivial, however, just based on the experience I've had with the process so far.
C-f Forward one character
C-n Next line
C-b Back one character
C-p Previous line
...and close Emacs, never to open it again.
The tutorial goes on to say:
When you get used to these keys, they're faster than their more familiar equivalents in other applications (Home, End, Ctrl+Left, etc.) because you don't have to move your hands from the touch typing position.
That's such ridiculous micro- and premature optimization - especially given that, since Emacs predates modern conventions, almost nothing is natively familiar - that it boggles the mind.
Has it been measured?
I mean, if they have actually measured:
1) the speed difference of using those shortcuts vs arrow/page-up and co when merely typing
2) the same speed difference as a percentage of the overall programming process
3) the impact of such speed difference in programmer productivity (speed translated to results faster or better code with fewer bugs).
Or it's just cargo cult?
Yes, it is. Like much of the rest of programming.
I think it's weird for an IDE to tell me which command keys to use. It should have a set of default keys, and ideally those could be remapped as well.
The biggest benefit of directional keys (up, down, home, end, etc...) is that they are universal across keyboards and languages. Control-F may be great if you're on a VT100 terminal, but maybe I'm on an AZERTY keyboard, or one of those funky square keyboards. Or a Chinese keyboard that's largely input by writing characters on a little pad. Or on a Mac using gestures or Ink. Or a dozen other possibilities.
If I was only programming in Pascal and only on one computer in one environment for the rest of my life, then it would make sense to learn those keystrokes. But like is more complicated than when those were first coded.
It sounds like you may not be aware that this describes emacs?
It's not premature in my opinion.
I've used re-frame ClojureScript for a few years now but would like to dip my toes in CL, just can't seem to get a head start. Maybe trying CL on the backend first, but even there Clojure dominates..
A relatively new Web Application Environment called Radiance may also be worth looking at.
Clojurescript was chosen on the client side because its integration with Om was very nice and matched the idea of immutability in Clojure.
Now that Om is no longer well supported we have a problem. The client side needs to be rewritten, but none of us have the time to do so. We'll see what happens with the project.
This highlights another benefit of Common Lisp. It's very mature and I don't have to worry about the fameworks that I use becoming obsolete after a short period of time.
It is said that CL provides a nicer experience to the developer (like, for example, clearer error messages, a more interactive development experience, etc.)
I tried it, it works fine, but still very alpha and moving. However, thinking about the possibility to write a SPA all in Lisp (no JS!), and then with easy deployments, executables, easy inclusion with Electron (Ceramic) is extremely exciting.
Are you aware of my fork ? You're certainly welcome to take anything from there that you like. I think the most recent work was on the 'bootstrap' branch. I recall that I was going a little bit in a different direction from what the other maintainer wanted to do, but I no longer recall the details.
There's a lib for doing React dev using Parenscript, as well.
And of course there are a lot of CL libraries for html generation, JSON parsing, web servers, etc.
>Maybe trying CL on the backend first
I'd say CL is just perfect for the backend side, everything you need should be there.
Well, not saying Clojure is better. Just saying that Lispers totally are on the SpA bandwagon. For example the CircleCI frontend is written in ClojureScript.
Check out Nightcoders for a similar IDE for Clojure.
First would be that it cannot be put together into a single executable as it is composed of multiple, separate components, that each rely on a specific structure of the file system being present. This is not something I can control.
Second, Portacle is made in such a way that all three platforms can be combined together into a single directory so that it can be run on any system as one, which mandates a shared folder structure.
Third, in order to be self-contained, the Portacle installation directory must contain its own configuration and project directories. It makes no sense to allow you to move the executable outside of this, and it would make no sense to put those directories within the .app on, say, mac.
And it messes up with our config:
> Delete ~/.emacs or ~/.emacs.d if they exist.
Making WebAssembly better for Rust(Common Lisp)
I guess on the future we could have VPortacle, which would be VIM + SLIMV (Superior Lisp Interaction Mode for Vim, the Vim counterpart to SLIME).
Would love to see this all in one for Clojure (incl. self contained standalone emacs)